1. Transportsicherheit – SSL und HTTPS
Markus Groß

2. AGENDA
2
Inhaltsverzeichnis

3.  Wie lässt sich die Vertrauenswürdigkeit der
Gegenstelle gewährleisten?
 Woher weiss man genau, durch welche Rechner die
TCP-Pakete gehen?
 Sicherheitsrisiko z.B. beim online Banking,
eCommerce und „Unterschrift“ von Verträgen
1 MOTIVATION
3
Wozu Transportsicherheit?

4.  Transposition
 Bei einem Transpositions-Algorithmus bleiben die Buchstaben
was sie sind, aber nicht wo sie sind
 Substitution
 Bei der Substitution werden die einzelnen Klartextbuchstaben
durch bestimmte Geheimtextbuchstaben ersetzt
Verfahren und Methoden
2 EXKURSVERSCHLÜSSELUNG
4
Grundlagen Verschlüsselung
Klartext: a b c d e f g h i j k l m n o p q r s t u v w x y z
Geheimtext: Q W E R T Y U I O P A S D F G H J K L Z X C V B N M
Klartext: H A L L O L E U T E W I E G E H T E S E U C H
Geheimtext: H A L L O
L E U T E
W I E G E
H T E S E
U C H

5.  Gleicher Schlüssel zum Ver- und Entschlüsseln der
Daten bzw. Datei
 Problem: Schlüsselübergabe
 Unsicher (per E-Mail oder andere elektronische Medien)
 Unpraktisch (per Telefon o.ä.)
 Wegen Notwendigkeit der Übergabe: Schlüssellänge nicht
ausreichend komplex
2 EXKURSVERSCHLÜSSELUNG
5
Symmetrische Verfahren

6.  Caesar Chiffre - Substitution
 Verschiebung der Buchstaben um X Buchtaben
 Leicht zu erraten, maximal 26 Schlüssel
 Griechische Skytral –Transposition
 Klartext wird um eine Rolle gewickelt
 Komplexere Verfahren (Polyalphabetisch)
 Vigenère Verschlüsselung
 Playfair Chiper
 Mechanische Verfahren
 Rotor Maschine
 Enigma
2 EXKURSVERSCHLÜSSELUNG
6
Klassische symmetrische Verschlüsselung

7. Data Encryption Standard (DES)
7
Moderne symmetrische Verschlüsselung
 Von IBM entwickelt und 1974 in den
USA standardisiert
 Wichtigste Bestandteile sind:
 Permutation
 XOR (logische Verknüpfung zweier
binärer Werte)
 Substitution
 DES ist ein Blockchiffre
 Klartext wird in 64 Bit Blöcke eingeteilt
 Durch Registeroperation sehr
„hardwarenah“ und schnell
2 EXKURSVERSCHLÜSSELUNG

8.  Ein Schlüssel zum Verschlüsseln der Datei, Public
Key, nicht geheim, auf Schlüsselservern verfügbar
 Ein Schlüssel zum Entschlüsseln, Private Key,
geschützt, bleibt beim Adressaten der Datei
→ Problem der unsicheren/unkomfortablen
Schlüsselübergabe gelöst
2 EXKURSVERSCHLÜSSELUNG
8
Asymmetrische Verfahren (Public Key-Prinzip)
Der geheime Schlüssel
entschlüsselt Nachrichten
Der öffentliche Schlüssel
verschlüsselt Nachrichten

9. RSA Verfahren
9
Ronal Rivest, Adi Shamir und Leonard Adleman
 Schlüsselerzeugung
→Wahl von zwei große Primzahlen p und q
(> 512 Bit)
→Bilde n = p * q
→Bestimme mit Hilfe des euklidischen
Algorithmus d und e
→ n und e bilden den öffentlichen Schlüssel
→ d den privaten Schlüssel
 Chiffrierung
 Geheimtext = Klartexte mod n
 Dechiffrierung
 Klartext = Geheimtextd mod n
2 EXKURSVERSCHLÜSSELUNG

10. Sicherheit Asymmetrische Verschlüsselung
10
 Solange sicher bis es keinen
effizienten Algorithmus zur
Primfaktorzerlegung großer Zahlen
gibt
 Laufzeitberechnung nach Schorn:
 Bei >100 stelligen Primzahlen benötigt
ein „handelsüblicher“ PC über 74
Jahre
2 EXKURSVERSCHLÜSSELUNG

11. Hybride Verschlüsselung
11
 Kombination beider Verfahren
 Problem symmetrische Verfahren
→Schlüssel Übermittlung
 Problem asymmetrischen Verfahren
→Hardware unfreundlich
 Übertragung des Schlüssels per
asymmetrischer Verschlüsselung
 Übertragung der Nachricht per
symmetrischen Verschlüsselung
→Grundlage von SSL
2 EXKURSVERSCHLÜSSELUNG

12.  MD5 wurde 1994 von Ronald L. Rivest am MIT
entwickelt
 Einweg-Algorithmus um aus einer beliebig langen
Zeichenkette eine eindeutige Checksumme mit
fester Länge zu berechnen (128 Bit)
 Auffüllen der Nachricht bis die Länge in Bit ein Vielfaches von
512 Bit beträgt
 Eingabewert wird in 512 Bit Blöcke geteilt - ABCD
 …
 http://www.hashgenerator.de/
MD5 (Message-Digest Algorithm 5) - RFC1321
2 EXKURSVERSCHLÜSSELUNG
12
Hashing
md5("Transportsicherheit - SSL, TLS https") =
552697af6c392a8b1b0934587695242ecef8ede6

13. 1. Nutzer tippt http://www.fhdw.de ein
2. Browser sucht auf einem Domain Name Server
(DNS) die IP-Adresse zu www.fhdw.de
3. Browser baut eine TCP-Verbindung zu
193.426.15.50 und Port 80 auf
4. Browser sendet ein HTTP-Kommando über TCP an
193.426.15.50 /Port 80:
Wie arbeitet ein Webbrowser?
3 GRUNDLAGEN
13
HTTP
Get start.htm HTTP/1.0
User-agent: Netscape 4.7
Accept: text/plain
Accept: text/html
Accept: image/gif

14. 5. Server antwortet über die TCP-Verbindung mit:
 Einer Statuszeile (Erfolgsmeldung oder Fehler),
 Metainfomation (Beschreibung der nachfolgenden
Information),
 Einer Leerzeile und
 Der Information selbst:
Wie arbeitet ein Webbrowser?
3 GRUNDLAGEN
14
HTTP
HTTP/1.0 Status 200 Document follows
Server: Apache/1.8
Date: Mon, 14 Mai, 2001 11:23:22 GMT
Content-type: text/html
Content-length: 5280
Last-modified: Fri, 11 Mai, 2001 03:12:12 GMT
<html> ...
</html>

15.  Schritt 1 - 5 wird für jede HTTP(1.0)-Anfrage
wiederholt
 Insbesondere muss für jede HTTP(1.0)-Anfrage eine
neue TCP-Verbindung aufgebaut werden
 Moderne Browser „schummeln“ hier und bauen
mehrere TCP-Verbindungen gleichzeitig auf, um die
verschiedenen Bestandteile einer Webseite
schneller zu laden
Wie arbeitet ein Webbrowser?
3 GRUNDLAGEN
15
HTTP

16.  Einfaches Username/Passwort-Verfahren
 Pop-Up-Fenster im Browser erscheint
 Passwort ist NICHT verschlüsselt (BASE64-codiert)
3 GRUNDLAGEN
16
HTTP Basic Authentication (RFC 2617)
Quelle: Schwenk, Jörg (2005): Sicherheit und Kryptographie im Internet, 2.Auflage, Vieweg
GET /root/secret.html HTTP/1.0
HOST: www.bank.de
HTTP/1.0 401 Authorization Required
WWW-Authenticate: Basic realm="name"
GET /root/secret.html HTTP/1.0
HOST:www.bank.de
Authorization: Basic QWRtaW46Zm9vYmFy
HTTP/1.0 200 OK
secret.html

17.  Erweiterung im HTTP 1.1 Standard
 User-ID und Passwort nicht mehr im Klartext
3 GRUNDLAGEN
17
HTTP Digest Authentication (RFC 2617)
Quelle: Schwenk, Jörg (2005): Sicherheit und Kryptographie im Internet, 2.Auflage, Vieweg
GET /root/secret.html HTTP/1.0
HOST: www.bank.de
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
realm=“mitarbeiter@bank.de",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41
Authorization: Digest username=“Hans.Mueller",
realm="mitarbeiter@bank.de",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri=“/root/secret.html",
response="e966c932a9242554e42c8ee200cec7f6",
opaque="5ccc069c403ebaf9f0171e9517f40e41
HTTP/1.0 200 OK
secret.html

18.  Authentizität
 Empfänger soll die Herkunft eindeutig ermittel können
 Verhindern, dass sich jemand Drittes als
Kommunikationspartner ausgibt
 Integrität
 Sicherstellung der Echtheit der Daten
 Empfänger soll überprüfen können, ob die Nachricht bei der
Übermittlung verändert wurde
 Vertraulichkeit
 Es soll sichergestellt werden, dass nur derjenige die Nachricht
empfängt für den sie auch bestimmt ist
3 GRUNDLAGEN
18
Anforderungen an sichere Kommunikation

19.  SSL 1.0 (1993)
 Interne Entwicklung von Netscape
 SSL 2.0 (1994)
 Erste Veröffentlichung in Netscape Navigator
 Max. 40 Bit Schlüssellänge (US Export Vorschriften)
 SSL 3.0 (1995)
 Bugfixing und aktuelle Kryptotechnologie
 Aufhebung der Begrenzung der Schlüssellänge
 TLS (Transport Layer Security)
 Eigentlich Version 3.1 von SSL (auf SSL 3.0 basierend)
 Standardisiertes von der IETF entwickeltes Sicherheitsprotokoll
Secure Socket Layer
3 GRUNDLAGEN
19
Entwicklung von SSL

20. Von 1994 bis heute
3 GRUNDLAGEN
20
Die Meilensteine von SSL
Entwicklungsschritte
SSL 1.0
Netscape
SSL 2.0
SSL 3.0
TLS 1.0
RFC 2246
TLS 1.1

21. Die transparente SSL Zwischenschicht
4 SECURESOCKTLAYER
21
SSL im OSI Model
SSL Implemetierung
TCP
IP
Netzwerkschicht
Quelle: Schwenk, Jörg (2005): Sicherheit und Kryptographie im Internet, 2.Auflage, Vieweg
HTTP(S)
SSL Record
SSL Handshake

22. SSL Protokoll Aufbau im Detail
4 SECURESOCKTLAYER
22
Protokollübersicht
Hand-
shake
Change-
Chiper
Alert
Record Layer
TCP
Quelle: Schwenk, Jörg (2005): Sicherheit und Kryptographie im Internet, 2.Auflage, Vieweg
HTTP(s) - Anwendungsprotokoll
TLS

23.  Funktion
 Sicherstellung der Authentizität der Gegenstelle durch
Zertifikate
 Austausch der öffentlichen Schlüssel
 Bei X.509 Zertifikaten Ausstellung durch
Certifcation Authorities (CA)
 Zertifikat beinhalte folgende Felder
 Aussteller und Inhaber
 Gültigkeitsdauer
 Zertifizierungspfad (LDAP)
 Public Key
 Verwendete Algorithmen
 Mit dem PrivateKey verschlüsselter Hashwert über Zertifikat
4 SECURESOCKTLAYER
23
Exkurs: Zertifikate nach X.509-Standard

24.  Beispiel Zertifikat:
4 SECURESOCKTLAYER
24
Exkurs: Zertifikate nach X.509-Standard
Issuer VeriSign, Inc.
Subject CIS GmbH
premium01.privatepilot.de
Validation
Period
01-01-2008 00:00:00 UTC
31-01-2009 23:59:59 UTC
Public Key RSA, 0x433d9384582...
Algorithm MD5 + RSA
Signature 0x3a53cb25445...
0x53f2
MD5 Digest
Entschlüsselung mit
PrivateKey

25.  Sichere Identifizierung erfordert dritte Instanz, der
beide Kommunikationspartner vertrauen
 Erstellung eines eindeutigen Zertifikats
 Ein CA validiert die Identität des Zertifikatsinhabers auf
konventionellem Weg (Ausweis, Handelsregisterauszug)
 Die CA erstellt das Zertifikat und schickt Zertifikat (per E-Mail)
und privaten Schlüssel (per Post) an Antragsteller
 Certification Authoritys authentifizieren sich
gegenseitig
 In Deutschland gilt ergänzend Signaturgesetz – SigG
 Risiko durch die Vielzahl der Schlüssel/CA
4 SECURESOCKTLAYER
25
Exkurs: Zertifikate nach X.509-Standard

26. 4 SECURESOCKTLAYER
26
SSL Handschake Protokoll
Client_Hello
• Verfügbare sym.
Verschlüsselung
•Client Zufallszahl
Server_Hello
• Verschlüsselung
• Server Zufallszahl
Server_Certifikat
Server-Zertifikat mit
Public Key
ClientKeyExchange
Sym. Schlüssel,
verschlüsselt mit
Public Key
Verify_Key
Sicherer Kanal Sicherer Kanal

27.  Einfach gehaltenes Protokoll
 Besteht neben dem Header nur aus dem Wert 1
 CCS „erzwingt“ die Verschlüsselung neu
auszuhandeln
 Beim Versenden dieser kurzen Nachricht darf
allerdings nicht vergessen werden, sie mit Hilfe der
alten Spezifikationen zu komprimieren bzw. zu
chiffrieren
4 SECURESOCKTLAYER
27
Change-Cipher-Spec Protokoll
Version: 3.0Type: 20 Length:
0x1 CCS: 1

28. 4 SECURESOCKTLAYER
28
Change-Cipher-Spec Protokoll

29.  Tritt bei Fehlern in der Kommunikation in Kraft
4 SECURESOCKTLAYER
29
Alert Protokoll
Version: 3.0Type: 21 Length:
0x2 Grad Beschreibung

30. SSL Record Protokoll
4 SECURESOCKTLAYER
30
Ablauf einer Verschlüsselung
A B C D E F G H IAnwendungsdaten
A B C D E F G H IAufteilung in
„Records“
XXXkomprimierter
„Record“
komprimieren
„Records“ dürfen max. 16 KB groß sein
XXXverschlüsselter
„Record“
.........TCP Paket
verschlüsseln MAC generieren
übermitteln
Quelle: http://www.cisco.com/en/US/about/ac123/ac147/archived_issues/ipj_1-1/ssl.html

31. Daten
4 SECURESOCKTLAYER
31
Darstellung eines Records
Version: 3.0Type: 23 Length:
0x2
Message Autehtification Code
Verschlüsselt
Quelle: Schwenk, Jörg (2005): Sicherheit und Kryptographie im Internet, 2.Auflage, Vieweg

32. Passive Traffic-Analyse
32
 Länge des http-get()-Statements und
der Antwort ist bekannt
 Scann gegen Webserver auf passende
URLs und HTML-Seiten möglich
 Beispiel:
unmittelbar nach Verbindungsaufbau
 Client  Server: 53 Byte übertragen
 Server  Client: 3742 Byte übertragen
 Suche nach 53 Byte langer URLs, die
3742 Byte Daten zurückliefern
5 ANGRIFFSMÖGLICHKEITEN

33.  Alle Informationen zwischen Server und Client
werden vom Hacker abgefangen
 Server und Client „denken“ immer, dass sie direkt
miteinander kommunizieren
 Nur erfolgsversprechend während des
Verbindungsaufbaus (einzige unverschlüsselte
Kommunikation)
Aktive Attacke
5 ANGRIFFSMÖGLICHKEITEN
33
Man-in-the-middle Attake

34. Sonstige Angriffsmöglichkeiten
34
 Schwachpunkt sitzt vor dem
Bildschirm
 Unwissenheit
 Zu schwache Passwörter
 Sozial Hacking (Geburtsdatum,
Nachname etc.)
 Phishing
 Versand vom SPAM Mail mit der
Aufforderung persönliche
Zugangsdaten bekannt zu geben
 Trojaner
5 ANGRIFFSMÖGLICHKEITEN

35.  Ursprünglich von Netscape entwickelt
 Erste Implementierung 1995 in Netscape Navigator
 SSL wahrt:
 Authentizität durch Zertifikate und asymmetrische
Verschlüsselung
 Integrität durch eindeutige Hashes
 Datenschutz (privacy) durch symmetrische Verschlüsselung
 SSL ist nach heutigem Kenntnisstand sehr sicher
und schnell
 Universell einsetzbar, da transparent im OSI
Protokoll implementiert
6 ZUSAMMENFASSUNG
35
Fazit

36.  Protokollstruktur verifiziert Sicherheit gegenseitig
 Standardisierte Weiterentwicklung durch IETF als
TLS (SSL 3.1)
 Dokumentiert als Request for Comment (RfC)
 Schwachpunkte sind Certification Autorities
 Verwaltung sehr vieler Schlüssel und Benutzer (Passwörter)
 Mögliche Angriffspunkte
 Passive Traffic-Analyse
 Man-in-the-middle-Attake
 Phishing, Trojaner, schwache Passwörter
6 ZUSAMMENFASSUNG
36
Fazit

37.  Beutelspacher, Albrecht (1994): Kryptologie, 4
Aufl., Springer
 Boon, Rochard E. Smith (1998): Internet-
Kryptographie, 1. Aufl., Addison-Wesley
 Garfinkel, Simson / Spafford, Gene (2002): Web
Security, Privacy and Commerce, 2. Aufl., O‘Reilly
 Rescorla, Eric (2000): SSL and TLS, 1. Aufl., Addison-
Wesley
 Schumacher, Roger (2007): Geschichte der
Kryptographie. 1 Aufl., Vieweg
 Schwenk, Jörg (2005): Sicherheit und Kryptographie
im Internet, 2.Aufl., Vieweg
7 LITERATURVERZEICHNIS
37
Quellen (1/2)

38.  Wobst, Reinhard (2000): Abenteuer Kryptologie, 1.
Aufl., Addison-Wesley
Onlinequellen:
 Spezifikation von SSL:
http://wp.netscape.com/ssl13/3-SPEC.HTM
 Einführung in SSL:
http://www.repges.net/SSL/ssl.html
 SSL Zusammenfassung
http://www1.tfh-berlin.de/~toby/vh/ssl
7 LITERATURVERZEICHNIS
38
Quellen (2/2)

39. 5c91a528471ec0b430de5fbdd73cea54
abd853daffff69f5ea2e1fc005590f86

40. Vielen Dank für Ihre Aufmerksamkeit
Noch Fragen?