|
|
| (24 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| '''Transport Layer Security''' (TLS) - Kurzbeschreibung | | '''Transport Layer Security''' (TLS) - Transportschichtsicherheit |
|
| |
|
| == Beschreibung == | | == Beschreibung == |
| {| class="float" | | {| class="float wikitable" |
| |+TLS im [https://de.wikipedia.org/wiki/TCP/IP-Referenzmodell TCP/IP-Protokollstapel] | | |+ TLS im [[TCP/IP-Referenzmodell|TCP/IP-Protokollstapel]] |
| |''Anwendung'' | | |- style="background:#DDDDFF;" |
| |[https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure HTTPS] | | |style="background:#FFEEBB"| ''Anwendung''<br /> |
| |[https://de.wikipedia.org/wiki/Internet_Message_Access_Protocol#IMAPS IMAPS] | | | [[Hypertext Transfer Protocol Secure|HTTPS]] |
| |[https://de.wikipedia.org/wiki/POP3S POP3S] | | | [[Internet Message Access Protocol#IMAPS|IMAPS]] |
| |[https://de.wikipedia.org/wiki/SMTPS SMTPS] | | | [[POP3S]] |
| |… | | | [[SMTPS]] |
| | | … |
| |- | | |- |
| | | | |style="background:#FFCC99;"| |
| | colspan="5" |'''TLS''' | | |colspan="5" style="background:#9999FF"| '''TLS''' |
| |- | | |- |
| |''Transport'' | | |style="background:#FFEEBB;"| ''Transport'' |
| | colspan="5" |[https://de.wikipedia.org/wiki/Transmission_Control_Protocol TCP] | | |colspan="5" style="background:#EEEEEE;"| [[Transmission Control Protocol|TCP]] |
| |- | | |- style="background:#EEEEEE;" |
| |''Internet'' | | |style="background:#FFEEBB;"| ''Internet'' |
| | colspan="5" |[https://de.wikipedia.org/wiki/Internet_Protocol IP] ([https://de.wikipedia.org/wiki/IPv4 IPv4], [https://de.wikipedia.org/wiki/IPv6 IPv6]) | | |colspan="5"| [[Internet Protocol|IP]] ([[IPv4]], [[IPv6]]) |
| |- | | |- style="background:#EEEEEE;" |
| |''Netzzugang'' | | |style="background:#FFEEBB"| ''Netzzugang'' |
| |[https://de.wikipedia.org/wiki/Ethernet Ethernet] | | | [[Ethernet]] |
| |[https://de.wikipedia.org/wiki/Token_Bus TokenBus] | | | [[Token Bus|Token<br />Bus]] |
| |[https://de.wikipedia.org/wiki/Token_Ring TokenRing] | | | [[Token Ring|Token<br />Ring]] |
| |[https://de.wikipedia.org/wiki/Fiber_Distributed_Data_Interface FDDI] | | |
| |… | | | [[Fiber Distributed Data Interface|FDDI]] |
| | | … |
| |} | | |} |
| | '''Transport Layer Security''' ('''TLS''', {{enS}} für „Transportschichtsicherheit“) |
| | |
| | * Bekannt unter der Vorgängerbezeichnung '''Secure Sockets Layer''' ('''SSL''') |
| | * [https://de.wikipedia.org/wiki/Verschl%C3%BCsselungsprotokoll Verschlüsselungsprotokoll] zur sicheren [https://de.wikipedia.org/wiki/Daten%C3%BCbertragung Datenübertragung] im [https://de.wikipedia.org/wiki/Internet Internet] |
| | |
| | ; Hauptkomponenten |
| | TLS besteht aus den beiden Hauptkomponenten TLS Handshake und TLS Record |
| | * Im TLS Handshake findet ein sicherer [https://de.wikipedia.org/wiki/Schl%C3%BCsselaustausch Schlüsselaustausch] und eine [https://de.wikipedia.org/wiki/Authentifizierung Authentifizierung] statt |
| | * TLS Record verwendet dann den im TLS Handshake ausgehandelten symmetrischen Schlüssel für eine sichere Datenübertragung – die Daten werden verschlüsselt und mit einem [https://de.wikipedia.org/wiki/Message_Authentication_Code MAC] gegen Veränderungen geschützt übertragen |
|
| |
|
| '''Transport Layer Security''' ('''TLS''', {{enS}} für „Transportschichtsicherheit“), auch bekannt unter der Vorgängerbezeichnung '''Secure Sockets Layer''' ('''SSL'''), ist ein [https://de.wikipedia.org/wiki/Verschl%C3%BCsselungsprotokoll Verschlüsselungsprotokoll] zur sicheren [https://de.wikipedia.org/wiki/Daten%C3%BCbertragung Datenübertragung] im [https://de.wikipedia.org/wiki/Internet Internet].
| | ; Schlüsselaustausch |
| | Für den [https://de.wikipedia.org/wiki/Schl%C3%BCsselaustausch Schlüsselaustausch] sind in den älteren TLS-Versionen verschiedene Algorithmen mit unterschiedlichen Sicherheitsgarantien im Einsatz |
| | * Die neueste Version TLS 1.3 verwendet allerdings nur noch das [https://de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustausch Diffie-Hellmanprotokoll] (DHE oder ECDHE) |
| | * Dabei wird für jede Verbindung ein neuer [https://de.wikipedia.org/wiki/Session_Key Sitzungsschlüssel] (Session Key) ausgehandelt |
| | * Da dies ohne Verwendung eines Langzeitschlüssels geschieht, erreicht TLS 1.3 [https://de.wikipedia.org/wiki/Perfect_Forward_Secrecy Perfect Forward Secrecy] |
|
| |
|
| TLS besteht aus den beiden Hauptkomponenten TLS Handshake und TLS Record. Im TLS Handshake findet ein sicherer [https://de.wikipedia.org/wiki/Schl%C3%BCsselaustausch Schlüsselaustausch] und eine [https://de.wikipedia.org/wiki/Authentifizierung Authentifizierung] statt. TLS Record verwendet dann den im TLS Handshake ausgehandelten symmetrischen Schlüssel für eine sichere Datenübertragung – die Daten werden verschlüsselt und mit einem [https://de.wikipedia.org/wiki/Message_Authentication_Code MAC] gegen Veränderungen geschützt übertragen.
| | === Vor- und Nachteile === |
| | Der Vorteil des TLS-Protokolls ist die Möglichkeit, jedes höhere Protokoll auf Basis des TLS-Protokolls zu implementieren |
| | * Damit ist eine Unabhängigkeit von Anwendungen und Systemen gewährleistet |
|
| |
|
| Für den [https://de.wikipedia.org/wiki/Schl%C3%BCsselaustausch Schlüsselaustausch] sind in den älteren TLS-Versionen verschiedene Algorithmen mit unterschiedlichen Sicherheitsgarantien im Einsatz. Die neueste Version TLS 1.3 verwendet allerdings nur noch das [https://de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustausch Diffie-Hellman-Schlüsselaustauschprotokoll] (DHE oder ECDHE). Dabei wird für jede Verbindung ein neuer [https://de.wikipedia.org/wiki/Session_Key Sitzungsschlüssel] (Session Key) ausgehandelt. Da dies ohne Verwendung eines Langzeitschlüssels geschieht, erreicht TLS 1.3 [https://de.wikipedia.org/wiki/Perfect_Forward_Secrecy Perfect Forward Secrecy].
| | Der Nachteil der TLS-verschlüsselten Übertragung besteht darin, dass der Verbindungsaufbau auf Serverseite rechenintensiv und deshalb langsamer ist |
| | * Die Verschlüsselung selbst beansprucht je nach verwendetem [https://de.wikipedia.org/wiki/Algorithmus Algorithmus] nur wenig Rechenzeit |
| | |
| | Verschlüsselte Daten sind auf niedrigeren Schichten (etwa auf [https://de.wikipedia.org/wiki/Point-to-Point_Tunneling_Protocol PPTP]-Ebene) kaum durch Kompression zu verdichten |
| | |
| | TLS verschlüsselt nur die Kommunikation zwischen zwei Stationen |
| | * Es sind Szenarien in [https://de.wikipedia.org/wiki/Serviceorientierte_Architektur serviceorientierten Architekturen] denkbar, in denen eine Nachricht über mehrere Stationen gesendet wird |
| | * Wenn jede Station nur einen Teil der Nachricht lesen darf, reicht TLS nicht aus, da jede Station alle Daten der Nachricht entschlüsseln kann |
| | * Somit entstehen Sicherheitslücken an jeder Station, die nicht für sie bestimmte Daten entschlüsseln kann |
|
| |
|
| == Implementierungen == | | == Implementierungen == |
| Zeile 48: |
Zeile 73: |
|
| |
|
| == TLS in der Praxis == | | == TLS in der Praxis == |
| TLS-Verschlüsselung wird gegenwärtig vor allem mit [https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure HTTPS] eingesetzt. Die meisten aktuellen [https://de.wikipedia.org/wiki/Webbrowser Webbrowser] und [https://de.wikipedia.org/wiki/Webserver Webserver] bevorzugen TLS 1.3 und TLS 1.2. Die älteren Versionen TLS 1.1 und TLS 1.0 werden nicht mehr unterstützt. | | TLS-Verschlüsselung wird gegenwärtig vor allem mit [https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure HTTPS] eingesetzt |
| | * Die meisten aktuellen [https://de.wikipedia.org/wiki/Webbrowser Webbrowser] und [https://de.wikipedia.org/wiki/Webserver Webserver] bevorzugen TLS 1.3 und TLS 1.2 |
| | * Die älteren Versionen TLS 1.1 und TLS 1.0 werden nicht mehr unterstützt |
| | * In aktuellen Browsern ist SSLv3 und SSLv2 deaktiviert, da diese Protokollversion eine Reihe von Sicherheitslücken, unter anderem des [https://de.wikipedia.org/wiki/Poodle Poodle-Angriffs] aufweist |
|
| |
|
| | | ; TLS 1.3 |
| In aktuellen Browsern ist SSLv3 und SSLv2 deaktiviert,
| |
| | |
| da diese Protokollversion eine Reihe von Sicherheitslücken, unter anderem des [https://de.wikipedia.org/wiki/Poodle Poodle-Angriffs] aufweist.
| |
|
| |
| Die Weiterentwicklung TLS 1.3 wird von allen nennenswert verbreiteten Browsern auf Desktops und Smartphones unterstützt | | Die Weiterentwicklung TLS 1.3 wird von allen nennenswert verbreiteten Browsern auf Desktops und Smartphones unterstützt |
| , TLS 1.2 wird von 98,7 Prozent aller Browserinstallationen unterstützt; Ausnahmen sind mehrere Jahre alte Versionen (Stand 02/2022). | | , TLS 1.2 wird von 98,7 Prozent aller Browserinstallationen unterstützt; Ausnahmen sind mehrere Jahre alte Versionen (Stand 02/2022) |
|
| |
|
| Das [https://de.wikipedia.org/wiki/Bundesamt_f%C3%BCr_Sicherheit_in_der_Informationstechnik Deutsche Bundesamt für Sicherheit in der Informationstechnik] empfiehlt bei der Verwendung von TLS die Versionen 1.2 und 1.3. [https://de.wikipedia.org/wiki/Cipher_Suite Cipher Suiten] mit [https://de.wikipedia.org/wiki/Perfect_Forward_Secrecy Perfect Forward Secrecy] werden bevorzugt empfohlen. | | Das [https://de.wikipedia.org/wiki/Bundesamt_f%C3%BCr_Sicherheit_in_der_Informationstechnik Deutsche Bundesamt für Sicherheit in der Informationstechnik] empfiehlt bei der Verwendung von TLS die Versionen 1.2 und 1.3. [https://de.wikipedia.org/wiki/Cipher_Suite Cipher Suiten] mit [https://de.wikipedia.org/wiki/Perfect_Forward_Secrecy Perfect Forward Secrecy] werden bevorzugt empfohlen |
|
| |
|
| Seit einiger Zeit nutzen immer mehr Webseitenbetreiber [https://de.wikipedia.org/wiki/Extended-Validation-Zertifikat Extended-Validation-TLS-Zertifikate] (EV-TLS-Zertifikat). In der Adresszeile des Browsers wird zusätzlich ein Feld angezeigt, in dem Zertifikats- und Domaininhaber im Wechsel mit der [https://de.wikipedia.org/wiki/Zertifizierungsstelle_(Digitale_Zertifikate) Zertifizierungsstelle] eingeblendet werden. Zudem wird je nach verwendetem Browser und/oder Add-on die Adresszeile (teilweise) grün eingefärbt. Internetnutzer sollen so schneller erkennen, ob die besuchte Webseite echt ist, und besser vor [https://de.wikipedia.org/wiki/Phishing Phishingversuchen] geschützt werden. EV-TLS-Zertifikate bieten in technischer Sicht keinen erweiterten Schutz, die Verschlüsselung und deren Stärke ist identisch. Nur der Inhaber wird dabei besser und aufwändiger verifiziert. Seit 2019 werden diese Zertifikate in den Browsern nicht mehr prominent hervorgehoben, weil der erwartete Sicherheitsgewinn für den Endbenutzer ausblieb. | | Seit einiger Zeit nutzen immer mehr Webseitenbetreiber [https://de.wikipedia.org/wiki/Extended-Validation-Zertifikat Extended-Validation-TLS-Zertifikate] (EV-TLS-Zertifikat) |
| | * In der Adresszeile des Browsers wird zusätzlich ein Feld angezeigt, in dem Zertifikats- und Domaininhaber im Wechsel mit der [https://de.wikipedia.org/wiki/Zertifizierungsstelle_(Digitale_Zertifikate) Zertifizierungsstelle] eingeblendet werden |
| | * Zudem wird je nach verwendetem Browser und/oder Add-on die Adresszeile (teilweise) grün eingefärbt |
| | * Internetnutzer sollen so schneller erkennen, ob die besuchte Webseite echt ist, und besser vor [https://de.wikipedia.org/wiki/Phishing Phishingversuchen] geschützt werden |
| | * EV-TLS-Zertifikate bieten in technischer Sicht keinen erweiterten Schutz, die Verschlüsselung und deren Stärke ist identisch |
| | * Nur der Inhaber wird dabei besser und aufwändiger verifiziert |
| | * Seit 2019 werden diese Zertifikate in den Browsern nicht mehr prominent hervorgehoben, weil der erwartete Sicherheitsgewinn für den Endbenutzer ausblieb |
|
| |
|
| Seit Januar 2017 markiert der Web-Browser Chrome Internetseiten als unsicher, die Informationen sammeln, ohne dabei HTTPS zu nutzen. Das wird voraussichtlich zu einem signifikanten Anstieg des Einsatzes von HTTPS führen. Im Februar 2017 war HTTPS bei 2,57 % aller registrierten deutschen Internet-Domains | | Seit Januar 2017 markiert der Web-Browser Chrome Internetseiten als unsicher, die Informationen sammeln, ohne dabei HTTPS zu nutzen |
|
| | * Das wird voraussichtlich zu einem signifikanten Anstieg des Einsatzes von HTTPS führen |
| sowie bei 3,70 % der österreichischen Domains
| | * Im Februar 2017 war HTTPS bei 2,57 % aller registrierten deutschen Internet-Domains |
| und 9,71 % der Schweizer Domains aktiviert. Eine Untersuchung von rund 40.000 Webseiten klein- und mittelständischer Unternehmen in Baden-Württemberg durch den Landesbeauftragten für den Datenschutz und die Informationsfreiheit Baden-Württemberg hat ergeben, dass rund 7 % der untersuchten Webseiten über HTTPS angeboten werden. Bei jenen Webseiten, die über HTTPS angeboten werden, ist die serverseitige Unterstützung für TLS 1.0 noch sehr weit verbreitet (99 %).
| |
|
| |
|
| | sowie bei 3,70 % der österreichischen Domains |
| | und 9,71 % der Schweizer Domains aktiviert |
| | * Eine Untersuchung von rund 40.000 Webseiten klein- und mittelständischer Unternehmen in Baden-Württemberg durch den Landesbeauftragten für den Datenschutz und die Informationsfreiheit Baden-Württemberg hat ergeben, dass rund 7 % der untersuchten Webseiten über HTTPS angeboten werden |
| | * Bei jenen Webseiten, die über HTTPS angeboten werden, ist die serverseitige Unterstützung für TLS 1.0 noch sehr weit verbreitet (99 %) |
|
| |
|
| TLS ist ohne eine zertifikatsbasierte Authentifizierung anfällig für [https://de.wikipedia.org/wiki/Man-in-the-Middle-Angriff Man-in-the-Middle-Angriffe]: Ist der Man-in-the-Middle vor der Übergabe des Schlüssels aktiv, kann er beiden Seiten seine Schlüssel vorgaukeln und so den gesamten Datenverkehr im Klartext aufzeichnen und unbemerkt manipulieren. Wegen der mangelnden Vertrauenswürdigkeit einiger Zertifizierungsstellen wird seit Anfang 2010 die Sicherheit von TLS grundsätzlich angezweifelt.
| |
|
| |
|
| | TLS ist ohne eine zertifikatsbasierte Authentifizierung anfällig für [https://de.wikipedia.org/wiki/Man-in-the-Middle-Angriff Man-in-the-Middle-Angriffe]: Ist der Man-in-the-Middle vor der Übergabe des Schlüssels aktiv, kann er beiden Seiten seine Schlüssel vorgaukeln und so den gesamten Datenverkehr im Klartext aufzeichnen und unbemerkt manipulieren |
| | * Wegen der mangelnden Vertrauenswürdigkeit einiger Zertifizierungsstellen wird seit Anfang 2010 die Sicherheit von TLS grundsätzlich angezweifelt |
|
| |
|
| | Durch die Deaktivierung fragwürdiger Zertifizierungsstellen im eigenen Browser lässt sich dieses Risiko jedoch weitgehend beseitigen |
|
| |
|
| Durch die Deaktivierung fragwürdiger Zertifizierungsstellen im eigenen Browser lässt sich dieses Risiko jedoch weitgehend beseitigen.
| | In Verbindung mit einem [https://de.wikipedia.org/wiki/Virtual_Hosting#IP_oder_namensbasiertes_Virtual_Hosting ''virtuellen Server''], zum Beispiel mit [https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP] (etwa beim [https://de.wikipedia.org/wiki/Apache_HTTP_Server Apache HTTP Server] über den ''VHost''-Mechanismus), ist es grundsätzlich als Nachteil zu werten, dass pro Kombination aus [https://de.wikipedia.org/wiki/IP-Adresse IP-Adresse] und [https://de.wikipedia.org/wiki/Port_(Netzwerkadresse) Port] nur ein Zertifikat verwendet werden kann, da die eigentlichen Nutzdaten des darüber liegenden Protokolls (und damit der Name des VHosts) zum Zeitpunkt des TLS-Handshakes noch nicht übertragen wurden |
| | * Dieses Problem wurde mit der TLS-Erweiterung [https://de.wikipedia.org/wiki/Server_Name_Indication Server Name Indication] (SNI) im Juni 2003 durch den <nowiki>RFC 3546</nowiki> behoben |
| | * Dabei wird bereits beim Verbindungsaufbau der gewünschte Servername mitgesendet |
| | * Die ursprüngliche Erweiterung wurde für TLS 1.0 beschrieben, aufgrund der Kompatibilität der einzelnen TLS-Versionen zueinander wird SNI auch bei TLS 1.1, Version 1.2 und 1.3 entsprechend der Empfehlung umgesetzt |
| | * In der Version 1.3 wird zusätzlich auch versucht, die SNI zu verschlüsseln, um mitzulesenden Parteien nicht zu ermöglichen, trotz verschlüsselter Verbindung Informationen über den Zielserver preiszugeben |
| | * Das muss jedoch vom Browser unterstützt, im [https://de.wikipedia.org/wiki/Domain_Name_System Domain Name System (DNS)] ein Schlüssel hinterlegt und verschlüsseltes DNS genutzt werden |
|
| |
|
| In Verbindung mit einem [https://de.wikipedia.org/wiki/Virtual_Hosting#IP_oder_namensbasiertes_Virtual_Hosting ''virtuellen Server''], zum Beispiel mit [https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP] (etwa beim [https://de.wikipedia.org/wiki/Apache_HTTP_Server Apache HTTP Server] über den ''VHost''-Mechanismus), ist es grundsätzlich als Nachteil zu werten, dass pro Kombination aus [https://de.wikipedia.org/wiki/IP-Adresse IP-Adresse] und [https://de.wikipedia.org/wiki/Port_(Netzwerkadresse) Port] nur ein Zertifikat verwendet werden kann, da die eigentlichen Nutzdaten des darüber liegenden Protokolls (und damit der Name des VHosts) zum Zeitpunkt des TLS-Handshakes noch nicht übertragen wurden. Dieses Problem wurde mit der TLS-Erweiterung [https://de.wikipedia.org/wiki/Server_Name_Indication Server Name Indication] (SNI) im Juni 2003 durch den <nowiki>RFC 3546</nowiki> behoben. Dabei wird bereits beim Verbindungsaufbau der gewünschte Servername mitgesendet. Die ursprüngliche Erweiterung wurde für TLS 1.0 beschrieben, aufgrund der Kompatibilität der einzelnen TLS-Versionen zueinander wird SNI auch bei TLS 1.1, Version 1.2 und 1.3 entsprechend der Empfehlung umgesetzt. In der Version 1.3 wird zusätzlich auch versucht, die SNI zu verschlüsseln, um mitzulesenden Parteien nicht zu ermöglichen, trotz verschlüsselter Verbindung Informationen über den Zielserver preiszugeben. Das muss jedoch vom Browser unterstützt, im [https://de.wikipedia.org/wiki/Domain_Name_System Domain Name System (DNS)] ein Schlüssel hinterlegt und verschlüsseltes DNS genutzt werden.
| | Im [https://de.wikipedia.org/wiki/Tor_(Netzwerk) Tor-Netzwerk] sind TLS-Zertifikate für Verbindungen in das Internet von besonderer Bedeutung, da ein Abhören einer unverschlüsselten Verbindung mittels [https://de.wikipedia.org/wiki/Man-in-the-Middle-Angriff Man-in-the-Middle-Angriff] dort durch den Rechner, der die Verbindung in das Internet herstellt (bezeichnet als „exit node“), sehr einfach möglich wäre |
| | | * Da eine Verbindung zwischen zwei Endpunkten im Tor-Netzwerks jedoch verschlüsselt ist, kann die verschlüsselte Übertragung von Daten innerhalb des Netzwerks nachrangig betrachtet werden, sofern man dem [https://de.wikipedia.org/wiki/Routing Routing] der Verbindungen vertraut |
| Im [https://de.wikipedia.org/wiki/Tor_(Netzwerk) Tor-Netzwerk] sind TLS-Zertifikate für Verbindungen in das Internet von besonderer Bedeutung, da ein Abhören einer unverschlüsselten Verbindung mittels [https://de.wikipedia.org/wiki/Man-in-the-Middle-Angriff Man-in-the-Middle-Angriff] dort durch den Rechner, der die Verbindung in das Internet herstellt (bezeichnet als „exit node“), sehr einfach möglich wäre. Da eine Verbindung zwischen zwei Endpunkten im Tor-Netzwerks jedoch verschlüsselt ist, kann die verschlüsselte Übertragung von Daten innerhalb des Netzwerks nachrangig betrachtet werden, sofern man dem [https://de.wikipedia.org/wiki/Routing Routing] der Verbindungen vertraut. Hier liegt das Hauptmerkmal der TLS-Verschlüsselung in der Authentizität der Gegenseite. | | * Hier liegt das Hauptmerkmal der TLS-Verschlüsselung in der Authentizität der Gegenseite |
|
| |
|
| Neben [https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure HTTPS] als verschlüsselte Variante von [https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP] sind weitere bekannte Anwendungsfälle für TLS beispielsweise: | | Neben [https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure HTTPS] als verschlüsselte Variante von [https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP] sind weitere bekannte Anwendungsfälle für TLS beispielsweise: |
| Zeile 95: |
Zeile 135: |
| * [https://de.wikipedia.org/wiki/DNS_over_TLS DNS over TLS], [https://de.wikipedia.org/wiki/DNS_over_HTTPS DNS over HTTPS] und [https://de.wikipedia.org/wiki/DNS_over_QUIC DNS over QUIC] um DNS Abfragen durch TLS zu tunneln | | * [https://de.wikipedia.org/wiki/DNS_over_TLS DNS over TLS], [https://de.wikipedia.org/wiki/DNS_over_HTTPS DNS over HTTPS] und [https://de.wikipedia.org/wiki/DNS_over_QUIC DNS over QUIC] um DNS Abfragen durch TLS zu tunneln |
|
| |
|
| Auch Verbindungen zu Datenbanksystemen können über TLS abgesichert werden. Dabei werden die Identität des Servers oder auch des Clients geprüft und die gesamte Kommunikation verschlüsselt. | | Auch Verbindungen zu Datenbanksystemen können über TLS abgesichert werden |
| | * Dabei werden die Identität des Servers oder auch des Clients geprüft und die gesamte Kommunikation verschlüsselt |
|
| |
|
| === Versionen === | | === Versionen === |
| {| class="wikitable big options" | | {| class="wikitable big options col1center" |
| ! Version !! Erscheinungsjahr !!Bemerkungen | | ! Version !! Erscheinungsjahr !!Bemerkungen |
| |-| {{Version|o|SSL 1.0}}
| |
| |1994
| |
| |
| |
| |-
| |
| |-| {{Version|o|SSL 2.0}}
| |
| |1995
| |
| |seit März 2011 überholt
| |
| |-| {{Version|o|SSL 3.0}}
| |
| |1996
| |
| |seit Juni 2015 überholt
| |
| |-| {{Version|o|TLS 1.0}}
| |
| |1999
| |
| |seit März 2021 überholt
| |
| |-| {{Version|o|TLS 1.1}}
| |
| |2006
| |
| |seit März 2021 überholt
| |
| |-| {{Version|co|TLS 1.2}}
| |
| |2008
| |
| |
| |
| |-| {{Version|c|TLS 1.3}}
| |
| |2018
| |
| |RFC 8446, enthält auch neue Anforderungen für TLS 1.2.
| |
| |}
| |
|
| |
| === Geschichte ===
| |
| Die erste Protokollversion von TLS wurde ab August 1986 im Rahmen des im September 1987 erstmals beschrieben Projektes ''Secure Data Network System (SDNS)'' entwickelt.
| |
| * 1994, neun Monate nach der ersten Ausgabe von [https://de.wikipedia.org/wiki/NCSA_Mosaic Mosaic], dem ersten verbreiteten [https://de.wikipedia.org/wiki/Webbrowser Webbrowser], stellte Netscape Communications die erste Version von SSL (1.0) fertig.
| |
| * Fünf Monate später wurde zusammen mit einer neuen Ausgabe des Netscape Navigator die nächste Version SSL 2.0 veröffentlicht.
| |
| * Ende 1995 veröffentlichte [https://de.wikipedia.org/wiki/Microsoft Microsoft] die erste Version seines Webbrowsers [https://de.wikipedia.org/wiki/Internet_Explorer Internet Explorer]. Kurz darauf wurde auch die erste Version ihres SSL-Pendants bekannt, PCT 1.0 (Private Communication Technology). PCT hatte einige Vorteile gegenüber SSL 2.0, die später in SSL 3.0 aufgenommen wurden.
| |
| * Im Sommer 1996 übergab Netscape die Versionskontrolle über sein Protokoll SSL 3.0 an die [https://de.wikipedia.org/wiki/Internet_Engineering_Task_Force IETF] zur Entwicklung eines Internet-Standards.
| |
|
| |
| Ab November 1996 entwickelte die [https://de.wikipedia.org/wiki/Internet_Engineering_Task_Force IETF] TLS WG auf Basis von Netscapes SSL 3.0 das verbesserte Protokoll „Transport Layer Security (TLS) Protocol Version 1.0“ (interne Versionsnummer 3.1), welches schließlich im Januar 1999 als RFC 2246 veröffentlicht wurde. Das finale Spezifikationsdokument von Netscapes SSL 3.0 war viele Jahre schwer zu finden und wurde im August 2011 nachträglich veröffentlicht als RFC 6101.
| |
| * Später wurde TLS durch weitere [https://de.wikipedia.org/wiki/Request_for_Comments RFCs] erweitert:
| |
| ** RFC 2712 – Addition of Kerberos Cipher Suites to Transport Layer Security (TLS).
| |
| ** RFC 2817 – Upgrading to TLS Within HTTP/1.1 erläutert die Benutzung des Upgrade-Mechanismus in HTTP/1.1, um Transport Layer Security (TLS) über eine bestehende [https://de.wikipedia.org/wiki/Transmission_Control_Protocol TCP]-Verbindung zu initialisieren. Dies erlaubt es, für unsicheren und für sicheren HTTP-Verkehr die gleichen „well-known“ TCP Ports (80 bzw. 443) zu benutzen.
| |
| ** RFC 2818 – HTTP Over TLS trennt sicheren von unsicherem Verkehr durch getrennte Server-TCP-Ports.
| |
| ** RFC 3268 – Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) nutzt die Erweiterbarkeit von TLS und fügt den symmetrischen Verschlüsselungsalgorithmen ([https://de.wikipedia.org/wiki/RC2_(Blockchiffre) RC2], [https://de.wikipedia.org/wiki/RC4 RC4], [https://de.wikipedia.org/wiki/International_Data_Encryption_Algorithm International Data Encryption Algorithm] (IDEA), [https://de.wikipedia.org/wiki/Data_Encryption_Standard Data Encryption Standard] (DES) und [https://de.wikipedia.org/wiki/Triple_DES Triple DES]) den [https://de.wikipedia.org/wiki/Advanced_Encryption_Standard Advanced Encryption Standard] (AES) hinzu.
| |
| ** <nowiki>RFC 3546</nowiki> – Transport Layer Security (TLS) Extensions führt das Konzept der Erweiterungen ein, wodurch optionale Datenfelder oder Header vor allem bei der anfänglichen Aushandlung übertragen werden können. Eine dieser Erweiterungen ist [https://de.wikipedia.org/wiki/Server_Name_Indication Server Name Indication].
| |
| * Im April 2006 wurde in RFC 4346 die Version 1.1 von TLS standardisiert und damit RFC 2246 obsolet. In TLS 1.1 wurden kleinere Sicherheitsverbesserungen vorgenommen und Unklarheiten beseitigt.
| |
| * Im August 2008 erschien mit RFC 5246 die Version 1.2 von TLS, welche RFC 4346 obsolet machte. Hierbei wurde die Festlegung auf MD5/SHA-1 in der [https://de.wikipedia.org/wiki/Pseudozuf%C3%A4llige_Funktion Pseudozufallsfunktion] (PRF) und bei signierten Elementen ersetzt durch flexiblere Lösungen, bei denen die Hash-Algorithmen spezifiziert werden können.
| |
| * Im Februar 2015 wurde RFC 7465
| |
|
| |
| * Im Mai 2015 wurden mit RFC 7525
| |
|
| |
| Empfehlungen zum sicheren Einsatz von TLS und [https://de.wikipedia.org/wiki/Datagram_Transport_Layer_Security DTLS] veröffentlicht. Demnach sollen SSLv2, SSLv3, RC4 und sonstige durch [https://de.wikipedia.org/wiki/Exportbeschr%C3%A4nkung Exportbeschränkungen] auf unter 112 Bit Schlüssellänge beschränkte Verschlüsselungsalgorithmen nicht verwendet werden. Vom Einsatz von [https://de.wikipedia.org/wiki/Triple_DES 3DES] zur Verschlüsselung und [https://de.wikipedia.org/wiki/RSA-Kryptosystem RSA] zum Schlüsselaustausch mit statischen Parametern wird abgeraten. Empfohlen werden [https://de.wikipedia.org/wiki/Cipher_Suite Cipher Suiten], die zum Schlüsselaustausch [https://de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustausch#Ephemeral_Diffie-Hellman Ephemeral Diffie-Hellman] kombiniert mit RSA verwenden, was [https://de.wikipedia.org/wiki/Perfect_Forward_Secrecy Forward Secrecy] (gegen späteres nachträgliches Entschlüsseln) bietet, zur Verschlüsselung AES im [https://de.wikipedia.org/wiki/Galois/Counter_Mode Galois/Counter Mode] mit 128 oder 256 Bit Schlüssellänge sowie die [https://de.wikipedia.org/wiki/Kryptologische_Hashfunktion Hashfunktion] SHA-256 oder SHA-384 für die Pseudozufallsfunktion von TLS.
| |
|
| |
| * Im August 2018 wurde in RFC 8446 TLS-Version 1.3 veröffentlicht, das seit 2014 entwickelt wurde.
| |
| * Im Oktober 2018 gaben die Hersteller der Browser Firefox, Chrome, Edge und Safari an, die in die Jahre gekommenen Protokolle TLS 1.0 und 1.1 beginnend ab März 2020 nicht mehr zu unterstützen.
| |
|
| |
| == Funktionsweise ==
| |
| Der Client baut eine Verbindung zum Server auf. Der Server authentifiziert sich gegenüber dem Client mit einem [https://de.wikipedia.org/wiki/Digitales_Zertifikat Zertifikat]. Der Client überprüft hierbei die Vertrauenswürdigkeit des [https://de.wikipedia.org/wiki/X.509 X.509]-Zertifikats und ob der Servername mit dem Zertifikat übereinstimmt. Optional kann sich der Client mit einem eigenen Zertifikat auch gegenüber dem Server authentifizieren. Dann schickt entweder der Client dem Server eine mit dem öffentlichen Schlüssel des Servers verschlüsselte geheime [https://de.wikipedia.org/wiki/Zufallszahl Zufallszahl], oder die beiden Parteien berechnen mit dem [https://de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustausch Diffie-Hellman-Schlüsselaustausch] ein gemeinsames Geheimnis. Aus dem Geheimnis wird dann ein kryptographischer Schlüssel abgeleitet. Dieser Schlüssel wird in der Folge benutzt, um alle Nachrichten der Verbindung mit einem [https://de.wikipedia.org/wiki/Symmetrisches_Verschl%C3%BCsselungsverfahren symmetrischen Verschlüsselungsverfahren] zu verschlüsseln und zum Schutz von [https://de.wikipedia.org/wiki/Integrit%C3%A4t_(Informationssicherheit) Nachrichten-Integrität] und [https://de.wikipedia.org/wiki/Authentizit%C3%A4t Authentizität] durch einen [https://de.wikipedia.org/wiki/Message_Authentication_Code Message Authentication Code] abzusichern.
| |
|
| |
| === TLS-Protokolle im Protokollstapel ===
| |
| Im [https://de.wikipedia.org/wiki/OSI-Modell OSI-Modell] ist TLS in Schicht 5 (der Sitzungsschicht) angeordnet. Im TCP/IP-Modell ist TLS oberhalb der [https://de.wikipedia.org/wiki/Transportschicht Transportschicht] (zum Beispiel [https://de.wikipedia.org/wiki/Transmission_Control_Protocol TCP]) und unterhalb Anwendungsprotokollen wie [https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP] oder [https://de.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol SMTP] angesiedelt. In den Spezifikationen wird dies dann zum Beispiel als „HTTP over TLS“ bezeichnet. Sollen jedoch beide Protokolle zusammengefasst betrachtet werden, wird üblicherweise ein ''„S“ für Secure'' dem Protokoll der Anwendungsschicht angehängt (zum Beispiel [https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure HTTP'''S''']). TLS arbeitet transparent, so dass es leicht eingesetzt werden kann, um Protokollen ohne eigene Sicherheitsmechanismen abgesicherte Verbindungen zur Verfügung zu stellen. Zudem ist es erweiterbar, um Flexibilität und Zukunftssicherheit bei den verwendeten Verschlüsselungstechniken zu gewährleisten.
| |
|
| |
| Das TLS-Protokoll besteht aus zwei Schichten:
| |
| {| class="wikitable"
| |
| !TLS Handshake Protocol
| |
| !TLS Change Cipher Spec. Protocol
| |
| !TLS Alert Protocol
| |
| !TLS Application Data Protocol
| |
| |-
| |
| ! colspan="4" |TLS Record Protocol
| |
| |}
| |
|
| |
| === TLS Record Protocol ===
| |
| Das TLS Record Protocol ist die untere der beiden Schichten und dient zur Absicherung der Verbindung. Es setzt direkt auf der Transportschicht auf und bietet zwei verschiedene Dienste, die einzeln oder gemeinsam genutzt werden können:
| |
|
| |
| * [https://de.wikipedia.org/wiki/Ende-zu-Ende-Verschl%C3%BCsselung Ende-zu-Ende-Verschlüsselung] mittels [https://de.wikipedia.org/wiki/Symmetrisches_Kryptosystem symmetrischer Algorithmen]. Der verwendete Schlüssel wird dabei im Voraus über ein weiteres Protokoll (zum Beispiel das TLS Handshake Protocol) ausgehandelt und kann nur einmal für die jeweilige Verbindung verwendet werden. TLS unterstützt für die [https://de.wikipedia.org/wiki/Symmetrische_Verschl%C3%BCsselung symmetrische Verschlüsselung] unter anderem [https://de.wikipedia.org/wiki/Data_Encryption_Standard DES], [https://de.wikipedia.org/wiki/Triple_DES Triple DES] und [https://de.wikipedia.org/wiki/Advanced_Encryption_Standard AES]
| |
| * Sicherung der [https://de.wikipedia.org/wiki/Integrit%C3%A4t_(Informationssicherheit) Nachrichten-Integrität] und [https://de.wikipedia.org/wiki/Authentizit%C3%A4t Authentizität] durch einen [https://de.wikipedia.org/wiki/Message_Authentication_Code Message Authentication Code], in der Regel [https://de.wikipedia.org/wiki/Keyed-Hash_Message_Authentication_Code HMAC].
| |
|
| |
| Außerdem werden zu sichernde Daten in Blöcke von maximal 16.384 (2<sup>14</sup>) Byte fragmentiert und beim Empfänger wieder zusammengesetzt. Dabei schreibt der Standard vor, dass die Blockgröße diesen Wert nicht übersteigt, außer der Block ist komprimiert oder verschlüsselt – dann darf die Blockgröße um 1024 Byte (bei Kompression) bzw. 2048 Byte (bei Verschlüsselung) größer sein. Auch können die Daten vor dem Verschlüsseln und vor dem Berechnen der kryptografischen Prüfsumme komprimiert werden. Das Komprimierungsverfahren wird ebenso wie die kryptografischen Schlüssel mit dem TLS Handshake-Protokoll ausgehandelt.
| |
|
| |
| Der Aufbau einer TLS-Record-Nachricht lautet wie folgt: ''Content Type'' (1 Byte: ''Change Cipher Spec'' = 20, ''Alert'' = 21, ''Handshake'' = 22, ''Application Data'' = 23) | ''Protokollversion Major'' (1 Byte) | ''Protokollversion Minor'' (1 Byte) | ''Länge'' (1 Short bzw. zwei Byte)
| |
|
| |
| === TLS Handshake Protocol ===
| |
| [[Datei:SSL_handshake_with_two_way_authentication_with_certificates.svg|verweis=https://de.wikipedia.org/wiki/Datei:SSL_handshake_with_two_way_authentication_with_certificates.svg|mini|TLS-Handshake mit Zwei-Wege-Authentifizierung mittels Zertifikaten und RSA-Schlüsselaustausch]]
| |
| Das TLS Handshake Protocol baut auf dem TLS Record Protocol auf und erfüllt die folgenden Funktionen, noch bevor die ersten Bits des Anwendungsdatenstromes ausgetauscht wurden:
| |
|
| |
| * Aushandeln zu benutzender kryptografischer Algorithmen und Schlüssel. TLS unterstützt auch eine unverschlüsselte Übertragung.
| |
| * Identifikation und Authentifizierung der Kommunikationspartner auf Basis [https://de.wikipedia.org/wiki/Asymmetrisches_Kryptosystem asymmetrischer Verschlüsselungsverfahren] und [https://de.wikipedia.org/wiki/Public-Key-Infrastruktur Public-Key-Kryptografie]. Dieser Schritt ist optional eine Zwei-Wege-Authentifizierung (in diesem Fall wird manchmal von ''mutual TLS'' gesprochen), für gewöhnlich authentifiziert sich aber nur der [https://de.wikipedia.org/wiki/Server Server] gegenüber dem [https://de.wikipedia.org/wiki/Client Client].
| |
|
| |
| Der Handshake selbst kann in vier ''Phasen'' unterteilt werden:
| |
|
| |
| # Der Client schickt zum Server ein C''lientHello'', und der Server antwortet dem Client mit einem S''erverHello''. Die Parameter der Nachrichten sind:
| |
| #* die Version (die höchste vom Client unterstützte TLS-Protokoll-Version)
| |
| #* eine 32 Byte lange Zufallsinformation (4 Byte Timestamp + 28 Byte lange Zufallszahl), die später verwendet wird, um das ''pre-master-secret'' zu bilden (sie schützt damit vor [https://de.wikipedia.org/wiki/Replay-Attacke Replay-Attacken])
| |
| #* eine Session-ID
| |
| #* die zu verwendende [https://de.wikipedia.org/wiki/Cipher_Suite Cipher Suite] (Algorithmen für Schlüsselaustausch, Verschlüsselung und Authentifizierung)
| |
| #* Optional den gewünschten [https://de.wikipedia.org/wiki/Fully_Qualified_Domain_Name FQDN] für die Unterstützung von [https://de.wikipedia.org/wiki/Server_Name_Indication Server Name Indication]
| |
| #* in der TLS 1.3 Version (mit [https://de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustausch Diffie-Hellman-Schlüsselaustausch]) werden hier auch schon die Key-Shares übertragen, die den gemeinsamen Schlüssel definieren.
| |
| # Der Server identifiziert sich gegenüber dem Client. Hierzu wird per C''ertificate'' ein [https://de.wikipedia.org/wiki/X.509 X.509v]3-[https://de.wikipedia.org/wiki/Digitales_Zertifikat Zertifikat] an den Client geschickt, gefolgt von einem ''CertificateVerify'' (in einigen TLS Versionen). Die C''ertificateVerify'' Nachricht enthält eine Unterschrift von zuvor ausgetauschten Nachrichten. Damit beweist der Server, dass er einen [https://de.wikipedia.org/wiki/Asymmetrische_Verschl%C3%BCsselung Secret-Key] besitzt, der zu dem auf dem Server-Zertifikat enthaltenen [https://de.wikipedia.org/wiki/Public-Key-Kryptografie Public-Key] passt. Der Client prüft das Zertifikat und die Unterschrift. Bei Misserfolg bricht der Client die Verbindung ab. Außerdem kann der Server optional per ''CertificateRequest'' ein Zertifikat zur Client-Authentifizierung anfordern. Diese Phase darf nur weggelassen werden, wenn eine anonyme Cipher Suite ohne Authentifizierung verwendet wird.
| |
| # Das zuvor erhaltene Server-Zertifikat enthält den [https://de.wikipedia.org/wiki/Asymmetrisches_Kryptosystem öffentlichen Schlüssel] des Servers. Wird eine [https://de.wikipedia.org/wiki/Cipher_Suite Cipher Suite] mit [https://de.wikipedia.org/wiki/RSA-Kryptosystem RSA]-Schlüsselaustausch verwendet (siehe Abbildung), so wird das vom Client generierte ''pre-master-secret'' mit diesem öffentlichen Schlüssel verschlüsselt und kann vom Server mit dem nur ihm bekannten privaten Schlüssel wieder entschlüsselt werden. Alternativ kann hier auch der [https://de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustausch Diffie-Hellman-Schlüsselaustausch] verwendet werden, um ein gemeinsames ''pre-master-secret'' zu generieren. Werden die Diffie-Hellman-Geheimnisse von Server und Client während des Handshakes frisch und zufällig ausgehandelt, sind die Voraussetzungen für [https://de.wikipedia.org/wiki/Perfect_Forward_Secrecy Perfect Forward Secrecy] erfüllt. Nach der Übertragung des ''pre-master-secrets'' identifiziert sich der Client mittels Zertifikat gegenüber dem Server, sofern dieser einen ''CertificateRequest'' geschickt hat. Dazu schickt der Client per ''Certificate'' das Client-Zertifikat, gefolgt von einem ''CertificateVerify.'' Die ''CertificateVerify'' Nachricht enthält eine Unterschrift aller zuvor ausgetauschten Nachrichten. Damit beweist der Client gegenüber dem Server, dass er einen Secret-Key besitzt, der zu dem auf dem Client-Zertifikat enthaltenen Public-Key passt. Ab hier ist dem Server also bekannt, mit wem er kommuniziert.
| |
| # Diese Phase schließt den Handshake ab. Aus dem vorhandenen ''pre-master-secret'' kann das ''master secret'' abgeleitet werden, das einen einmaligen [https://de.wikipedia.org/wiki/Sitzungsschl%C3%BCssel Sitzungsschlüssel] ({{enS|session key}}) darstellt. Aus dem ''master secret'' werden wiederum Schlüssel abgeleitet, die zum Ver- und Entschlüsseln der Daten sowie für die Integritätsprüfung verwendet werden. Die Nachrichten, die die Kommunikationspartner sich nun gegenseitig zusenden, werden nur noch verschlüsselt übertragen. Falls sich der Server nicht im Schritt 2 via ''CertificateVerify'' authentifiziert hat, ist dem Client erst nach dem Erhalt der ersten verschlüsselten Nachricht bekannt, dass er mit dem rechtmäßigen Besitzer des Zertifikats kommuniziert.
| |
|
| |
| === TLS Change Cipher Spec Protocol ===
| |
| Das Change Cipher Spec Protocol besteht nur aus einer einzigen Nachricht. Diese Nachricht ist ein Byte groß und besitzt den Inhalt 1. Durch diese Nachricht teilt der Sender dem Empfänger mit, dass er in der aktiven Sitzung auf die im Handshake Protocol ausgehandelte [https://de.wikipedia.org/wiki/Cipher_Suite Cipher Suite] wechselt. Ein wesentlicher Grund für die Definition eines eigenen Protokolls für diese Nachricht besteht darin, dass TLS-Implementierungen mehrere Nachrichten eines Protokolls in einem Record (also einer TLS-Dateneinheit) zusammenfassen können. Für die Nachricht „Change Cipher Spec“ ist das unerwünscht. Weil Records verschiedener Protokolle nicht zusammengefasst werden dürfen, ist das Problem durch Definition eines eigenen Protokolls gelöst.
| |
|
| |
| === TLS Alert Protocol ===
| |
| Das ''Alert Protocol'' unterscheidet etwa zwei Dutzend verschiedene Mitteilungen. Eine davon teilt das Ende der Sitzung mit (close_notify). Andere beziehen sich zum Beispiel auf die Protokollsyntax oder die Gültigkeit der verwendeten Zertifikate. Es wird zwischen Warnungen und Fehlern unterschieden, wobei letztere die Verbindung sofort beenden.
| |
|
| |
| Der Aufbau einer Fehlermeldung lautet wie folgt: ''AlertLevel'' (1 Byte: ''Warning'' = 1, ''Fatal'' = 2) | ''AlertDescription'' (1 Byte: ''close_notify'' = 0, […], ''no_renegotiation'' = 100).
| |
|
| |
| In der Spezifikation von TLS werden die folgenden schweren Fehlertypen definiert:
| |
| {| class="wikitable options big"
| |
| |unexpected_message
| |
| |Unpassende Nachricht wurde empfangen.
| |
| |-
| |
| |bad_record_mac
| |
| |Ein falscher [https://de.wikipedia.org/wiki/Message_Authentication_Code MAC] wurde empfangen.
| |
| |-
| |
| |decompression_failure
| |
| |Dekomprimierungsalgorithmus empfing unkorrekte Daten.
| |
| |-
| |
| |handshake_failure
| |
| |Absender konnte keine akzeptable Menge von Sicherheitsparametern bearbeiten.
| |
| |- | | |- |
| |illegal_parameter | | | SSL 1.0 || 1994 || |
| |Ein Feld in der Handshake-Nachricht lag außerhalb des erlaubten Bereichs oder stand im Widerspruch mit anderen Feldern.
| |
| |} | |
| | |
| ; In der Spezifikation von TLS werden die folgenden Warnungen definiert:
| |
| {| class="wikitable options big"
| |
| |close_notify | |
| |Teilt Empfänger mit, dass Absender keine weiteren Nachrichten auf dieser Verbindung senden wird. Muss von jedem Partner einer Verbindung als letzte Nachricht gesendet werden. | |
| |- | | |- |
| |no_certificate | | | SSL 2.0 || 1995 || seit März 2011 überholt |
| |Kann als Antwort auf eine Zertifikatanforderung gesendet werden, falls passendes Zertifikat nicht verfügbar ist. (Wurde in TLS 1.0 entfernt)
| |
| |- | | |- |
| |bad_certificate | | | SSL 3.0 || 1996 || |seit Juni 2015 überholt |
| |Empfangenes Zertifikat war unvollständig oder falsch. | |
| |- | | |- |
| |unsupported_certificate | | | TLS 1.0 || 1999 || seit März 2021 überholt |
| |Der Typ des empfangenden Zertifikats wird nicht unterstützt. | |
| |- | | |- |
| |certificate_revoked | | | TLS 1.1 || 2006 || seit März 2021 überholt |
| |Zertifikat wurde vom Unterzeichner zurückgerufen. | |
| |- | | |- |
| |certificate_expired | | | TLS 1.2 || 2008 || |
| |Zertifikat ist abgelaufen. | |
| |- | | |- |
| |certificate_unknown | | | TLS 1.3 || 2018 || RFC 8446, enthält auch neue Anforderungen für TLS 1.2 |
| |Andere, nicht genau spezifizierte Gründe sind beim Bearbeiten des Zertifikats aufgetreten, die dazu führen, dass das Zertifikat als ungültig gekennzeichnet wurde. | |
| |} | | |} |
|
| |
|
| ; In der Spezifikation von TLS 1.0 wurden folgende Warnungen ergänzt:
| | === Geschichte === |
| {| class="wikitable options big"
| | [[Transport Layer Security/Geschichte]] |
| |decryption_failed
| |
| |Entschlüsselung fehlgeschlagen.
| |
| |-
| |
| |record_overflow
| |
| |
| |
| |-
| |
| |unknown_ca
| |
| |Unbekannte oder nicht vertrauenswürdige CA.
| |
| |-
| |
| |access_denied
| |
| |Zugriff verweigert.
| |
| |-
| |
| |decode_error
| |
| |Decodierungsfehler.
| |
| |-
| |
| |decrypt_error
| |
| |Entschlüsselungsfehler.
| |
| |-
| |
| |export_restriction
| |
| |Exportbeschränkung.
| |
| |-
| |
| |protocol_version
| |
| |Veraltete Version von TLS/SSL.
| |
| |-
| |
| |insufficient_security
| |
| |Unzureichende Sicherheit.
| |
| |-
| |
| |internal_error
| |
| |Interner Fehler.
| |
| |-
| |
| |user_canceled
| |
| |Abbruch durch Benutzer.
| |
| |-
| |
| |no_renegotiation
| |
| |
| |
| |}
| |
|
| |
|
| === TLS Application Data Protocol === | | == Funktionsweise == |
| Die Anwendungsdaten werden über das Record Protocol transportiert, in Teile zerlegt, komprimiert und in Abhängigkeit vom aktuellen Zustand der Sitzung auch verschlüsselt. Inhaltlich werden sie von TLS nicht näher interpretiert.
| | [[Transport Layer Security/Funktionsweise]] |
| | |
| === Berechnung des Master Secrets ===
| |
| Aus dem ''pre-master-secret'' wird in früheren Protokollversionen mit Hilfe der [https://de.wikipedia.org/wiki/Hashfunktion Hashfunktionen] [https://de.wikipedia.org/wiki/SHA-1 SHA-1] und [https://de.wikipedia.org/wiki/MD5 MD5], in TLS 1.2 mit Hilfe einer durch eine ''Cipher Suite'' spezifizierten Pseudozufallsfunktion das ''Master Secret'' berechnet. In diese Berechnung fließen zusätzlich die Zufallszahlen der Phase 1 des Handshakes mit ein. Die Verwendung beider Hash-Funktionen sollte sicherstellen, dass das ''Master Secret'' immer noch geschützt ist, falls eine der Funktionen als kompromittiert gilt. In TLS 1.2 wird dieser Ansatz durch die flexible Austauschbarkeit der Funktion ersetzt.
| |
|
| |
|
| == Sicherheit == | | == Sicherheit == |
| [[TLS/Sicherheit]] | | [[TLS/Sicherheit]] |
|
| |
| == Vor- und Nachteile ==
| |
| Der Vorteil des TLS-Protokolls ist die Möglichkeit, jedes höhere Protokoll auf Basis des TLS-Protokolls zu implementieren. Damit ist eine Unabhängigkeit von Anwendungen und Systemen gewährleistet.
| |
|
| |
| Der Nachteil der TLS-verschlüsselten Übertragung besteht darin, dass der Verbindungsaufbau auf Serverseite rechenintensiv und deshalb langsamer ist. Die Verschlüsselung selbst beansprucht je nach verwendetem [https://de.wikipedia.org/wiki/Algorithmus Algorithmus] nur wenig Rechenzeit.
| |
|
| |
| Verschlüsselte Daten sind auf niedrigeren Schichten (etwa auf [https://de.wikipedia.org/wiki/Point-to-Point_Tunneling_Protocol PPTP]-Ebene) kaum durch Kompression zu verdichten.
| |
|
| |
| TLS verschlüsselt nur die Kommunikation zwischen zwei Stationen. Es sind Szenarien in [https://de.wikipedia.org/wiki/Serviceorientierte_Architektur serviceorientierten Architekturen] denkbar, in denen eine Nachricht über mehrere Stationen gesendet wird. Wenn jede Station nur einen Teil der Nachricht lesen darf, reicht TLS nicht aus, da jede Station alle Daten der Nachricht entschlüsseln kann. Somit entstehen Sicherheitslücken an jeder Station, die nicht für sie bestimmte Daten entschlüsseln kann.
| |
|
| |
|
| <noinclude> | | <noinclude> |
| Zeile 313: |
Zeile 177: |
| ===== Weblinks ===== | | ===== Weblinks ===== |
| # https://de.wikipedia.org/wiki/Transport_Layer_Security | | # https://de.wikipedia.org/wiki/Transport_Layer_Security |
|
| |
| = TMP =
| |
| {| class="float-right" style="text-align:center; margin-top:0;"
| |
| |+ TLS im [[TCP/IP-Referenzmodell|TCP/IP-Protokollstapel]]
| |
| |- style="background:#DDDDFF;"
| |
| |style="background:#FFEEBB"| ''Anwendung''<br />
| |
| | [[Hypertext Transfer Protocol Secure|HTTPS]]
| |
| | [[Internet Message Access Protocol#IMAPS|IMAPS]]
| |
| | [[POP3S]]
| |
| | [[SMTPS]]
| |
| | …
| |
| |-
| |
| |style="background:#FFCC99;"|
| |
| |colspan="5" style="background:#9999FF"| '''TLS'''
| |
| |-
| |
| |style="background:#FFEEBB;"| ''Transport''
| |
| |colspan="5" style="background:#EEEEEE;"| [[Transmission Control Protocol|TCP]]
| |
| |- style="background:#EEEEEE;"
| |
| |style="background:#FFEEBB;"| ''Internet''
| |
| |colspan="5"| [[Internet Protocol|IP]] ([[IPv4]], [[IPv6]])
| |
| |- style="background:#EEEEEE;"
| |
| |style="background:#FFEEBB"| ''Netzzugang''
| |
| | [[Ethernet]]
| |
| | [[Token Bus|Token<br />Bus]]
| |
| | [[Token Ring|Token<br />Ring]]
| |
| | [[Fiber Distributed Data Interface|FDDI]]
| |
| | …
| |
| |}
| |
|
| |
| '''Transport Layer Security''' ('''TLS''', {{enS}} für „Transportschichtsicherheit“), auch bekannt unter der Vorgängerbezeichnung '''Secure Sockets Layer''' ('''SSL'''), ist ein [[Verschlüsselungsprotokoll]] zur sicheren [[Datenübertragung]] im [[Internet]].
| |
|
| |
| TLS besteht aus den beiden Hauptkomponenten TLS Handshake und TLS Record. Im TLS Handshake findet ein sicherer [[Schlüsselaustausch]] und eine [[Authentifizierung]] statt. TLS Record verwendet dann den im TLS Handshake ausgehandelten symmetrischen Schlüssel für eine sichere Datenübertragung – die Daten werden verschlüsselt und mit einem [[Message Authentication Code|MAC]] gegen Veränderungen geschützt übertragen.
| |
|
| |
| Für den [[Schlüsselaustausch]] sind in den älteren TLS-Versionen verschiedene Algorithmen mit unterschiedlichen Sicherheitsgarantien im Einsatz. Die neueste Version TLS 1.3<ref name="RFC8446" /> verwendet allerdings nur noch das [[Diffie-Hellman-Schlüsselaustausch]]protokoll (DHE oder ECDHE). Dabei wird für jede Verbindung ein neuer [[Session Key|Sitzungsschlüssel]] (Session Key) ausgehandelt. Da dies ohne Verwendung eines Langzeitschlüssels geschieht, erreicht TLS 1.3 [[Perfect Forward Secrecy]].
| |
|
| |
| == TLS in der Praxis ==
| |
|
| |
| TLS-Verschlüsselung wird gegenwärtig vor allem mit [[Hypertext Transfer Protocol Secure|HTTPS]] eingesetzt. Die meisten aktuellen [[Webbrowser]] und [[Webserver]] bevorzugen TLS 1.3 und TLS 1.2. Die älteren Versionen TLS 1.1 und TLS 1.0 werden nicht mehr unterstützt.<ref name="Wood">{{Internetquelle |autor=Christopher Wood |url=https://webkit.org/blog/8462/deprecation-of-legacy-tls-1-0-and-1-1-versions/ |titel=Deprecation of Legacy TLS 1.0 and 1.1 Versions |werk=WebKit |hrsg= |datum=2018-10-15 |abruf=2020-08-18}}</ref><ref name="Thomson">{{Internetquelle |autor=Martin Thomson |url=https://blog.mozilla.org/security/2018/10/15/removing-old-versions-of-tls |titel=Removing Old Versions of TLS |sprache=en-US |abruf=2020-08-18}}</ref><ref name="ChromePlatformStatus">{{Internetquelle |url=https://www.chromestatus.com/feature/5759116003770368 |titel=TLS 1.0 and TLS 1.1 |werk=Chrome Platform Status |abruf=2020-08-18}}</ref> In aktuellen Browsern ist SSLv3 und SSLv2 deaktiviert,<ref>{{Internetquelle |url=https://support.mozilla.org/de/kb/Firefox%20kann%20keine%20sichere%20Verbindung%20aufbauen%20weil%20die%20Website%20eine%20%c3%a4ltere%20unsichere%20Version%20des%20SSL-Protokolls%20verwendet |titel=Firefox kann keine sichere Verbindung aufbauen weil die Website eine ältere unsichere Version des SSL-Protokolls verwendet |abruf=2016-01-19}}</ref> da diese Protokollversion eine Reihe von Sicherheitslücken, unter anderem des [[Poodle|Poodle-Angriffs]] aufweist.<ref>{{Internetquelle |url=https://lists.alioth.debian.org/pipermail/pkg-mozilla-maintainers/2005-April/000024.html |titel=SSLv2 insecure – should be disabled by default |abruf=2016-01-19}}</ref><ref>{{Internetquelle |url=https://www.gnutls.org/manual/html_node/On-SSL-2-and-older-protocols.html |titel=On SSL 2 and older protocols |abruf=2016-01-19}}</ref> Die Weiterentwicklung TLS 1.3 wird von allen nennenswert verbreiteten Browsern auf Desktops und Smartphones unterstützt<ref>{{Internetquelle |url=https://caniuse.com/?search=tls%201.3 |titel=Can I use... Support tables for HTML5, CSS3, etc |abruf=2021-03-29}}</ref>, TLS 1.2 wird von 98,7 Prozent aller Browserinstallationen unterstützt; Ausnahmen sind mehrere Jahre alte Versionen (Stand 02/2022).<ref>{{Internetquelle |url=https://caniuse.com/?search=tls%201.2 |titel=Can I use... Support tables for HTML5, CSS3, etc |abruf=2022-02-13}}</ref>
| |
|
| |
| Das [[Bundesamt für Sicherheit in der Informationstechnik|Deutsche Bundesamt für Sicherheit in der Informationstechnik]] empfiehlt bei der Verwendung von TLS die Versionen 1.2 und 1.3. [[Cipher Suite]]n mit [[Perfect Forward Secrecy]] werden bevorzugt empfohlen.<ref>{{Internetquelle |autor= |url=https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.html |titel=TR-02102-2 Kryptographische Verfahren: Empfehlungen und Schlüssellängen |werk= |hrsg=[[Bundesamt für Sicherheit in der Informationstechnik]] |datum=2019-02-22 |abruf=2020-03-06}}</ref>
| |
|
| |
| Seit einiger Zeit nutzen immer mehr Webseitenbetreiber [[Extended-Validation-Zertifikat|Extended-Validation-TLS-Zertifikate]] (EV-TLS-Zertifikat). In der Adresszeile des Browsers wird zusätzlich ein Feld angezeigt, in dem Zertifikats- und Domaininhaber im Wechsel mit der [[Zertifizierungsstelle (Digitale Zertifikate)|Zertifizierungsstelle]] eingeblendet werden. Zudem wird je nach verwendetem Browser und/oder Add-on die Adresszeile (teilweise) grün eingefärbt. Internetnutzer sollen so schneller erkennen, ob die besuchte Webseite echt ist, und besser vor [[Phishing]]versuchen geschützt werden. EV-TLS-Zertifikate bieten in technischer Sicht keinen erweiterten Schutz, die Verschlüsselung und deren Stärke ist identisch. Nur der Inhaber wird dabei besser und aufwändiger verifiziert. Seit 2019 werden diese Zertifikate in den Browsern nicht mehr prominent hervorgehoben, weil der erwartete Sicherheitsgewinn für den Endbenutzer ausblieb.<ref>{{Internetquelle |url=https://www.golem.de/sonstiges/zustimmung/auswahl.html?from=https%3A%2F%2Fwww.golem.de%2Fnews%2Fextended-validation-browser-wollen-teure-zertifikate-nicht-mehr-hervorheben-1908-143151.html |titel=Golem.de: IT-News für Profis |abruf=2021-03-29}}</ref>
| |
|
| |
| Seit Januar 2017 markiert der Web-Browser Chrome Internetseiten als unsicher, die Informationen sammeln, ohne dabei HTTPS zu nutzen. Das wird voraussichtlich zu einem signifikanten Anstieg des Einsatzes von HTTPS führen. Im Februar 2017 war HTTPS bei 2,57 % aller registrierten deutschen Internet-Domains<ref>{{Internetquelle |url=https://www.reflecte.de/deutsch-internet-statistiken |titel=Deutsch Internet Statistiken reflecte.de |sprache=de |offline=1 |archiv-url=https://web.archive.org/web/20170214002858/https://www.reflecte.de/deutsch-internet-statistiken |archiv-datum=2017-02-14 |archiv-bot=2019-05-19 05:37:52 InternetArchiveBot |abruf=2017-02-22}}</ref> sowie bei 3,70 % der österreichischen Domains<ref>{{Internetquelle |url=https://www.reflecte.at/osterreichisch-internet-statistiken |titel=Österreichisch Internet Statistiken reflecte.at |sprache=de |offline=1 |archiv-url=https://web.archive.org/web/20170214004415/https://www.reflecte.at/osterreichisch-internet-statistiken |archiv-datum=2017-02-14 |archiv-bot=2019-05-19 05:37:52 InternetArchiveBot |abruf=2017-02-22}}</ref> und 9,71 % der Schweizer Domains<ref>{{Internetquelle |url=https://www.avidom.ch/schweizerisch-internet-statistiken |titel=Schweizerisch Internet Statistiken avidom.ch |sprache=de |offline=1 |archiv-url=https://web.archive.org/web/20170214011451/https://www.avidom.ch/schweizerisch-internet-statistiken |archiv-datum=2017-02-14 |archiv-bot=2019-05-19 05:37:52 InternetArchiveBot |abruf=2017-02-22}}</ref> aktiviert. Eine Untersuchung von rund 40.000 Webseiten klein- und mittelständischer Unternehmen in Baden-Württemberg durch den Landesbeauftragten für den Datenschutz und die Informationsfreiheit Baden-Württemberg hat ergeben, dass rund 7 % der untersuchten Webseiten über HTTPS angeboten werden. Bei jenen Webseiten, die über HTTPS angeboten werden, ist die serverseitige Unterstützung für TLS 1.0 noch sehr weit verbreitet (99 %).<ref>{{Literatur |Autor=Ronald Petrlic, Klaus Manny |Titel=Wie sicher ist der Zugriff auf Websites im Internet? |Sammelwerk=Datenschutz und Datensicherheit – DuD |Band=41 |Nummer=2 |Datum=2017-02-03 |ISSN=1614-0702 |Seiten=88–92 |DOI=10.1007/s11623-017-0734-y}}</ref>
| |
|
| |
| TLS ist ohne eine zertifikatsbasierte Authentifizierung anfällig für [[Man-in-the-Middle-Angriff]]e: Ist der Man-in-the-Middle vor der Übergabe des Schlüssels aktiv, kann er beiden Seiten seine Schlüssel vorgaukeln und so den gesamten Datenverkehr im Klartext aufzeichnen und unbemerkt manipulieren. Wegen der mangelnden Vertrauenswürdigkeit einiger Zertifizierungsstellen wird seit Anfang 2010 die Sicherheit von TLS grundsätzlich angezweifelt.<ref>{{Internetquelle |url=https://www.heise.de/newsticker/meldung/EFF-zweifelt-an-Abhoersicherheit-von-SSL-963857.html |titel=EFF zweifelt an Abhörsicherheit von SSL |abruf=2016-01-19}}</ref><ref>{{Internetquelle |url=https://www.eff.org/deeplinks/2010/03/researchers-reveal-likelihood-governments-fake-ssl |titel=New Research Suggests That Governments May Fake SSL Certificates |abruf=2016-01-19}}</ref><ref>{{Internetquelle |url=http://files.cloudprivacy.net/ssl-mitm.pdf |titel=Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL |format=PDF |sprache=en |offline=1 |archiv-url=https://web.archive.org/web/20160216222537/http://files.cloudprivacy.net/ssl-mitm.pdf |archiv-datum=2016-02-16 |archiv-bot=2019-05-19 05:37:52 InternetArchiveBot |abruf=2016-01-19}}</ref><ref>{{Internetquelle |url=https://www.wired.com/2010/03/packet-forensics/ |titel=Law Enforcement Appliance Subverts SSL |abruf=2016-01-19}}</ref> Durch die Deaktivierung fragwürdiger Zertifizierungsstellen im eigenen Browser lässt sich dieses Risiko jedoch weitgehend beseitigen.
| |
|
| |
| In Verbindung mit einem [[Virtual Hosting#IP oder namensbasiertes Virtual Hosting|''virtuellen Server'']], zum Beispiel mit [[Hypertext Transfer Protocol|HTTP]] (etwa beim [[Apache HTTP Server]] über den ''VHost''-Mechanismus), ist es grundsätzlich als Nachteil zu werten, dass pro Kombination aus [[IP-Adresse]] und [[Port (Netzwerkadresse)|Port]] nur ein Zertifikat verwendet werden kann, da die eigentlichen Nutzdaten des darüber liegenden Protokolls (und damit der Name des VHosts) zum Zeitpunkt des TLS-Handshakes noch nicht übertragen wurden. Dieses Problem wurde mit der TLS-Erweiterung [[Server Name Indication]] (SNI) im Juni 2003 durch den <nowiki>RFC 3546</nowiki><ref name="RFC3546" /> behoben. Dabei wird bereits beim Verbindungsaufbau der gewünschte Servername mitgesendet. Die ursprüngliche Erweiterung wurde für TLS 1.0 beschrieben, aufgrund der Kompatibilität der einzelnen TLS-Versionen zueinander wird SNI auch bei TLS 1.1, Version 1.2 und 1.3 entsprechend der Empfehlung umgesetzt. In der Version 1.3 wird zusätzlich auch versucht, die SNI zu verschlüsseln, um mitzulesenden Parteien nicht zu ermöglichen, trotz verschlüsselter Verbindung Informationen über den Zielserver preiszugeben. Das muss jedoch vom Browser unterstützt, im [[Domain Name System|Domain Name System (DNS)]] ein Schlüssel hinterlegt und verschlüsseltes DNS genutzt werden.<ref>{{Internetquelle |url=https://www.cloudflare.com/de-de/learning/ssl/what-is-encrypted-sni/ |titel=Was ist verschlüsselte SNI? |hrsg=Cloudflare Inc. |sprache=de |abruf=2021-03-30}}</ref>
| |
|
| |
| Im [[Tor (Netzwerk)|Tor-Netzwerk]] sind TLS-Zertifikate für Verbindungen in das Internet von besonderer Bedeutung, da ein Abhören einer unverschlüsselten Verbindung mittels [[Man-in-the-Middle-Angriff]] dort durch den Rechner, der die Verbindung in das Internet herstellt (bezeichnet als „exit node“), sehr einfach möglich wäre. Da eine Verbindung zwischen zwei Endpunkten im Tor-Netzwerks jedoch verschlüsselt ist, kann die verschlüsselte Übertragung von Daten innerhalb des Netzwerks nachrangig betrachtet werden, sofern man dem [[Routing]] der Verbindungen vertraut. Hier liegt das Hauptmerkmal der TLS-Verschlüsselung in der Authentizität der Gegenseite.
| |
|
| |
| Neben [[Hypertext Transfer Protocol Secure|HTTPS]] als verschlüsselte Variante von [[Hypertext Transfer Protocol|HTTP]] sind weitere bekannte Anwendungsfälle für TLS beispielsweise:
| |
| * [[POP3S]] für [[Post Office Protocol|POP3]]
| |
| * [[SMTPS]] für [[Simple Mail Transfer Protocol|SMTP]]
| |
| * NNTPS für [[Network News Transfer Protocol|NNTP]]
| |
| * [[Session Initiation Protocol#Verschlüsselung und Sicherheit|SIPS]] für [[Session Initiation Protocol|SIP]]
| |
| * [[Internet Message Access Protocol#IMAPS|IMAPS]] für [[Internet Message Access Protocol|IMAP]]
| |
| * [[Extensible Messaging and Presence Protocol#Verschlüsselung|XMPPS]] für [[Extensible Messaging and Presence Protocol|XMPP]]
| |
| * [[Internet Relay Chat#Verschlüsselung|IRCS]] für [[Internet Relay Chat|IRC]]
| |
| * LDAPS für [[Lightweight Directory Access Protocol|LDAP]]
| |
| * [[Multi-purpose Business Security over IP|MBS/IP]]-TLS
| |
| * [[FTPS]] für [[File Transfer Protocol|FTP]]
| |
| * [[Extensible Authentication Protocol|EAP]]-TLS
| |
| * [[Tn3270|TN3270]]-TLS
| |
| * [[OpenVPN]]
| |
| * [[DNS over TLS]], [[DNS over HTTPS]] und [[DNS over QUIC]] um DNS Abfragen durch TLS zu tunneln
| |
|
| |
| Auch Verbindungen zu Datenbanksystemen können über TLS abgesichert werden. Dabei werden die Identität des Servers oder auch des Clients geprüft und die gesamte Kommunikation verschlüsselt.<ref>{{Internetquelle |autor= |url=https://www.postgresql.org/docs/current/auth-cert.html |titel=PostgreSQL: Certificate Authentication |abruf=2021-03-23}}</ref>
| |
|
| |
| === Versionen ===
| |
|
| |
| {| class="wikitable"
| |
| |- class="hintergrundfarbe5"
| |
| ! Version !! Erscheinungsjahr !! Bemerkungen
| |
| |-
| |
| | {{Version|o|SSL 1.0}}
| |
| | 1994
| |
| |
| |
| |-
| |
| |-
| |
| | {{Version|o|SSL 2.0}}
| |
| | 1995
| |
| | seit März 2011 überholt<ref>{{RFC-Internet |RFC=6176 |Autor=S. Turner, T. Polk |Titel=Prohibiting Secure Sockets Layer (SSL) Version 2.0 |Datum=2011-03}}</ref>
| |
| |-
| |
| | {{Version|o|SSL 3.0}}
| |
| | 1996
| |
| | seit Juni 2015 überholt<ref>{{RFC-Internet |RFC=7568 |Autor=R. Barnes, M. Thomson, A. Pironti, A. Langley |Titel=Deprecating Secure Sockets Layer Version 3.0 |Datum=2015-06}}</ref>
| |
| |-
| |
| | {{Version|o|TLS 1.0}}
| |
| | 1999
| |
| | seit März 2021 überholt<ref name="RFC8996">{{RFC-Internet |RFC=8996 |Autor=K. Moriarty, S. Farrell |Titel=Deprecating TLS 1.0 and TLS 1.1 |Datum=2021-03}}</ref>
| |
| |-
| |
| | {{Version|o|TLS 1.1}}
| |
| | 2006
| |
| | seit März 2021 überholt<ref name="RFC8996" />
| |
| |-
| |
| | {{Version|co|TLS 1.2}}
| |
| | 2008
| |
| |
| |
| |-
| |
| | {{Version|c|TLS 1.3}}
| |
| |2018<ref>{{Internetquelle |url=https://www.ietf.org/mail-archive/web/tls/current/msg25837.html |titel=[TLS] Protocol Action: ‘The Transport Layer Security (TLS) Protocol Version 1.3’ to Proposed Standard |abruf=2018-03-31 |kommentar=draft-ietf-tls-tls13-28.txt}}</ref>
| |
| | <nowiki>RFC 8446</nowiki>, enthält auch neue Anforderungen für TLS 1.2.<ref name="RFC8446" />
| |
| |}{{Version|t|zeige=11101}}
| |
|
| |
| == Geschichte ==
| |
|
| |
| * Die erste Protokollversion von TLS wurde ab August 1986 im Rahmen des im September 1987 erstmals beschrieben Projektes ''Secure Data Network System (SDNS)'' entwickelt.<ref>{{Internetquelle |url=https://circleid.com/posts/20190124_creating_tls_the_pioneering_role_of_ruth_nelson |titel=Creating TLS: The Pioneering Role of Ruth Nelson |sprache=en |abruf=2021-12-07}}</ref>
| |
| * 1994, neun Monate nach der ersten Ausgabe von [[NCSA Mosaic|Mosaic]], dem ersten verbreiteten [[Webbrowser]], stellte Netscape Communications die erste Version von SSL (1.0) fertig.
| |
| * Fünf Monate später wurde zusammen mit einer neuen Ausgabe des Netscape Navigator die nächste Version SSL 2.0 veröffentlicht.
| |
| * Ende 1995 veröffentlichte [[Microsoft]] die erste Version seines Webbrowsers [[Internet Explorer]]. Kurz darauf wurde auch die erste Version ihres SSL-Pendants bekannt, PCT 1.0 (Private Communication Technology). PCT hatte einige Vorteile gegenüber SSL 2.0, die später in SSL 3.0 aufgenommen wurden.
| |
| * Im Sommer 1996 übergab Netscape die Versionskontrolle über sein Protokoll SSL 3.0 an die [[Internet Engineering Task Force|IETF]] zur Entwicklung eines Internet-Standards.
| |
| * Ab November 1996<ref>{{Internetquelle |url=https://tools.ietf.org/html/draft-ietf-tls-protocol-00 |titel=(draft-00)The TLS Protocol Version 1.0 |hrsg=IETF |datum=1996-11-26 |abruf=2020-12-10}}</ref> entwickelte die [[Internet Engineering Task Force|IETF]] TLS WG auf Basis von Netscapes SSL 3.0 das verbesserte Protokoll „Transport Layer Security (TLS) Protocol Version 1.0“ (interne Versionsnummer 3.1), welches schließlich im Januar 1999 als <nowiki>RFC 2246</nowiki><ref>{{RFC-Internet |Autor= |RFC=2246 |Titel=The TLS Protocol Version 1.0 |Datum=1999-01}}</ref> veröffentlicht wurde. Das finale Spezifikationsdokument von Netscapes SSL 3.0 war viele Jahre schwer zu finden und wurde im August 2011 nachträglich veröffentlicht als <nowiki>RFC 6101</nowiki><ref>{{RFC-Internet |Autor= |RFC=6101 |Titel=The Secure Sockets Layer (SSL) Protocol Version 3.0 |Datum=2011-08}}</ref>.
| |
| * Später wurde TLS durch weitere [[Request for Comments|RFCs]] erweitert:
| |
| ** <nowiki>RFC 2712</nowiki> – Addition of Kerberos Cipher Suites to Transport Layer Security (TLS).<ref>{{RFC-Internet |RFC=2712 |Titel=Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) |Datum=}}</ref>
| |
| ** <nowiki>RFC 2817</nowiki> – Upgrading to TLS Within HTTP/1.1<ref>{{RFC-Internet |RFC=2817 |Titel=Upgrading to TLS Within HTTP/1.1 |Datum=}}</ref> erläutert die Benutzung des Upgrade-Mechanismus in HTTP/1.1, um Transport Layer Security (TLS) über eine bestehende [[Transmission Control Protocol|TCP]]-Verbindung zu initialisieren. Dies erlaubt es, für unsicheren und für sicheren HTTP-Verkehr die gleichen „well-known“ TCP Ports (80 bzw. 443) zu benutzen.
| |
| ** <nowiki>RFC 2818</nowiki> – HTTP Over TLS<ref>{{RFC-Internet |RFC=2818 |Titel=HTTP Over TLS |Datum=}}</ref> trennt sicheren von unsicherem Verkehr durch getrennte Server-TCP-Ports.
| |
| ** <nowiki>RFC 3268</nowiki> – Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)<ref>{{RFC-Internet |RFC=3268 |Titel=Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) |Datum=}}</ref> nutzt die Erweiterbarkeit von TLS und fügt den symmetrischen Verschlüsselungsalgorithmen ([[RC2 (Blockchiffre)|RC2]], [[RC4]], [[International Data Encryption Algorithm]] (IDEA), [[Data Encryption Standard]] (DES) und [[Triple DES]]) den [[Advanced Encryption Standard]] (AES) hinzu.
| |
| ** <nowiki>RFC 3546</nowiki><ref name="RFC3546" /> – Transport Layer Security (TLS) Extensions führt das Konzept der Erweiterungen ein, wodurch optionale Datenfelder oder Header vor allem bei der anfänglichen Aushandlung übertragen werden können. Eine dieser Erweiterungen ist [[Server Name Indication]].
| |
| * Im April 2006 wurde in <nowiki>RFC 4346</nowiki><ref>{{RFC-Internet |RFC=4346 |Titel=The Transport Layer Security (TLS) Protocol Version 1.1 |Datum=2006-04}}</ref> die Version 1.1 von TLS standardisiert und damit <nowiki>RFC 2246</nowiki> obsolet. In TLS 1.1 wurden kleinere Sicherheitsverbesserungen vorgenommen und Unklarheiten beseitigt.
| |
| * Im August 2008 erschien mit <nowiki>RFC 5246</nowiki><ref>{{RFC-Internet |Autor=Dierks, Rescorla |RFC=5246 |Titel=TLS 1.2 Spezifikation (Proposed Standard) |Datum=2008-08 |Obsoletes=4346}}</ref> die Version 1.2 von TLS, welche <nowiki>RFC 4346</nowiki> obsolet machte. Hierbei wurde die Festlegung auf MD5/SHA-1 in der [[Pseudozufällige Funktion|Pseudozufallsfunktion]] (PRF) und bei signierten Elementen ersetzt durch flexiblere Lösungen, bei denen die Hash-Algorithmen spezifiziert werden können.
| |
| * Im Februar 2015 wurde <nowiki>RFC 7465</nowiki><ref>{{RFC-Internet |Autor= |RFC=7465 |Titel=Prohibiting RC4 Cipher Suites |Datum=2015-02}}</ref> veröffentlicht, das RC4 für Verschlüsselung verbietet.<ref>{{Internetquelle |autor=Jürgen Schmidt |url=https://www.heise.de/security/meldung/IETF-verbietet-RC4-Verschluesselung-in-TLS-2556520.html |titel=IETF verbietet RC4-Verschlüsselung in TLS |hrsg=Heise Security |datum=2015-02-20 |abruf=2015-02-20}}</ref>
| |
| * Im Mai 2015 wurden mit <nowiki>RFC 7525</nowiki><ref>{{RFC-Internet |Autor= |RFC=7525 |Titel=Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) |Datum=2015-05}}</ref> Empfehlungen zum sicheren Einsatz von TLS und [[Datagram Transport Layer Security|DTLS]] veröffentlicht. Demnach sollen SSLv2, SSLv3, RC4 und sonstige durch [[Exportbeschränkung]]en auf unter 112 Bit Schlüssellänge beschränkte Verschlüsselungsalgorithmen nicht verwendet werden. Vom Einsatz von [[Triple DES|3DES]] zur Verschlüsselung und [[RSA-Kryptosystem|RSA]] zum Schlüsselaustausch mit statischen Parametern wird abgeraten. Empfohlen werden [[Cipher Suite]]n, die zum Schlüsselaustausch [[Diffie-Hellman-Schlüsselaustausch#Ephemeral Diffie-Hellman|Ephemeral Diffie-Hellman]] kombiniert mit RSA verwenden, was [[Perfect Forward Secrecy|Forward Secrecy]] (gegen späteres nachträgliches Entschlüsseln) bietet, zur Verschlüsselung AES im [[Galois/Counter Mode]] mit 128 oder 256 Bit Schlüssellänge sowie die [[Kryptologische Hashfunktion|Hashfunktion]] SHA-256 oder SHA-384 für die Pseudozufallsfunktion von TLS.<ref>{{Internetquelle |autor=Jürgen Schmidt |url=https://www.heise.de/newsticker/meldung/IETF-spezifiziert-Richtlinien-fuer-den-Einsatz-von-Verschluesselung-2639221.html |titel=IETF spezifiziert Richtlinien für den Einsatz von Verschlüsselung |hrsg=Heise Security |datum=2015-05-08 |abruf=2015-05-10}}</ref>
| |
| * Im August 2018 wurde in <nowiki>RFC 8446</nowiki> TLS-Version 1.3 veröffentlicht, das seit 2014 entwickelt wurde.<ref name="RFC8446" />
| |
| * Im Oktober 2018 gaben die Hersteller der Browser Firefox, Chrome, Edge und Safari an, die in die Jahre gekommenen Protokolle TLS 1.0 und 1.1 beginnend ab März 2020 nicht mehr zu unterstützen.<ref name="Wood" /><ref name="Thomson" /> In Google Chrome 84 wurde die Unterstützung für TLS 1.0 und 1.1 daher entfernt.<ref name="ChromePlatformStatus" />
| |
|
| |
| == Funktionsweise ==
| |
|
| |
| Der Client baut eine Verbindung zum Server auf. Der Server authentifiziert sich gegenüber dem Client mit einem [[Digitales Zertifikat|Zertifikat]]. Der Client überprüft hierbei die Vertrauenswürdigkeit des [[X.509]]-Zertifikats und ob der Servername mit dem Zertifikat übereinstimmt. Optional kann sich der Client mit einem eigenen Zertifikat auch gegenüber dem Server authentifizieren. Dann schickt entweder der Client dem Server eine mit dem öffentlichen Schlüssel des Servers verschlüsselte geheime [[Zufallszahl]], oder die beiden Parteien berechnen mit dem [[Diffie-Hellman-Schlüsselaustausch]] ein gemeinsames Geheimnis. Aus dem Geheimnis wird dann ein kryptographischer Schlüssel abgeleitet. Dieser Schlüssel wird in der Folge benutzt, um alle Nachrichten der Verbindung mit einem [[Symmetrisches Verschlüsselungsverfahren|symmetrischen Verschlüsselungsverfahren]] zu verschlüsseln und zum Schutz von [[Integrität (Informationssicherheit)|Nachrichten-Integrität]] und [[Authentizität]] durch einen [[Message Authentication Code]] abzusichern.
| |
|
| |
| === TLS-Protokolle im Protokollstapel ===
| |
|
| |
| Im [[OSI-Modell]] ist TLS in Schicht 5 (der Sitzungsschicht) angeordnet. Im TCP/IP-Modell ist TLS oberhalb der [[Transportschicht]] (zum Beispiel [[Transmission Control Protocol|TCP]]) und unterhalb Anwendungsprotokollen wie [[Hypertext Transfer Protocol|HTTP]] oder [[Simple Mail Transfer Protocol|SMTP]] angesiedelt. In den Spezifikationen wird dies dann zum Beispiel als „HTTP over TLS“ bezeichnet. Sollen jedoch beide Protokolle zusammengefasst betrachtet werden, wird üblicherweise ein ''„S“ für Secure'' dem Protokoll der Anwendungsschicht angehängt (zum Beispiel [[Hypertext Transfer Protocol Secure|HTTP'''S''']]). TLS arbeitet transparent, so dass es leicht eingesetzt werden kann, um Protokollen ohne eigene Sicherheitsmechanismen abgesicherte Verbindungen zur Verfügung zu stellen. Zudem ist es erweiterbar, um Flexibilität und Zukunftssicherheit bei den verwendeten Verschlüsselungstechniken zu gewährleisten.
| |
|
| |
| Das TLS-Protokoll besteht aus zwei Schichten:
| |
| {| class="wikitable"
| |
| |-
| |
| ! TLS Handshake Protocol
| |
| ! TLS Change Cipher Spec. Protocol
| |
| ! TLS Alert Protocol
| |
| ! TLS Application Data Protocol
| |
| |-
| |
| !colspan="4"| TLS Record Protocol
| |
| |}
| |
|
| |
| === TLS Record Protocol ===
| |
|
| |
| Das TLS Record Protocol ist die untere der beiden Schichten und dient zur Absicherung der Verbindung. Es setzt direkt auf der Transportschicht auf und bietet zwei verschiedene Dienste, die einzeln oder gemeinsam genutzt werden können:
| |
| * [[Ende-zu-Ende-Verschlüsselung]] mittels [[Symmetrisches Kryptosystem|symmetrischer Algorithmen]]. Der verwendete Schlüssel wird dabei im Voraus über ein weiteres Protokoll (zum Beispiel das TLS Handshake Protocol) ausgehandelt und kann nur einmal für die jeweilige Verbindung verwendet werden. TLS unterstützt für die [[symmetrische Verschlüsselung]] unter anderem [[Data Encryption Standard|DES]], [[Triple DES]] und [[Advanced Encryption Standard|AES]]
| |
| * Sicherung der [[Integrität (Informationssicherheit)|Nachrichten-Integrität]] und [[Authentizität]] durch einen [[Message Authentication Code]], in der Regel [[Keyed-Hash Message Authentication Code|HMAC]].
| |
|
| |
| Außerdem werden zu sichernde Daten in Blöcke von maximal 16.384 (2<sup>14</sup>) Byte fragmentiert und beim Empfänger wieder zusammengesetzt. Dabei schreibt der Standard vor, dass die Blockgröße diesen Wert nicht übersteigt, außer der Block ist komprimiert oder verschlüsselt – dann darf die Blockgröße um 1024 Byte (bei Kompression) bzw. 2048 Byte (bei Verschlüsselung) größer sein. Auch können die Daten vor dem Verschlüsseln und vor dem Berechnen der kryptografischen Prüfsumme komprimiert werden. Das Komprimierungsverfahren wird ebenso wie die kryptografischen Schlüssel mit dem TLS Handshake-Protokoll ausgehandelt.
| |
|
| |
| Der Aufbau einer TLS-Record-Nachricht lautet wie folgt: ''Content Type'' (1 Byte: ''Change Cipher Spec'' = 20, ''Alert'' = 21, ''Handshake'' = 22, ''Application Data'' = 23) | ''Protokollversion Major'' (1 Byte) | ''Protokollversion Minor'' (1 Byte) | ''Länge'' (1 Short bzw. zwei Byte)
| |
|
| |
| === TLS Handshake Protocol ===
| |
|
| |
| [[Datei:SSL handshake with two way authentication with certificates.svg|mini|TLS-Handshake mit Zwei-Wege-Authentifizierung mittels Zertifikaten und RSA-Schlüsselaustausch]]
| |
|
| |
| Das TLS Handshake Protocol baut auf dem TLS Record Protocol auf und erfüllt die folgenden Funktionen, noch bevor die ersten Bits des Anwendungsdatenstromes ausgetauscht wurden:
| |
| * Aushandeln zu benutzender kryptografischer Algorithmen und Schlüssel. TLS unterstützt auch eine unverschlüsselte Übertragung.
| |
| * Identifikation und Authentifizierung der Kommunikationspartner auf Basis [[Asymmetrisches Kryptosystem|asymmetrischer Verschlüsselungsverfahren]] und [[Public-Key-Infrastruktur|Public-Key-Kryptografie]]. Dieser Schritt ist optional eine Zwei-Wege-Authentifizierung (in diesem Fall wird manchmal von ''mutual TLS'' gesprochen), für gewöhnlich authentifiziert sich aber nur der [[Server]] gegenüber dem [[Client]].
| |
|
| |
| Der Handshake selbst kann in vier ''Phasen'' unterteilt werden:
| |
| # Der Client schickt zum Server ein C''lientHello'', und der Server antwortet dem Client mit einem S''erverHello''. Die Parameter der Nachrichten sind:
| |
| #* die Version (die höchste vom Client unterstützte TLS-Protokoll-Version)
| |
| #* eine 32 Byte lange Zufallsinformation (4 Byte Timestamp + 28 Byte lange Zufallszahl), die später verwendet wird, um das ''pre-master-secret'' zu bilden (sie schützt damit vor [[Replay-Attacke]]n)
| |
| #* eine Session-ID
| |
| #* die zu verwendende [[Cipher Suite]] (Algorithmen für Schlüsselaustausch, Verschlüsselung und Authentifizierung)
| |
| #* Optional den gewünschten [[Fully Qualified Domain Name|FQDN]] für die Unterstützung von [[Server Name Indication]]
| |
| #* in der TLS 1.3 Version (mit [[Diffie-Hellman-Schlüsselaustausch]]) werden hier auch schon die Key-Shares übertragen, die den gemeinsamen Schlüssel definieren.
| |
| # Der Server identifiziert sich gegenüber dem Client. Hierzu wird per C''ertificate'' ein [[X.509]]v3-[[Digitales Zertifikat|Zertifikat]] an den Client geschickt, gefolgt von einem ''CertificateVerify'' (in einigen TLS Versionen). Die C''ertificateVerify'' Nachricht enthält eine Unterschrift von zuvor ausgetauschten Nachrichten. Damit beweist der Server, dass er einen [[Asymmetrische Verschlüsselung|Secret-Key]] besitzt, der zu dem auf dem Server-Zertifikat enthaltenen [[Public-Key-Kryptografie|Public-Key]] passt. Der Client prüft das Zertifikat und die Unterschrift. Bei Misserfolg bricht der Client die Verbindung ab. Außerdem kann der Server optional per ''CertificateRequest'' ein Zertifikat zur Client-Authentifizierung anfordern. Diese Phase darf nur weggelassen werden, wenn eine anonyme Cipher Suite ohne Authentifizierung verwendet wird.
| |
| # Das zuvor erhaltene Server-Zertifikat enthält den [[Asymmetrisches Kryptosystem|öffentlichen Schlüssel]] des Servers. Wird eine [[Cipher Suite]] mit [[RSA-Kryptosystem|RSA]]-Schlüsselaustausch verwendet (siehe Abbildung), so wird das vom Client generierte ''pre-master-secret'' mit diesem öffentlichen Schlüssel verschlüsselt und kann vom Server mit dem nur ihm bekannten privaten Schlüssel wieder entschlüsselt werden. Alternativ kann hier auch der [[Diffie-Hellman-Schlüsselaustausch]] verwendet werden, um ein gemeinsames ''pre-master-secret'' zu generieren. Werden die Diffie-Hellman-Geheimnisse von Server und Client während des Handshakes frisch und zufällig ausgehandelt, sind die Voraussetzungen für [[Perfect Forward Secrecy]] erfüllt. Nach der Übertragung des ''pre-master-secrets'' identifiziert sich der Client mittels Zertifikat gegenüber dem Server, sofern dieser einen ''CertificateRequest'' geschickt hat. Dazu schickt der Client per ''Certificate'' das Client-Zertifikat, gefolgt von einem ''CertificateVerify.'' Die ''CertificateVerify'' Nachricht enthält eine Unterschrift aller zuvor ausgetauschten Nachrichten. Damit beweist der Client gegenüber dem Server, dass er einen Secret-Key besitzt, der zu dem auf dem Client-Zertifikat enthaltenen Public-Key passt. Ab hier ist dem Server also bekannt, mit wem er kommuniziert.
| |
| # Diese Phase schließt den Handshake ab. Aus dem vorhandenen ''pre-master-secret'' kann das ''master secret'' abgeleitet werden, das einen einmaligen [[Sitzungsschlüssel]] ({{enS|session key}}) darstellt. Aus dem ''master secret'' werden wiederum Schlüssel abgeleitet, die zum Ver- und Entschlüsseln der Daten sowie für die Integritätsprüfung verwendet werden. Die Nachrichten, die die Kommunikationspartner sich nun gegenseitig zusenden, werden nur noch verschlüsselt übertragen. Falls sich der Server nicht im Schritt 2 via ''CertificateVerify'' authentifiziert hat, ist dem Client erst nach dem Erhalt der ersten verschlüsselten Nachricht bekannt, dass er mit dem rechtmäßigen Besitzer des Zertifikats kommuniziert.
| |
|
| |
| === TLS Change Cipher Spec Protocol ===
| |
|
| |
| Das Change Cipher Spec Protocol besteht nur aus einer einzigen Nachricht. Diese Nachricht ist ein Byte groß und besitzt den Inhalt 1. Durch diese Nachricht teilt der Sender dem Empfänger mit, dass er in der aktiven Sitzung auf die im Handshake Protocol ausgehandelte [[Cipher Suite]] wechselt.
| |
| Ein wesentlicher Grund für die Definition eines eigenen Protokolls für diese Nachricht besteht darin, dass TLS-Implementierungen mehrere Nachrichten eines Protokolls in einem Record (also einer TLS-Dateneinheit) zusammenfassen können. Für die Nachricht „Change Cipher Spec“ ist das unerwünscht. Weil Records verschiedener Protokolle nicht zusammengefasst werden dürfen, ist das Problem durch Definition eines eigenen Protokolls gelöst.<ref>Joshua Davies: ''Implementing SSL / TLS Using Cryptography and PKI.'' John Wiley and Sons, Indianapolis 2011, S. 344.</ref>
| |
|
| |
| === TLS Alert Protocol ===
| |
|
| |
| Das ''Alert Protocol'' unterscheidet etwa zwei Dutzend verschiedene Mitteilungen. Eine davon teilt das Ende der Sitzung mit (close_notify). Andere beziehen sich zum Beispiel auf die Protokollsyntax oder die Gültigkeit der verwendeten Zertifikate. Es wird zwischen Warnungen und Fehlern unterschieden, wobei letztere die Verbindung sofort beenden.
| |
|
| |
| Der Aufbau einer Fehlermeldung lautet wie folgt: ''AlertLevel'' (1 Byte: ''Warning'' = 1, ''Fatal'' = 2) | ''AlertDescription'' (1 Byte: ''close_notify'' = 0, […], ''no_renegotiation'' = 100).
| |
|
| |
| In der Spezifikation von TLS werden die folgenden schweren Fehlertypen definiert:
| |
|
| |
| {| class="wikitable"
| |
| |-
| |
| | unexpected_message || Unpassende Nachricht wurde empfangen.
| |
| |-
| |
| | bad_record_mac || Ein falscher [[Message Authentication Code|MAC]] wurde empfangen.
| |
| |-
| |
| | decompression_failure || Dekomprimierungsalgorithmus empfing unkorrekte Daten.
| |
| |-
| |
| | handshake_failure || Absender konnte keine akzeptable Menge von Sicherheitsparametern bearbeiten.
| |
| |-
| |
| | illegal_parameter || Ein Feld in der Handshake-Nachricht lag außerhalb des erlaubten Bereichs oder stand im Widerspruch mit anderen Feldern.
| |
| |}
| |
|
| |
| In der Spezifikation von TLS werden die folgenden Warnungen definiert:
| |
|
| |
| {| class="wikitable"
| |
| |-
| |
| | close_notify || Teilt Empfänger mit, dass Absender keine weiteren Nachrichten auf dieser Verbindung senden wird. Muss von jedem Partner einer Verbindung als letzte Nachricht gesendet werden.
| |
| |-
| |
| | no_certificate || Kann als Antwort auf eine Zertifikatanforderung gesendet werden, falls passendes Zertifikat nicht verfügbar ist. (Wurde in TLS 1.0 entfernt<ref name="schwenk2010">Schwenk, Jörg (2010): ''Sicherheit und Kryptographie im Internet. Von sicherer E-Mail bis zu IP-Verschlüsselung'', herausgegeben von Vieweg+Teubner Verlag / GWV Fachverlage GmbH, Wiesbaden. ISBN 978-3-8348-0814-1.</ref>)
| |
| |-
| |
| | bad_certificate || Empfangenes Zertifikat war unvollständig oder falsch.
| |
| |-
| |
| | unsupported_certificate || Der Typ des empfangenden Zertifikats wird nicht unterstützt.
| |
| |-
| |
| | certificate_revoked || Zertifikat wurde vom Unterzeichner zurückgerufen.
| |
| |-
| |
| | certificate_expired || Zertifikat ist abgelaufen.
| |
| |-
| |
| | certificate_unknown || Andere, nicht genau spezifizierte Gründe sind beim Bearbeiten des Zertifikats aufgetreten, die dazu führen, dass das Zertifikat als ungültig gekennzeichnet wurde.
| |
| |}
| |
|
| |
| In der Spezifikation von TLS 1.0 wurden folgende Warnungen ergänzt:<ref name="schwenk2010" />
| |
|
| |
| {| class="wikitable"
| |
| | decryption_failed || Entschlüsselung fehlgeschlagen.
| |
| |-
| |
| | record_overflow ||
| |
| |-
| |
| | unknown_ca || Unbekannte oder nicht vertrauenswürdige CA.
| |
| |-
| |
| | access_denied || Zugriff verweigert.
| |
| |-
| |
| | decode_error || Decodierungsfehler.
| |
| |-
| |
| | decrypt_error || Entschlüsselungsfehler.
| |
| |-
| |
| | export_restriction || Exportbeschränkung.
| |
| |-
| |
| | protocol_version || Veraltete Version von TLS/SSL.
| |
| |-
| |
| | insufficient_security || Unzureichende Sicherheit.
| |
| |-
| |
| | internal_error || Interner Fehler.
| |
| |-
| |
| | user_canceled || Abbruch durch Benutzer.
| |
| |-
| |
| | no_renegotiation ||
| |
| |}
| |
|
| |
| === TLS Application Data Protocol ===
| |
|
| |
| Die Anwendungsdaten werden über das Record Protocol transportiert, in Teile zerlegt, komprimiert und in Abhängigkeit vom aktuellen Zustand der Sitzung auch verschlüsselt. Inhaltlich werden sie von TLS nicht näher interpretiert.
| |
|
| |
| === Berechnung des Master Secrets ===
| |
|
| |
| Aus dem ''pre-master-secret'' wird in früheren Protokollversionen mit Hilfe der [[Hashfunktion]]en [[SHA-1]] und [[MD5]], in TLS 1.2 mit Hilfe einer durch eine ''Cipher Suite'' spezifizierten Pseudozufallsfunktion das ''Master Secret'' berechnet. In diese Berechnung fließen zusätzlich die Zufallszahlen der Phase 1 des Handshakes mit ein. Die Verwendung beider Hash-Funktionen sollte sicherstellen, dass das ''Master Secret'' immer noch geschützt ist, falls eine der Funktionen als kompromittiert gilt. In TLS 1.2 wird dieser Ansatz durch die flexible Austauschbarkeit der Funktion ersetzt.
| |
|
| |
| == Sicherheit ==
| |
|
| |
| Auf SSL und TLS sind jeweils eine Reihe von Angriffen bekannt, die die Sicherheitsgarantien untergraben.<ref name="RFC7457" /> Die folgende Liste stellt einen Teil der bekannten Angriffe dar.
| |
|
| |
| === Padding-Oracle-Angriffe ===
| |
|
| |
| Der Kryptologe [[Serge Vaudenay]] entdeckte 2002, dass ein [[Man-in-the-Middle-Angriff|Man-in-the-Middle-Angreifer]] aus dem [[Padding (Informatik)|Padding]] einer mit dem [[Cipher Block Chaining Mode]] (CBC) verschlüsselten Nachricht Informationen erhalten kann, die zur Entschlüsselung der Nachricht genutzt werden können. Durch gezielte Manipulation einer verschlüsselten Nachricht lernt der Angreifer, ob der Server ein gültiges Padding meldet und damit ein Teil des Klartexts richtig erraten wurde.<ref name="Vaudenay2002" />
| |
|
| |
| Als Schutzmaßnahme sollte der Server ungültige Nachrichten verwerfen, ohne dabei zu offenbaren, ob das Padding oder die Nachrichtenauthentizität ungültig war. Allerdings kann ein Angreifer diese Information auch durch eine Analyse der Antwortzeiten herleiten (Timing-Angriff). Betroffen sind SSL, TLS bis Version 1.2 und DTLS, sofern eine [[Cipher Suite]] mit CBC verwendet wird. Cipher Suites mit [[Authenticated Encryption]] sind nicht betroffen.<ref name="AlFardan2013" />
| |
|
| |
| Im Oktober 2014 demonstrierten Sicherheitsforscher den [[Poodle|POODLE-Angriff]] (''Padding Oracle On Downgraded Legacy Encryption''), mit dem ein Angreifer ein Versions-Downgrade einer TLS-Verbindung erzwingt, um einen Padding-Oracle-Angriff gegen SSL 3.0 durchzuführen. Zwecks Kompatibilität wurde SSL 3.0 trotz zu dem Zeitpunkt bekannter Sicherheitsschwächen noch von Webbrowsern und anderen Implementierungen unterstützt. Im Nachgang hat die [[Internet Engineering Task Force]] SSL 3.0 als überholt gekennzeichnet<ref name="RFC7568" /> und ein Verfahren zum Schutz vor Downgrade-Angriffen auf TLS spezifiziert.<ref name="RFC7507" />
| |
|
| |
| === BEAST ===
| |
|
| |
| SSL 3.0 und TLS 1.0 verwenden im CBC-Modus einen vorhersagbaren Initialisierungsvektor. Ein Angreifer kann dadurch mit einem [[Kryptoanalyse#Chosen Plaintext|Chosen-Plaintext-Angriff]] unbekannte Teile des Klartexts ermitteln. Ein Angriffsszenario ist das Stehlen von [[HTTP-Cookie]]s, die verschlüsselt übertragen werden. Hierzu muss der Angreifer das Angriffsopfer auf eine bösartige Website locken, die wiederholt HTTP-Anfragen an eine fremde Domain auslöst, wobei der Webbrowser automatisch die für die Domain gesetzten HTTP-Cookies mitsendet. Durch den teilweise selbst gewählten Inhalt der HTTP-Anfragen und durch Abhören der verschlüsselten TLS-Nachrichten kann der Angreifer das Cookie zeichenweise erraten.
| |
|
| |
| Die Grundlagen des Angriffs wurden 2004 beschrieben<ref name="Bard2004" /> und 2011 erstmals in der Praxis unter dem Namen BEAST (''Browser Exploit Against SSL/TLS'') demonstriert.<ref name="Duong2011" /><ref name="BEAST" /> TLS-Version 1.1 und höher sind nicht betroffen, da jede Nachricht mit einem pseudozufälligen Initialisierungsvektor verschlüsselt wird.
| |
|
| |
| Der kryptographische Unterschied zwischen TLS 1.0 und TLS 1.1 ist marginal und es gibt einen trivialen und abwärtskompatiblen Workaround mittels 1/(n-1) TLS record splitting, welcher diesen marginalen Unterschied zwischen TLS 1.0 und TLS 1.1 formal beweisbar irrelevant macht. Dieser triviale Workaround wurde von allen von BEAST betroffenen Anwendungen im Laufe des Jahres 2011 eingebaut. BEAST betrifft nur Webbrowser, Java im Browser und SSL-VPNs, weil BEAST nur als Inside-Angriff möglich ist.<ref>{{Internetquelle |autor=Eric Rescorla (EKR) |url=http://www.educatedguesswork.org/2011/11/rizzoduong_beast_countermeasur.html |titel=Rizzo/Duong BEAST Countermeasures |datum=2011-11-05 |abruf=2020-12-10}}</ref>
| |
|
| |
| === Kompressionsangriffe ===
| |
|
| |
| Die Verwendung der optionalen [[Datenkompression|Kompression]] von Nutzdaten eröffnet eine Klasse von Angriffen, die das Erraten von Teilen des Klartexts ermöglichen. Das Angriffsszenario ist ähnlich wie beim [[#BEAST|BEAST-Angriff]]: der Angreifer führt einen Chosen-Plaintext-Angriff durch und beobachtet die verschlüsselten TLS-Nachrichten im Netz. Das Kompressionsverfahren entfernt Redundanzen aus den Nutzdaten, sodass der zu verschlüsselnde Klartext und damit auch der Geheimtext kürzer wird. Hat der Angreifer einen Teil des unbekannten Klartexts erraten, zum Beispiel ein Zeichen eines HTTP-Cookies, so erfährt er dies aus dem Längenunterschied einer verschlüsselten TLS-Nachricht.
| |
|
| |
| Der Angriff wurde 2012 von den Urhebern des BEAST-Angriffs unter dem Namen CRIME (''Compression Ratio Info-leak Made Easy'') veröffentlicht.<ref name="CRIME" /> Neben SSL und TLS ist auch das [[SPDY]]-Protokoll betroffen. Als Schutzmaßnahme wird von der Verwendung der Kompression abgeraten. TLS ab Version 1.3 unterstützt keine Kompression mehr. Der SPDY-Nachfolger [[HTTP/2]] verwendet ein vereinfachtes Kompressionsformat (''HPACK''), das weniger effizient komprimiert als [[Deflate]], dafür aber schwerer anzugreifen ist.<ref name="RFC7541" />
| |
|
| |
| TIME und BREACH sind verbesserte Varianten des Angriffs. TIME (''Timing Info-leak Made Easy'') leitet die Größe einer verschlüsselten TLS-Nachricht aus der Antwortzeit her, ohne dass der Netzwerkverkehr abgehört werden muss.<ref name="TIME" /> Beide Angriffe erlauben das Erraten von TLS-verschlüsselten Inhalten, wenn TLS-Kompression abgeschaltet ist und stattdessen [[Hypertext Transfer Protocol#HTTP-Kompression|HTTP-Kompression]] verwendet wird. Da TLS Kompressionsangriffe nicht grundsätzlich verhindern kann, müssen anwendungsspezifische Schutzmaßnahmen verwendet werden, zum Beispiel der vollständige Verzicht auf Kompression.
| |
|
| |
| === Downgrade auf Exportverschlüsselung ===
| |
|
| |
| Als Folge der [[Exportbeschränkung]]en von [[Kryptographie]] aus den [[Vereinigte Staaten|Vereinigten Staaten]] sind in TLS zahlreiche exporttaugliche Cipher Suites spezifiziert, die nur kurze Schlüssel verwenden. Trotz bekannter Sicherheitsschwächen wurden oder werden diese zum Teil noch von Implementierungen unterstützt. Der TLS-Handshake soll eigentlich verhindern, dass ein Man-in-the-Middle-Angreifer einen Downgrade auf eine nicht angefragte Cipher Suite erzwingen kann, indem die Handshake-Nachrichten authentifiziert werden. Die Sicherheit der Authentifizierung hängt allerdings auch von der ausgehandelten Cipher Suite ab, sodass der Angreifer den Schlüssel brechen kann.
| |
|
| |
| Beim 2015 veröffentlichten [[FREAK|FREAK-Angriff]] (''Factoring RSA Export Keys'') findet ein Downgrade auf [[RSA-Kryptosystem|RSA-basierte]] Cipher Suites mit 512 Bit langen Exportschlüsseln statt.<ref>Cipher Suites mit „RSA_EXPORT“ im Namen.</ref> Der Angriff setzt einen Implementierungsfehler voraus, bei dem der Client den 512-Bit-Schlüssel anstatt des längeren Schlüssels aus dem Serverzertifikat verwendet. Der Fehler betraf unter anderem OpenSSL und SecureTransport (Apple).<ref name="Beurdouche2015" /><ref name="SMACK" />
| |
|
| |
| Kurz darauf veröffentlichte ein Forscherteam den Logjam-Angriff, der einen Downgrade des [[Diffie-Hellman-Schlüsselaustausch]]s auf 512-Bit-Restklassengruppen ermöglicht. Ursache ist die Unterstützung von exporttauglichen Cipher Suites mit Ephemeral Diffie-Hellman.<ref>Cipher Suites mit „DHE_EXPORT“ im Namen.</ref> Anders als bei FREAK handelt es sich um eine Protokollschwäche in TLS, die auch ohne Implementierungsfehler ausgenutzt werden kann. Der Logjam-Angriff kann in der Praxis performant durchgeführt werden, da ein Großteil der Rechenarbeit zum Brechen des Schlüssels schon vor dem Verbindungsaufbau durchgeführt werden kann. Der erforderliche Rechenaufwand während des eigentlichen Schlüsselaustauschs dauert etwa 70 Sekunden. Als Schutzmaßnahme sollten Server die Unterstützung für exporttaugliche Cipher Suites abschalten und mindestens 2048 Bit lange Gruppen verwenden. Clients sollten Gruppen verwerfen, die kürzer als 1024 Bit sind.<ref name="Adrian2015" />
| |
|
| |
| === Implementierungsfehler ===
| |
|
| |
| Neben Sicherheitsschwächen im Protokoll sind TLS-Implementierungen in wiederkehrender Regelmäßigkeit von sicherheitsrelevanten Implementierungsfehlern betroffen. Einer der schwerwiegendsten Fehler war der 2014 entdeckte [[Heartbleed]]-Bug in [[OpenSSL]].
| |
|
| |
| === Öffentlicher und vorsätzlicher Bruch der Verschlüsselung ===
| |
|
| |
| Über die [[Europäisches Institut für Telekommunikationsnormen|ETSI]] wurde ein sozialer Angriff auf den TLS-Standard gestartet, bei dem eine nachschlüsselfähige und daher als gebrochen anzusehende Version des Standards Eingang in allgemeine Kommunikationsprozesse finden soll.
| |
|
| |
| Die Angreifer leiten eine Berechtigung für ihren Angriff auf die Verschlüsselung daraus ab, dass es in der Wirtschaft, insbesondere in der Finanzindustrie, sowie bei Behörden Möglichkeiten geben müsse, übergeordneten Einblick in verschlüsselte Kommunikation zu nehmen, ohne dass die Beteiligten davon erfahren.<ref>[https://heise.de/-3999118 ''TLS-Standardisierung: Behörden und Banken wollen Verschlüsselung aushöhlen''.] Heise Online; abgerufen am 2. März 2019</ref> Viele Fachleute und Organisationen, wie z. B. die [[Electronic Frontier Foundation|EFF]], warnen aufgrund der möglichen Kollateralschäden sehr deutlich vor der Nutzung dieses Verfahrens.<ref>[https://www.eff.org/deeplinks/2019/02/ets-isnt-tls-and-you-shouldnt-use-it ''ETS Isn’t TLS and You Shouldn’t Use It''.] EFF, abgerufen am 2. März 2019</ref>
| |
|
| |
| Der Versuch, diese defekte Verschlüsselung als „eTLS“ („Enterprise TLS“)<ref>[https://www.etsi.org/deliver/etsi_ts/103500_103599/10352303/01.01.01_60/ts_10352303v010101p.pdf ETSI TS 103 523-3: ''CYBER; Middlebox Security Protocol; Part 3: Profile for enterprise network and data centre access control''] (PDF; 235 kB) Technische Spezifikation der ETSI; abgerufen am 2. März 2019</ref> in die TLS-Familie einzuführen, wurde über die Namensrechte an TLS abgewehrt<ref>[https://heise.de/-4245220 ''IETF an ETSI: Finger weg von TLS''.] Heise Online; abgerufen am 3. Februar 2019</ref>, weshalb das Verfahren in ETS umbenannt werden wird.
| |
|
| |
| Da ETS/eTLS als [[Common Vulnerabilities and Exposures|CVE]] von TLS anerkannt ist, kann man ETS/eTLS auch als (vorsätzlich) fehlerhafte Implementierung von TLS bezeichnen.<ref>[https://nvd.nist.gov/vuln/detail/CVE-2019-9191 CVE-2019-9191 ''The ETSI Enterprise Transport Security (ETS, formerly known as eTLS) protocol does not provide per-session forward secrecy''.] nist.gov; abgerufen am 2. März 2019</ref>
| |
|
| |
| Infolgedessen erhielt das ''Technical Committee CYBER'' des ETSI 2019 den Negativpreis ''BigBrotherAward'':
| |
| {{Zitat
| |
| |Text=für seine Bemühung, das ‚Enterprise Transport Security‘ Protokoll (ETS) als Teil des neuen technischen Standards für die Verschlüsselung im Internet festzulegen und damit abgesicherte Verbindungen mit einer Sollbruchstelle auszustatten
| |
| |Autor=Frank Rosengart
| |
| |Quelle=Laudatio bei den [[BigBrotherAwards]]
| |
| |ref=<ref>{{Internetquelle |autor=Frank Rosengart |url=https://bigbrotherawards.de/2019/technik-etsi-cyber-committee |titel=Laudatio Technik: „Technical Committee CYBER“ des Europäischen Instituts für Telekommunikationsnormen (ETSI) |werk=bigbrotherawards.de |datum=2019-06-08 |abruf=2019-06-21}}</ref>}}
| |
|
| |
| == Vor- und Nachteile ==
| |
|
| |
| Der Vorteil des TLS-Protokolls ist die Möglichkeit, jedes höhere Protokoll auf Basis des TLS-Protokolls zu implementieren. Damit ist eine Unabhängigkeit von Anwendungen und Systemen gewährleistet.
| |
|
| |
| Der Nachteil der TLS-verschlüsselten Übertragung besteht darin, dass der Verbindungsaufbau auf Serverseite rechenintensiv und deshalb langsamer ist. Die Verschlüsselung selbst beansprucht je nach verwendetem [[Algorithmus]] nur wenig Rechenzeit.
| |
|
| |
| Verschlüsselte Daten sind auf niedrigeren Schichten (etwa auf [[Point-to-Point Tunneling Protocol|PPTP]]-Ebene) kaum durch Kompression zu verdichten.
| |
|
| |
| TLS verschlüsselt nur die Kommunikation zwischen zwei Stationen. Es sind Szenarien in [[Serviceorientierte Architektur|serviceorientierten Architekturen]] denkbar, in denen eine Nachricht über mehrere Stationen gesendet wird. Wenn jede Station nur einen Teil der Nachricht lesen darf, reicht TLS nicht aus, da jede Station alle Daten der Nachricht entschlüsseln kann. Somit entstehen Sicherheitslücken an jeder Station, die nicht für sie bestimmte Daten entschlüsseln kann.
| |
|
| |
| == Implementierungen ==
| |
|
| |
| Zu den bekanntesten [[Programmbibliothek]]en, die Transport Layer Security implementieren, gehören:
| |
| * [[OpenSSL]]
| |
| * [[GnuTLS]]
| |
| * [[LibreSSL]]
| |
| * [[Network Security Services]]
| |
| * [[mbed TLS]], vormals PolarSSL
| |
| * [[OpenSSL#Abspaltungen|BoringSSL]]<ref>[https://www.heise.de/newsticker/meldung/Google-entwickelt-eigene-SSL-Bibliothek-2236224.html ''Google entwickelt eigene SSL-Bibliothek''] auf heise online</ref>
| |
| * [[Cryptlib]]
| |
| * [[SChannel]] (Microsoft)
| |
| * [[WolfSSL]]
| |
|
| |
| == Siehe auch ==
| |
|
| |
| * [[IPsec]]
| |
|
| |
| == Literatur ==
| |
|
| |
| * Eric Rescorla: ''SSL and TLS. Designing and building secure systems.'' Addison-Wesley, New York NY u. a. 2001, ISBN 0-201-61598-3.
| |
| * Roland Bless u. a.: ''Sichere Netzwerkkommunikation. Grundlagen, Protokolle und Architekturen.'' Springer Verlag, Berlin u. a. 2005, ISBN 3-540-21845-9, (''X.systems.press'').
| |
| * [[Claudia Eckert]]: ''IT-Sicherheit. Konzepte – Verfahren – Protokolle.'' 6. überarbeitete Auflage. Oldenbourg, München u. a. 2009, ISBN 978-3-486-58999-3.
| |
|
| |
| == Weblinks ==
| |
| * [https://datatracker.ietf.org/wg/tls/documents/ TLS-Arbeitsgruppe] der IETF
| |
| * {{RFC-Internet |Autor=Dierks, Rescorla |RFC=5246 |Titel=TLS 1.2 Spezifikation (Proposed Standard) |Datum=2008-08 |Obsoletes=4346}}
| |
| * {{Webarchiv |url=http://wp.netscape.com/eng/ssl3/ |text=SSL 3.0 Spezifikation |wayback=20080208141212}}
| |
| * [https://www.repges.net/SSL/ssl.html Einführung in SSL von Markus Repges] Beschreibt Handshake und Protokoll im Detail
| |
| * [https://www.youtube.com/watch?v=W5crwV9KGUw Funktionsweise einer SSL-Verschlüsselung von Websites] im Video
| |
| * [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.pdf?__blob=publicationFile&v=7 Aktuelle Richtlinie BSI TR-02102-2 „Kryptographische Verfahren: Verwendung von Transport Layer Security (TLS)“] (PDF) mit Auflistung der empfohlenen Cipher Suiten für TLS 1.2 und 1.3; Stand: Februar 2019
| |
|
| |
| == Einzelnachweise ==
| |
|
| |
| <references responsive>
| |
| <ref name="Adrian2015">
| |
| {{Literatur
| |
| |Autor=David Adrian, Karthikeyan Bhargavan, Zakir Durumeric, Pierrick Gaudry, Matthew Green, J. Alex Halderman, Nadia Heninger, Drew Springall, Emmanuel Thomé, Luke Valenta, Benjamin VanderSloot, Eric Wustrow, Santiago Zanella-Béguelin, Paul Zimmermann
| |
| |Titel=Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice
| |
| |Sammelwerk=Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security
| |
| |Verlag=ACM
| |
| |Ort=New York
| |
| |Datum=2015
| |
| |Seiten=5–17
| |
| |Online=[https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf weakdh.org]
| |
| |Format=PDF
| |
| |KBytes=
| |
| |DOI=10.1145/2810103.2813707}}
| |
| </ref>
| |
| <ref name="AlFardan2013">
| |
| {{Literatur
| |
| |Autor=Nadhem J. AlFardan, Kenneth G. Paterson
| |
| |Titel=Lucky Thirteen: Breaking the TLS and DTLS Record Protocols
| |
| |Sammelwerk=IEEE Symposium on Security and Privacy
| |
| |Verlag=IEEE
| |
| |Datum=2013
| |
| |Seiten=526–540
| |
| |Online=[https://www.ieee-security.org/TC/SP2013/papers/4977a526.pdf ieee-security.org]
| |
| |Format=PDF
| |
| |KBytes=
| |
| |DOI=10.1109/SP.2013.42}}
| |
| </ref>
| |
| <ref name="Bard2004">
| |
| {{Literatur
| |
| |Autor=Gregory V. Bard
| |
| |Titel=The Vulnerability of SSL to Chosen Plaintext Attack
| |
| |Sammelwerk=Cryptology ePrint Archive
| |
| |Datum=2004
| |
| |Online=[https://eprint.iacr.org/2004/111.pdf iacr.org]
| |
| |Format=PDF
| |
| |KBytes=
| |
| |DOI=10.1145/586110.586125}}
| |
| </ref>
| |
| <ref name="Beurdouche2015">
| |
| {{Literatur
| |
| |Autor=Benjamin Beurdouche, Karthikeyan Bhargavan, Antoine Delignat-Lavaud, Cédric Fournet, Markulf Kohlweiss, Alfredo Pironti, Pierre-Yves Strub, Jean Karim Zinzindohoue
| |
| |Titel=A Messy State of the Union: Taming the Composite State Machines of TLS
| |
| |Sammelwerk=IEEE Symposium on Security and Privacy
| |
| |Verlag=IEEE
| |
| |Datum=2015
| |
| |Seiten=535–552
| |
| |Online=[http://research.microsoft.com/en-US/about/papers/taming-the-composite-state-machine-of-tls.pdf research.microsoft.com]
| |
| |Format=PDF
| |
| |KBytes=
| |
| |DOI=10.1109/SP.2015.39}}
| |
| </ref>
| |
| <ref name="Duong2011">
| |
| {{Internetquelle
| |
| |autor=Thai Duong, Juliano Rizzo
| |
| |url=http://www.hit.bme.hu/~buttyan/courses/EIT-SEC/abib/04-TLS/BEAST.pdf
| |
| |titel=Here Come The Ninjas
| |
| |datum=2011-05-13
| |
| |format=PDF
| |
| |abruf=2016-01-10}}
| |
| </ref>
| |
| <ref name="BEAST">
| |
| {{Internetquelle
| |
| |autor=Juliano Rizzo, Thai Duong
| |
| |url=https://packetstormsecurity.com/files/105499/Browser-Exploit-Against-SSL-TLS.html
| |
| |titel=Browser Exploit Against SSL/TLS
| |
| |datum=2011-10-03
| |
| |abruf=2016-01-10}}
| |
| </ref>
| |
| <ref name="CRIME">
| |
| {{Internetquelle
| |
| |autor=Juliano Rizzo, Thai Duong
| |
| |url=https://www.ekoparty.org/archive/2012/CRIME_ekoparty2012.pdf
| |
| |titel=The CRIME attack
| |
| |datum=2012
| |
| |format=PDF
| |
| |abruf=2016-01-11
| |
| |kommentar=Präsentation bei der [[Ekoparty]] 2012.}}
| |
| </ref>
| |
| <ref name="RFC3546">
| |
| {{RFC-Internet |RFC=3546 |Titel=Transport Layer Security (TLS) Extensions |Datum=}}
| |
| </ref>
| |
| <ref name="RFC7457">
| |
| {{RFC-Internet |Autor= |RFC=7457 |Titel=Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS) |Datum=2015-02}}
| |
| </ref>
| |
| <ref name="RFC7507">
| |
| {{RFC-Internet |Autor= |RFC=7507 |Titel=TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks |Datum=2015-04}}
| |
| </ref>
| |
| <ref name="RFC7541">
| |
| {{RFC-Internet |Autor= |RFC=7541 |Titel=HPACK: Header Compression for HTTP/2 |Datum=2015-05}}
| |
| </ref>
| |
| <ref name="RFC7568">
| |
| {{RFC-Internet |Autor= |RFC=7568 |Titel=Deprecating Secure Sockets Layer Version 3.0 |Datum=2015-06}}
| |
| </ref>
| |
| <ref name="RFC8446">
| |
| {{RFC-Internet |Autor= |RFC=8446 |Titel=The Transport Layer Security (TLS) Protocol Version 1.3 |Datum=2018-08}}
| |
| </ref>
| |
| <ref name="SMACK">
| |
| {{Internetquelle
| |
| |autor=Benjamin Beurdouche, Karthikeyan Bhargavan, Antoine Delignat-Lavaud, Cédric Fournet, Markulf Kohlweiss, Alfredo Pironti, Pierre-Yves Strub, Jean Karim Zinzindohoue
| |
| |url=https://mitls.org/downloads/SmackTLS-Oakland15.pdf
| |
| |titel=A messy state of the union: Taming the Composite State Machines of TLS
| |
| |datum=2015
| |
| |format=PDF
| |
| |abruf=2016-01-11
| |
| |kommentar=Präsentationsfolien}}
| |
| </ref>
| |
| <ref name="TIME">
| |
| {{Internetquelle
| |
| |autor=Tal Be’ery, Amichai Shulman
| |
| |url=https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-13-a-perfect-crime-beery-wp.pdf
| |
| |titel=A Perfect CRIME? Only TIME Will Tell
| |
| |datum=2013
| |
| |format=PDF
| |
| |abruf=2016-01-11}}
| |
| </ref>
| |
| <ref name="Vaudenay2002">
| |
| {{Literatur
| |
| |Autor=Serge Vaudenay
| |
| |Titel=Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS…
| |
| |Sammelwerk=Advances in Cryptology – EUROCRYPT 2002
| |
| |Reihe=Lecture Notes in Computer Science
| |
| |Band=2332
| |
| |Verlag=Springer
| |
| |Ort=Berlin / Heidelberg
| |
| |Datum=2002
| |
| |Seiten=535–545
| |
| |Online=[https://www.iacr.org/cryptodb/archive/2002/EUROCRYPT/2850/2850.pdf iacr.org]
| |
| |Format=PDF
| |
| |KBytes=
| |
| |DOI=10.1145/586110.586125}}
| |
| </ref>
| |
| </references>
| |
|
| |
| [[Kategorie:Transport Layer Security| ]]
| |
| [[Kategorie:Verschlüsselungsprotokoll]]
| |
| [[Kategorie:Kryptologischer Standard]]
| |
|
| |
|
| |
|
| [[Kategorie:TLS]] | | [[Kategorie:TLS]] |
| </noinclude> | | </noinclude> |