Transport Layer Security: Unterschied zwischen den Versionen

Aus Foxwiki
Zeile 154: Zeile 154:


=== Geschichte ===
=== 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
[[Transport Layer Security/Geschichte]]
* 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&nbsp;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&nbsp;4346 die Version 1.1 von TLS standardisiert und damit RFC&nbsp;2246 obsolet
* In TLS 1.1 wurden kleinere Sicherheitsverbesserungen vorgenommen und Unklarheiten beseitigt
* Im August 2008 erschien mit RFC&nbsp;5246 die Version 1.2 von TLS, welche RFC&nbsp;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&nbsp;7465
 
* Im Mai 2015 wurden mit RFC&nbsp;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&nbsp;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&nbsp;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&nbsp;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 ==
== Funktionsweise ==

Version vom 25. Februar 2024, 13:44 Uhr

Transport Layer Security (TLS) - Kurzbeschreibung

Beschreibung

TLS im TCP/IP-Protokollstapel
Anwendung
HTTPS IMAPS POP3S SMTPS
TLS
Transport TCP
Internet IP (IPv4, IPv6)
Netzzugang Ethernet Token
Bus
Token
Ring
FDDI

Transport Layer Security (TLS, für „Transportschichtsicherheit“)

Hauptkomponenten

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 MAC gegen Veränderungen geschützt übertragen
Schlüsselaustausch

Für den Schlüsselaustausch sind in den älteren TLS-Versionen verschiedene Algorithmen mit unterschiedlichen Sicherheitsgarantien im Einsatz

Implementierungen

Zu den bekanntesten Programmbibliotheken, die Transport Layer Security implementieren, gehören:

TLS in der Praxis

TLS-Verschlüsselung wird gegenwärtig vor allem mit 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
  • In aktuellen Browsern ist SSLv3 und SSLv2 deaktiviert, da diese Protokollversion eine Reihe von Sicherheitslücken, unter anderem des Poodle-Angriffs aufweist
TLS 1.3

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)

Das Deutsche Bundesamt für Sicherheit in der Informationstechnik empfiehlt bei der Verwendung von TLS die Versionen 1.2 und 1.3. Cipher Suiten mit Perfect Forward Secrecy werden bevorzugt empfohlen

Seit einiger Zeit nutzen immer mehr Webseitenbetreiber 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 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 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

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 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

In Verbindung mit einem virtuellen Server, zum Beispiel mit 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 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 RFC 3546 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 (DNS) ein Schlüssel hinterlegt und verschlüsseltes DNS genutzt werden

Im 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 HTTPS als verschlüsselte Variante von HTTP sind weitere bekannte Anwendungsfälle für TLS beispielsweise:

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

Version Erscheinungsjahr Bemerkungen
1994
1995 seit März 2011 überholt
1996 seit Juni 2015 überholt
1999 seit März 2021 überholt
2006 seit März 2021 überholt
2008
2018 RFC 8446, enthält auch neue Anforderungen für TLS 1.2

Geschichte

Transport Layer Security/Geschichte

Funktionsweise

Transport Layer Security/Funktionsweise

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 Algorithmus nur wenig Rechenzeit

Verschlüsselte Daten sind auf niedrigeren Schichten (etwa auf PPTP-Ebene) kaum durch Kompression zu verdichten

TLS verschlüsselt nur die Kommunikation zwischen zwei Stationen

  • Es sind Szenarien in 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


Anhang

Siehe auch


Links

Weblinks
  1. https://de.wikipedia.org/wiki/Transport_Layer_Security