Systems Architecture Comparison SSL/TLS, TLS for multiple virtual hosts Dominik Oepen, Dennis Reinert
2 May Systems Architecture Inhalt Einleitung Grundlagen Record Layer Handshake Protokoll Vergleich SSL 3.0 und TLS 1.0 TLS Erweiterungen / virtuelle Hosts Zusammenfassung Quellenverzeichnis
3 May Systems Architecture Was ist das Problem? Problem Webserver Internet Alice Bob Vertraulichkeit? Authentizität? Einleitung
4 May Systems Architecture Mögliche Lösung? Lösung Webserver Internet Alice Bob SSL/TLS Einleitung
5 May Systems Architecture Geschichte Netscape Navigator, SSL 2.0 SSL 3.1 als Standard durch die IETF festgelegt und umbenannt in TLS 1.0 (Transport Layer Security) SSL 1.0 von Netscape Communications Corp /1995 Webbrowser Mosaic 1.0 vom NCSA (National Center for Supercomputing Applications) 1996 SSL 3.0 und Übergabe an die IETF (Internet Engineering Task Force) 01/ /2006 Netscape Navigator, SSL 2.0 TLS 1.1 und TLS Extensions veröffentlicht durch die IETF Einleitung
6 May Systems Architecture SSL/TLS in den Referenzmodellen SSL/TLS zwischen Anwendungsschicht und Transportschicht Aufbau eines sicheren SSL/TLS Kanals (Socket) oberhalb der TCP-Verbindung IP HTTP, SMTP, FTP ATM, PPP, Ethernet TCP SSL/TLS Bitübertragungsschicht Sicherungsschicht Vermittlungsschicht Transportschicht Sitzungsschicht Darstellungsschicht Anwendungsschicht OSI Internet Anwendung- schicht Host-zu-Netz Transportschicht TCP/IP Einleitung
7 May Systems Architecture Bestandteile des SSL/TLS Protokolls TCP Record Layer Hand- shake HTTP (oder andere Anwendungsprotokolle) Change Chipher Alert Einleitung
8 May Systems Architecture Kryptografische Grundlagen - Hashfunktionen - Signaturen - Zertifikate / Public Key Infrastructure (PKI) SSL und TLS verwenden eine Vielzahl von kryptografischen Verfahren: Grundlagen
9 May Systems Architecture Hashfunktionen - Funktion: ∑* => ∑^n -Einwegfunktionen -Kollisionsresistent (Kryptografische) Hashfunktion: Grundlagen
10 May Systems Architecture Signaturen Sender bildet Hashwert der Nachricht Verschlüsselt Hashwert mit privatem Schlüssel Empfänger kann anhand des Hashwerts verifizieren, dass die Nachricht nicht verändert wurde Signaturen dienen der Integritätsprüfung - Bei SSL Verwendung von Message Authentication Codes (MAC), verwendet symetrische Schlüssel Grundlagen
11 May Systems Architecture Zertifikate / PKI Wie kann man feststellen ob eine Nachricht wirklich von einem bestimmten Absender stammt? Zertifikate sind vergleichbar mit virtuellen Ausweisen Enthalten Informationen über Zertifikatsinhaber (Name, Domain, etc.) und deren Public Key Werden von vertrauenswürdigen Instanzen ausgestellt, Certification Authorities (CA) Echtheit einer Signatur kann anhand der Signatur der CA verifiziert werden Zertifikate der Root CAs sind selbst signiert und werden mit Browsern mitgeliefert Grundlagen
12 May Systems Architecture PKI CA 1CA 2CA 3 Root CA Zertifikat Grundlagen
13 May Systems Architecture Record Layer neue Ebene in der Protokollhierachie akzeptiert Folge von Bytes (Bytestrom) von der Anwendung Fragmentierung des Bytestroms der Applikation in Blöcke (Records) Komprimierung der Applikationsdaten (optional) Authentifizierung der Daten durch MAC (Message Authentication Code) Ver-/Entschlüsselung mit dem Handshake wird das Schlüsselmaterial zwischen den Partnern vereinbart IP HTTP Netzwerk- schicht TCP Record Layer
14 May Systems Architecture Record Layer - Protokoll in Aktion Applikationsdaten Fragmentierung Komprimierung Authentifizierung MAC Verschlüsselung Anhängen des Record Headers MAC Padd.P. Länge MAC Padd.P. Länge H Record Layer
15 May Systems Architecture Record Layer - Aufbau Record Paket TypLängeMajor Version Message Authentication Code (optional) Länge Daten verschlüsselt (optional) Minor Version Record Layer
16 May Systems Architecture SSL Handshake Protocol Ziele des Handshake Protokolls: Verbindungsaufbau Austausch von Schlüsseln für Verschlüsselung und MAC Authentifizierung Handshake - Protokoll
17 May Systems Architecture SSL Handshake Protocol Webserver Alice ClientHello Handshake - Protokoll
18 May Systems Architecture ClientHello Höchste beherrschte SSL/TLS Version Eine Liste von Algorithmen die der Client beherrscht (Cipher Suites) Session ID Zufallszahl Rc Die Client Hello Nachricht enthält: Handshake - Protokoll
19 May Systems Architecture SSL Handshake Protocol Webserver Alice ClientHello ServerHello Certificate ServerHelloDone Handshake - Protokoll
20 May Systems Architecture ServerHello / Certificate Die zu verwendende SSL/TLS Version Falls Session fortgesetzt werden kann Session ID Die zu verwendende Cipher Suite Zufallszahl Rs Der Server wählt: Danach sendet er sein Zertifikat Phase wird durch ServerHelloDone beendet Handshake - Protokoll
21 May Systems Architecture SSL Handshake Protocol Webserver Alice ClientHello ClientKeyExchange ServerHello Certificate ServerHelloDone Handshake - Protokoll
22 May Systems Architecture ClientKeyExchange Client erzeugt Zufallszahl (Premaster Secret) Verschlüsselt diese mit Public Key des Servers Sendet verschlüsseltes Premaster Secret an Server Handshake - Protokoll
23 May Systems Architecture Schlüsselerzeugung Insgesamt werden 4 Schlüssel erzeugt: - Zwei Schlüssel zur symetrischen Verschlüsselung - Zwei Schlüssel für die MACs Handshake - Protokoll Master Secret = MD5( Pre | SHA( 'A' | Pre | Rc | Rs)) | MD5( Pre | SHA( 'BB' | Pre | Rc | Rs)) | MD5( Pre | SHA( 'CCC' | Pre | Rc | Rs)) Aus Rc, Rs und dem Premaster Secret wird das Master Secret errechnet:
24 May Systems Architecture SSL Handshake Protocol Webserver Alice ClientHello ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished ServerHello Certificate ServerHelloDone Handshake - Protokoll
25 May Systems Architecture ChangeCipherSpec ChangeCipherSpec ist ein eigenes Protokoll Wird unter bestimmten Umständen durchgeführt (Überlauf der Sequenznummern, Alert Meldungen, etc.) Protokoll besteht aus 2 Nachrichten: ChangeCipherSpec Nachricht: Alle folgenden Nachrichten mit neuer CipherSuite Finished Nachricht: MAC über alle bisher erhaltenen Nachrichten Handshake - Protokoll
26 May Systems Architecture Optionale Phasen Server sendet kein Zertifikat, sondern temporären öffentlichen Schlüssel Handshake - Protokoll Webserver Alice ClientHello ServerHello Certificate ServerHelloDone Handshake - Protokoll ServerKeyExchange
27 May Systems Architecture Optionale Phasen Server kann vom Client ein Zertifikat verlangen Handshake - Protokoll Webserver Alice ServerHello Certificate ServerHelloDone Handshake - Protokoll Certificate Request ClientKeyExchange Certificate CertificateVerify
28 May Systems Architecture Vergleich SSL 3.0 und TLS 1.0 TLS 1.0 Internetstandard der IETF keine grundlegenden Änderungen von TLS 1.0 gegenüber SSL 3.0, deshalb im Versionsfeld der SSL-Nachrichten 3.1 zwölf neue Alert-Nachrichten Änderungen bzgl.: - Nachrichten-Authentifikation - Ereugung des Schlüsselmaterials - CertificateVerify und Finished-Nachricht - Fortezza-Ciphersuites nicht mehr zwingender Bestandteil der Ciphersuites Vergleich SSL und TLS
29 May Systems Architecture Vergleich SSL 3.0 und TLS 1.0 (forts.) CertificateVerify (CV) Berechnung der CertificateVerify Nachricht gegenüber SSL stark vereinfacht Nachricht besteht nur noch aus dem signierten Hashwert aller ausgetauschten Handshake-Nachrichten (ClientHello bis CV-Nachricht) Authentifikation der Nachrichten TLS verwendet das kryptografisch stärkere HMAC-Verfahren gegenüber den ad hoc-Lösungen bei SSL Vergleich SSL und TLS
30 May Systems Architecture Vergleich SSL 3.0 und TLS 1.0 (forts.) TLS Ciphersuites neu definierte Ciphersuites müssen von der IETF einen eindeutigen Namen erhalten in Form eines 2-Byte-Werts bei SSL war Namensvergabe ein Problem, da nicht eindeutig geregelt (Bytewerte zum Teil doppelt belegt) 0x00,0x00TLS_NULL_WITH_NULL_NULL 0x00,0x01TLS_RSA_WITH_NULL_MD5... 0x00,0x06TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5... 0x00,0x13TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA... Algorithmen für die digitale Signatur und den Schlüsselaustausch während des Handshakes symmetrische Verschlüsselungsalgorithmus und sein Modus, sowie ausgewählte Hashfunktion Vergleich SSL und TLS
31 May Systems Architecture Erweiterungen von TLS TLS wurde im RFC 4366 um einige Funktionen erweitert: Unterstützung von namensbasierten virtuellen Hosts Diverse Erweiterungen zum Einsatz auf Systemen mit begrenzten Ressourcen Erweiterungen von TLS
32 May Systems Architecture TLS und virtuelle Hosts Webserver www1.domain.de www2.domain.de Was sind virtuelle Hosts? Erweiterungen von TLS
33 May Systems Architecture TLS und virtuelle Hosts Problem bei namensbasierten virtuellen Hosts: - Name des Hosts auf TLS Ebene nicht bekannt - Welches Zertifikat soll bei einer Anfrage übermittelt werden? Lösung: - Erweiterung der ClientHello Nachricht - Name des Zielhosts wird beim ClientHello mitgeschickt Erweiterungen von TLS
34 May Systems Architecture TLS bei begrenzten Ressourcen MaximumFragmentSize: Aushandeln der Fragmentgröße bei Bandbreiten- oder Speicherbegrenzung ClientCertificateURLs: Übermittlung einer URL zum Zertifikat, statt Zertifikat selbst CA Root Keys: Übermittlung welche Root CA Keys der Client besitzt Truncated MAC: HMAC wird auf 80 Bit gekürzt um Bandbreite zu sparen Client Certificate Status Information: Certficate Revocation List muss nicht gesendet werden Erweiterungen von TLS
35 May Systems Architecture Zusammenfassung Vertraulichkeit -> durch symetrische Verschlüsselung im Record Layer Authentizität -> durch (H)MAC-Bildung im Record Layer Authentifikation der Kommunikationspartner -> durch Austausch von Zertifikaten im Handshake-Protokoll
36 May Systems Architecture Quellenverzeichnis T. Dierks, E. Rescorla: RFC The Transport Layer Security (TLS) Protocol Version [ ] Blake-Wilson, u.a. : RFC Transport Layer Security (TLS) Extensions. [ ]. Eckert, Claudia: IT-Sicherheit. Konzepte-Verfahren-Protokolle. 4. Auflage. München: Oldenbourg Verlag, 2006 Schwenk, Jörg: Sicherheit und Kryptographie im Internet. 2. Auflage. Wiesbaden: Vieweg Verlag, 2005 Anonymous: Der neue Linux Hacker's Guide Sicherheit für Linux-Server und -Netze, Markt+Technik Verlag, 2001
Systems Architecture Comparison SSL/TLS, TLS for multiple virtual hosts Vielen Dank für Ihre Aufmerksamkeit! Dominik Oepen, Dennis Reinert