Transport Layer Security (TLS, englisch 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 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 verwendet allerdings nur noch das Diffie-Hellman-SchlĂŒsselaustauschprotokoll (DHE oder ECDHE). Dabei wird fĂŒr jede Verbindung ein neuer SitzungsschlĂŒssel (Session Key) ausgehandelt. Da dies ohne Verwendung eines LangzeitschlĂŒssels geschieht, erreicht TLS 1.3 Perfect Forward Secrecy.
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. 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 Ve