Transport Layer Security

Transport Layer Security ( TLS ) ist ein kryptografisches Protokoll, das die Sicherheit der Kommunikation in Computernetzwerken wie dem Internet gewährleisten soll . Das Protokoll findet breite Anwendung in Diensten wie E-Mail , Instant Messaging und Voice over IP , seine Verwendung zur Sicherung von HTTPS ist jedoch nach wie vor am weitesten verbreitet.

Das TLS-Protokoll dient primär der Gewährleistung von Sicherheit, einschließlich Vertraulichkeit , Integrität und Authentizität durch Kryptografie , beispielsweise durch Zertifikate , zwischen zwei oder mehr kommunizierenden Computeranwendungen. Es läuft auf der Präsentationsschicht und besteht selbst aus zwei Schichten: dem TLS-Datensatz und dem TLS- Handshake-Protokoll .

Das eng verwandte Datagram Transport Layer Security (DTLS) ist ein Kommunikationsprotokoll , das Sicherheit für datagrammbasierte Anwendungen bietet . In technischen Dokumentationen wird häufig von „(D)TLS“ gesprochen, wenn damit beide Versionen gemeint sind. ^{[ 1 ]}

TLS ist ein von der Internet Engineering Task Force (IETF) vorgeschlagener Standard, der erstmals 1999 definiert wurde. Die aktuelle Version ist TLS 1.3, definiert im August 2018. TLS baut auf den mittlerweile veralteten SSL- Spezifikationen ( Secure Sockets Layer ) (1994, 1995, 1996) auf, die von Netscape Communications zur Integration des HTTPS- Protokolls in ihren Webbrowser Netscape Navigator entwickelt wurden.

Client-Server -Anwendungen nutzen das TLS- Protokoll zur Kommunikation über ein Netzwerk auf eine Weise, die das Abhören und Manipulieren verhindern soll .

Da Anwendungen sowohl mit als auch ohne TLS (oder SSL) kommunizieren können, muss der Client den Server auffordern, eine TLS-Verbindung herzustellen. ^{[ 2 ]} Eine der wichtigsten Methoden hierfür ist die Verwendung eines anderen Ports für TLS-Verbindungen. Port 80 wird üblicherweise für unverschlüsselten HTTP- Verkehr verwendet, während Port 443 der gängige Port für verschlüsselten HTTPS- Verkehr ist. Alternativ kann eine protokollspezifische STARTTLS -Anfrage an den Server gesendet werden, um die Verbindung auf TLS umzuschalten – beispielsweise bei bestimmten E-Mail- und News- Protokollen.

Sobald Client und Server die Verwendung von TLS vereinbart haben, verhandeln sie eine zustandsbehaftete Verbindung mittels eines Handshake-Verfahrens (siehe § TLS-Handshake ). ^{[ 3 ]} Die Protokolle verwenden einen Handshake mit einer asymmetrischen Verschlüsselung , um nicht nur die Verschlüsselungseinstellungen, sondern auch einen sitzungsspezifischen gemeinsamen Schlüssel festzulegen, mit dem die weitere Kommunikation mittels einer symmetrischen Verschlüsselung verschlüsselt wird . Während dieses Handshakes einigen sich Client und Server auf verschiedene Parameter, die zur Gewährleistung der Verbindungssicherheit dienen:

• Der Handshake beginnt, wenn ein Client eine Verbindung zu einem TLS-fähigen Server herstellt und eine sichere Verbindung anfordert. Der Client präsentiert eine Liste der unterstützten Cipher Suites ( Verschlüsselungsverfahren und Hash-Funktionen ).
• Aus dieser Liste wählt der Server eine Verschlüsselungs- und Hash-Funktion aus, die er ebenfalls unterstützt, und benachrichtigt den Client über die Entscheidung.
• Der Server stellt dann üblicherweise eine Identifizierung in Form eines digitalen Zertifikats bereit . Das Zertifikat enthält den Servernamen , die vertrauenswürdige Zertifizierungsstelle (CA), die die Echtheit des Zertifikats bestätigt, und den öffentlichen Verschlüsselungsschlüssel des Servers.
• Der Kunde bestätigt vor dem Fortfahren die Gültigkeit des Zertifikats.
• Um die für die sichere Verbindung verwendeten Sitzungsschlüssel zu generieren, hat der Client entweder:
  • verschlüsselt eine Zufallszahl ( PreMasterSecret ) mit dem öffentlichen Schlüssel des Servers und sendet das Ergebnis an den Server (das nur der Server mit seinem privaten Schlüssel entschlüsseln können sollte); beide Parteien verwenden dann die Zufallszahl, um einen eindeutigen Sitzungsschlüssel für die nachfolgende Ver- und Entschlüsselung von Daten während der Sitzung zu generieren, oder
  • verwendet den Diffie-Hellman-Schlüsselaustausch (oder seine Variante elliptischer Kurven DH ), um sicher einen zufälligen und eindeutigen Sitzungsschlüssel für die Ver- und Entschlüsselung zu generieren, der die zusätzliche Eigenschaft der Vorwärtsgeheimhaltung besitzt : Wenn der private Schlüssel des Servers in Zukunft offengelegt wird, kann er nicht zur Entschlüsselung der aktuellen Sitzung verwendet werden, selbst wenn die Sitzung von einem Dritten abgefangen und aufgezeichnet wird.

Damit ist der Handshake abgeschlossen und die sichere Verbindung wird aufgebaut, die bis zum Verbindungsabbruch mit dem Sitzungsschlüssel verschlüsselt und entschlüsselt wird. Schlägt einer der oben genannten Schritte fehl, schlägt der TLS-Handshake fehl und die Verbindung wird nicht hergestellt.

Beachten Sie, dass TLS 1.3 nur Schlüsselaustauschalgorithmen mit Vorwärtsgeheimhaltung zulässt . Daher ist die Einrichtung eines PreMasterSecrets mithilfe des öffentlichen und privaten Schlüssels des Servers nur in TLS 1.2 und älteren Versionen möglich.

TLS und SSL lassen sich keiner einzelnen Schicht des OSI- oder TCP/IP-Modells eindeutig zuordnen . ^{[ 4 ] [ 5 ]} TLS läuft „auf einem zuverlässigen Transportprotokoll (z. B. TCP )“ ^{[ 6 ] : §1} , was bedeutet, dass es oberhalb der Transportschicht angesiedelt ist . Es dient der Verschlüsselung höherer Schichten, was normalerweise Aufgabe der Darstellungsschicht ist . Anwendungen verwenden TLS jedoch im Allgemeinen so, als wäre es eine Transportschicht ^{[ 4 ] [ 5 ],} obwohl Anwendungen, die TLS verwenden, die Initiierung von TLS-Handshakes und die Handhabung ausgetauschter Authentifizierungszertifikate aktiv steuern müssen. ^{[ 6 ] : §1}

Wenn Verbindungen durch TLS gesichert sind, weisen sie zwischen einem Client (z. B. einem Webbrowser) und einem Server (z. B. wikipedia.org) alle folgenden Eigenschaften auf: ^{[ 6 ] : §1}

• Die Verbindung ist privat (bzw. vertraulich ), da die übertragenen Daten mit einem symmetrischen Verschlüsselungsalgorithmus verschlüsselt werden. Die Schlüssel für diese symmetrische Verschlüsselung werden für jede Verbindung individuell generiert und basieren auf einem gemeinsamen Geheimnis, das zu Beginn der Sitzung ausgehandelt wurde. Server und Client verhandeln die Details des zu verwendenden Verschlüsselungsalgorithmus und der kryptografischen Schlüssel, bevor das erste Datenbyte übertragen wird (siehe unten). Die Aushandlung des gemeinsamen Geheimnisses ist sowohl sicher (das ausgehandelte Geheimnis ist für Abhörer nicht zugänglich und kann selbst von einem Angreifer, der sich in die Verbindung einmischt, nicht erlangt werden) als auch zuverlässig (kein Angreifer kann die Kommunikation während der Aushandlung unbemerkt verändern).
• Die Identität der Kommunikationspartner kann mittels Public-Key-Kryptographie authentifiziert werden . Diese Authentifizierung ist für den Server erforderlich und für den Client optional.
• Die Verbindung ist zuverlässig (oder intakt ), da jede übertragene Nachricht eine Integritätsprüfung mittels eines Nachrichtenauthentifizierungscodes beinhaltet , um einen unbemerkten Verlust oder eine Veränderung der Daten während der Übertragung zu verhindern.

TLS unterstützt viele verschiedene Methoden zum Schlüsselaustausch, zur Datenverschlüsselung und zur Authentifizierung der Nachrichtenintegrität. Daher umfasst die sichere Konfiguration von TLS viele konfigurierbare Parameter, und nicht alle Optionen bieten alle oben beschriebenen datenschutzrelevanten Eigenschaften (siehe die Tabellen unten § Schlüsselaustausch , § Verschlüsselungssicherheit und § Datenintegrität ).

Es wurden Versuche unternommen, die von TLS angestrebte Kommunikationssicherheit zu untergraben, und das Protokoll wurde mehrfach überarbeitet, um diesen Sicherheitsbedrohungen zu begegnen. Entwickler von Webbrowsern haben ihre Produkte wiederholt aktualisiert, um potenzielle Sicherheitslücken nach deren Entdeckung zu schließen (siehe TLS/SSL-Unterstützungshistorie von Webbrowsern).

Datagram Transport Layer Security (DTLS) ist ein verwandtes Kommunikationsprotokoll , das datagrammbasierten Anwendungen Sicherheit bietet , indem es deren Kommunikation auf eine Weise ermöglicht, die ^{[ 7 ] [ 8 ]} das Abhören , Manipulieren und Fälschen von Nachrichten verhindern soll . Das DTLS-Protokoll basiert auf dem streamorientierten Transport Layer Security (TLS)-Protokoll und bietet ähnliche Sicherheitsgarantien. Im Gegensatz zu TLS ist es jedoch mit den meisten datagrammorientierten Protokollen kompatibel, darunter User Datagram Protocol (UDP), Datagram Congestion Control Protocol (DCCP), Control And Provisioning of Wireless Access Points (CAPWAP), Stream Control Transmission Protocol (SCTP)-Kapselung und Secure Real-time Transport Protocol (SRTP).

Da das DTLS-Protokoll-Datagramm die Semantik des zugrundeliegenden Transports beibehält, treten bei der Anwendung keine Verzögerungen auf, die mit Stream-Protokollen verbunden sind. Allerdings muss die Anwendung mit Paketumordnung , Datagrammverlust und Datenmengen, die größer als ein Datagramm- ^{Netzwerkpaket sind, umgehen. Da DTLS UDP oder SCTP anstelle von TCP verwendet, vermeidet es das TCP-Meltdown-Problem [9} ] [ 10 ] ^{beim Aufbau eines VPN -} Tunnels.

Die ursprüngliche 2006 veröffentlichte Version 1.0 von DTLS war kein eigenständiges Dokument. Sie wurde als Reihe von Deltas zu TLS 1.1 bereitgestellt. ^{[ 7 ] : §4} Auch die Nachfolgeversion von DTLS aus dem Jahr 2012 ist ein Delta zu TLS 1.2. Sie erhielt die Versionsnummer von DTLS 1.2, um ihrer TLS-Version zu entsprechen. Schließlich ist DTLS 1.3 aus dem Jahr 2022 ein Delta zu TLS 1.3. Wie die beiden Vorgängerversionen soll auch DTLS 1.3 „gleichwertige Sicherheitsgarantien [zu TLS 1.3] mit Ausnahme des Schutzes der Befehlsreihenfolge/der Nichtwiederholbarkeit“ bieten. ^{[ 11 ]}

Viele VPN-Clients, darunter Cisco AnyConnect ^{[ 12 ]} und InterCloud Fabric ^{[ 13 ]} , OpenConnect ^{[ 14 ]} , ZScaler Tunnel ^{[ 15 ]} , F5 Networks Edge VPN Client ^{[ 16 ]} und Citrix Systems NetScaler ^{[ 17 ]} , verwenden DTLS zur Sicherung des UDP-Verkehrs. Darüber hinaus unterstützen alle modernen Webbrowser DTLS-SRTP ^{[ 18 ]} für WebRTC .

Im August 1986 starteten die National Security Agency (NSA), das National Bureau of Standards (NBS) und die Defense Communications Agency (DCA) das Projekt Secure Data Network System (SDNS). Ziel war die Entwicklung der nächsten Generation sicherer Computerkommunikationsnetzwerke und Produktspezifikationen für Anwendungen im öffentlichen und privaten Internet. Das SDNS sollte die rasch entstehenden neuen OSI-Internetstandards ergänzen, die sowohl in den GOSIP-Profilen der US-Regierung als auch im Rahmen der umfangreichen internationalen ITU-ISO-JTC1-Internetinitiative vorangetrieben wurden. ^{[ 28 ]}

Im Rahmen des Projekts entwickelten die Forscher ein Protokoll namens SP4 ( Sicherheitsprotokoll der Schicht 4 des OSI-Systems). Dieses wurde später in Transport Layer Security Protocol (TLSP) umbenannt und 1995 als internationaler Standard ITU-T X.274|ISO/IEC 10736:1995 veröffentlicht. ^{[ 29 ]} Trotz der Namensähnlichkeit unterscheidet es sich vom heutigen TLS.

Weitere Bemühungen um die Sicherheit der Transportschicht umfassten die Secure Network Programming ( SNP) API, die 1993 den Ansatz einer sicheren Transportschicht-API nach dem Vorbild von Berkeley Sockets untersuchte , um die Nachrüstung bestehender Netzwerkanwendungen mit Sicherheitsmaßnahmen zu erleichtern. SNP wurde 1994 auf der USENIX Summer Technical Conference veröffentlicht und vorgestellt. ^{[ 30 ] [ 31 ]} Das SNP-Projekt wurde 1991 durch ein Stipendium der NSA an Professor Simon Lam an der UT Austin finanziert. ^{[ 32 ]} Secure Network Programming gewann 2004 den ACM Software System Award . ^{[ 33 ] [ 34 ]} Simon Lam wurde in die Internet Hall of Fame aufgenommen , weil er 1991 Secure Sockets erfunden und 1993 die erste Secure-Sockets-Schicht namens SNP implementiert hatte. ^{[ 35 ] [ 36 ]}

Netscape entwickelte die ursprünglichen SSL-Protokolle, und Taher Elgamal , leitender Wissenschaftler bei Netscape Communications von 1995 bis 1998, gilt als der „Vater von SSL“. ^{[ 37 ] [ 38 ] [ 39 ] [ 40 ]} SSL Version 1.0 wurde aufgrund schwerwiegender Sicherheitslücken im Protokoll nie öffentlich freigegeben. Version 2.0, die im Februar 1995 veröffentlicht wurde, wies schnell eine Reihe von Sicherheits- und Benutzerfreundlichkeitsmängeln auf. Sie verwendete dieselben kryptografischen Schlüssel für die Nachrichtenauthentifizierung und -verschlüsselung. Die MAC-Konstruktion war schwach und nutzte die MD5-Hashfunktion mit einem geheimen Präfix, wodurch sie anfällig für Längenerweiterungsangriffe war. Weder der Eröffnungs-Handshake noch der explizite Nachrichtenabschluss boten Schutz, wodurch Man-in-the-Middle-Angriffe unentdeckt bleiben konnten. Darüber hinaus setzte SSL 2.0 einen einzelnen Dienst und ein festes Domänenzertifikat voraus, was mit dem weit verbreiteten virtuellen Hosting auf Webservern kollidierte. Daher war die Nutzung von SSL für die meisten Websites praktisch unmöglich.

Diese Mängel machten eine vollständige Neuentwicklung des Protokolls hin zu SSL Version 3.0 erforderlich. ^{[ 41 ] [ 39 ]} Die 1996 veröffentlichte Version wurde von Paul Kocher in Zusammenarbeit mit den Netscape-Ingenieuren Phil Karlton und Alan Freier entwickelt. Eine Referenzimplementierung stammte von Christopher Allen und Tim Dierks von Certicom. Neuere Versionen von SSL/TLS basieren auf SSL 3.0. Der Entwurf von SSL 3.0 aus dem Jahr 1996 wurde von der IETF als historisches Dokument in RFC  6101 veröffentlicht .

SSL 2.0 wurde 2011 mit RFC  6176 als veraltet eingestuft . 2014 wurde festgestellt, dass SSL 3.0 anfällig für den POODLE- Angriff ist, der alle Blockchiffren in SSL betrifft; RC4 , die einzige von SSL 3.0 unterstützte Nicht-Blockchiffre, ist in der verwendeten Form ebenfalls angreifbar. ^{[ 42 ]} SSL 3.0 wurde im Juni 2015 mit RFC  7568 endgültig als veraltet erklärt .

TLS 1.0 wurde erstmals im Januar 1999 in RFC  2246 als Upgrade von SSL Version 3.0 definiert und von Christopher Allen und Tim Dierks von Certicom entwickelt. Wie im RFC festgehalten, sind die Unterschiede zwischen diesem Protokoll und SSL 3.0 zwar nicht dramatisch, aber dennoch so bedeutend, dass eine Interoperabilität zwischen TLS 1.0 und SSL 3.0 ausgeschlossen ist. Tim Dierks schrieb später, dass diese Änderungen und die Umbenennung von „SSL“ in „TLS“ ein Versuch waren, Microsoft zu beschwichtigen, „damit es nicht so aussah, als würde die IETF das Protokoll von Netscape einfach absegnen“. ^{[ 43 ]}

Der PCI Council empfahl Unternehmen, bis zum 30. Juni 2018 von TLS 1.0 auf TLS 1.1 oder höher umzusteigen. ^{[ 44 ] [ 45 ]} Im Oktober 2018 kündigten Apple , Google , Microsoft und Mozilla gemeinsam an, TLS 1.0 und 1.1 im März 2020 als veraltet zu kennzeichnen. ^{[ 22 ]} TLS 1.0 und 1.1 wurden im März 2021 mit RFC  8996 offiziell als veraltet erklärt .

TLS 1.1 wurde im April 2006 in RFC  4346 definiert. ^{[ 46 ]} Es handelt sich um ein Update von TLS Version 1.0. Zu den wesentlichen Unterschieden dieser Version gehören:

• Zusätzlicher Schutz gegen Cipher-Block Chaining (CBC)-Angriffe.
  • Der implizite Initialisierungsvektor (IV) wurde durch einen expliziten IV ersetzt.
  • Änderung im Umgang mit Padding-Fehlern .
• Unterstützung für die IANA- Registrierung von Parametern. ^{[ 47 ]}

Die Unterstützung für TLS-Versionen 1.0 und 1.1 wurde um das Jahr 2020 von vielen Webseiten als veraltet eingestuft ^{[ 48 ],} wodurch der Zugriff auf Firefox- Versionen vor 24 und Chromium-basierte Browser vor 29 nicht mehr möglich war ^{[ 49 ].} Allerdings können Drittanbieter-Lösungen für Netscape Navigator und ältere Firefox-Versionen angewendet werden, um die Unterstützung für TLS 1.2 wiederherzustellen ^{[ 50 ] .}

TLS 1.2 wurde im August 2008 in RFC  5246 definiert. ^{[ 25 ]} Es basiert auf der früheren TLS-1.1-Spezifikation. Zu den wichtigsten Unterschieden gehören:

• Die Kombination aus MD5 und SHA-1 in der Pseudozufallsfunktion (PRF) wurde durch SHA-256 ersetzt , wobei die Möglichkeit besteht, PRFs mit spezifizierten Cipher Suites zu verwenden.
• Die Kombination aus MD5 und SHA-1 im Hash der fertigen Nachricht wurde durch SHA-256 ersetzt, wobei optional verschlüsselungsspezifische Hash-Algorithmen verwendet werden können. Die Größe des Hashs in der fertigen Nachricht muss jedoch weiterhin mindestens 96 Bit betragen . ^{[ 25 ] : §7.4.9}
• Die Kombination aus MD5 und SHA-1 im digital signierten Element wurde durch einen einzelnen Hash ersetzt, der während des Handshakes ausgehandelt wird und standardmäßig SHA-1 ist.
• Verbesserung der Möglichkeiten von Client und Server, festzulegen, welche Hash- und Signaturalgorithmen akzeptiert werden.
• Erweiterung der Unterstützung für authentifizierte Verschlüsselungsalgorithmen , die hauptsächlich für den Galois/Counter Mode (GCM) und den CCM-Modus der Advanced Encryption Standard (AES)-Verschlüsselung verwendet werden.
• Die Definition von TLS-Erweiterungen und AES-Verschlüsselungssammlungen wurde hinzugefügt. ^{[ 47 ]}

Alle TLS-Versionen wurden im März 2011 in RFC  6176 weiter verfeinert. Dabei wurde die Abwärtskompatibilität mit SSL aufgehoben, sodass TLS-Sitzungen niemals die Verwendung von Secure Sockets Layer (SSL) Version 2.0 aushandeln. Für die Abschaffung von TLS 1.2 gibt es derzeit (Stand: April 2025) kein offizielles Datum. Die Spezifikationen für TLS 1.2 wurden im Standards Track Document RFC  8446 ebenfalls neu definiert , um die größtmögliche Sicherheit zu gewährleisten. Es dient nun als Ausweichprotokoll und ist nur noch für Clients vorgesehen, die TLS 1.3 nicht nutzen können. (Die ursprüngliche Definition von TLS 1.2 in RFC  5246 ist inzwischen überholt.)

TLS 1.3 wurde im August 2018 in RFC  8446 definiert. ^{[ 6 ]} Es basiert auf der früheren TLS-1.2-Spezifikation. Zu den wesentlichen Unterschieden gegenüber TLS 1.2 gehören: ^{[ 51 ]}

• Trennung der Schlüsselaustausch- und Authentifizierungsalgorithmen von den Verschlüsselungssuiten ^{[ 47 ] [ 6 ] : §11}
• Entfernung der Unterstützung für schwache und weniger gebräuchliche benannte elliptische Kurven
• Die Unterstützung für die kryptografischen Hashfunktionen MD5 und SHA-224 wird entfernt.
• Digitale Signaturen auch dann erforderlich, wenn eine vorherige Konfiguration verwendet wird
• Integration von HKDF und dem semi-ephemeren DH-Vorschlag
• Wiederaufnahme wird durch PSK und Tickets ersetzt
• Unterstützung von 1- RTT -Handshakes und erste Unterstützung für 0- RTT
• Die Verpflichtung zur perfekten Vorwärtsgeheimhaltung durch die Verwendung ephemerer Schlüssel während des (EC)DH-Schlüsselabkommens
• Die Unterstützung für viele unsichere oder veraltete Funktionen wird eingestellt, darunter Komprimierung , Neuverhandlung, Nicht -AEAD- Verschlüsselungen, Null-Verschlüsselungen , ^{[ 52 ]} Nicht -PFS -Schlüsselaustausch (darunter statischer RSA- und statischer DH- Schlüsselaustausch), benutzerdefinierte DHE- Gruppen, EC-Punktformatverhandlung, Change Cipher Spec-Protokoll, UNIX-Zeit der Hello-Nachricht und das Längenfeld AD-Eingabe für AEAD-Verschlüsselungen.
• Verbot der SSL- oder RC4-Aushandlung aus Gründen der Abwärtskompatibilität
• Integration der Nutzung von Sitzungs-Hash
• Die Verwendung der Versionsnummer der Datensatzebene wird eingestellt und die Nummer aus Gründen der Abwärtskompatibilität eingefroren.
• Einige sicherheitsrelevante Algorithmusdetails aus einem Anhang in die Spezifikation verschieben und ClientKeyShare in einen Anhang auslagern
• Hinzufügen der ChaCha20- Stromchiffre mit dem Poly1305- Nachrichtenauthentifizierungscode
• Hinzufügen der digitalen Signaturalgorithmen Ed25519 und Ed448
• Hinzufügen der Schlüsselaustauschprotokolle x25519 und x448
• Unterstützung für das Senden mehrerer OCSP -Antworten hinzugefügt
• Verschlüsselung aller Handshake-Nachrichten nach dem ServerHello, einschließlich des Serverzertifikats

Network Security Services (NSS), die von Mozilla entwickelte und vom Webbrowser Firefox verwendete Kryptografiebibliothek , aktivierte TLS 1.3 im Februar 2017 standardmäßig. ^{[ 53 ]} Die Unterstützung für TLS 1.3 wurde anschließend hinzugefügt – jedoch aufgrund von Kompatibilitätsproblemen für eine kleine Anzahl von Nutzern nicht automatisch aktiviert ^{[ 54 ]} – und zwar in Firefox 52.0 , das im März 2017 veröffentlicht wurde. Mit der Veröffentlichung von Firefox 60.0 im Mai 2018 wurde TLS 1.3 standardmäßig aktiviert . ^{[ 55 ]}

Google Chrome hatte TLS 1.3 im Jahr 2017 für kurze Zeit als Standardversion festgelegt. Aufgrund inkompatibler Middleboxes wie beispielsweise Blue Coat Web-Proxys wurde diese Version dann wieder entfernt . ^{[ 56 ]}

Die Intoleranz der neuen TLS-Version äußerte sich in einer Protokollverfestigung ; Middleboxes hatten den Versionsparameter des Protokolls verfestigt. Infolgedessen ähnelt Version 1.3 dem Netzwerkabbild von Version 1.2. Diese Änderung erfolgte sehr spät im Entwicklungsprozess und wurde erst während der Browserbereitstellung entdeckt. ^{[ 57 ]} Die Entdeckung dieser Intoleranz führte auch dazu, dass die vorherige Strategie zur Versionsverhandlung, bei der die höchste passende Version ausgewählt wurde, aufgrund der unpraktikablen Verfestigung aufgegeben wurde. ^{[ 58 ]} Das sogenannte „ Greasing “ eines Erweiterungspunkts, bei dem ein Protokollteilnehmer Unterstützung für nicht existierende Erweiterungen beansprucht, um sicherzustellen, dass nicht erkannte, aber tatsächlich existierende Erweiterungen toleriert werden und so der Verfestigung entgegengewirkt wird, wurde ursprünglich für TLS entwickelt, findet aber mittlerweile auch in anderen Protokollen Anwendung. ^{[ 58 ]}

Während des IETF 100 Hackathons , der 2017 in Singapur stattfand , arbeitete die TLS-Gruppe an der Anpassung von Open-Source-Anwendungen an die Verwendung von TLS 1.3. ^{[ 59 ] [ 60 ]} Die TLS-Gruppe setzte sich aus Mitgliedern aus Japan, Großbritannien und Mauritius zusammen, die dem Team cyberstorm.mu angehörten. ^{[ 60 ] Diese Arbeit wurde beim IETF 101 Hackathon in London [ 61 ] und} beim IETF 102 ^{Hackathon in} Montreal ^{[ 62 ] fortgesetzt.}

wolfSSL ermöglichte die Nutzung von TLS 1.3 ab Version 3.11.1, veröffentlicht im Mai 2017. ^{[ 63 ]} Als erste kommerzielle TLS-1.3-Implementierung unterstützte wolfSSL 3.11.1 Draft 18 und nun auch Draft 28 ^{[ 64 ]} , die finale Version, sowie viele ältere Versionen. Es wurde eine Reihe von Blogbeiträgen zum Leistungsunterschied zwischen TLS 1.2 und 1.3 veröffentlicht. ^{[ 65 ]}

InSeptember 2018Das populäre OpenSSL- Projekt veröffentlichte Version 1.1.1 seiner Bibliothek, in der die Unterstützung für TLS 1.3 als „wichtigste Neuerung“ galt. ^{[ 66 ]}

Die Unterstützung für TLS 1.3 wurde für Secure Channel (schannel) in den GA- Versionen von Windows 11 und Windows Server 2022 hinzugefügt . ^{[ 67 ]}

Die Electronic Frontier Foundation (EFF) lobte TLS 1.3 und äußerte Bedenken hinsichtlich des Variantenprotokolls Enterprise Transport Security (ETS), das wichtige Sicherheitsmaßnahmen von TLS 1.3 absichtlich deaktiviert. ^{[ 68 ]} ETS, ursprünglich Enterprise TLS (eTLS) genannt, ist ein veröffentlichter Standard, bekannt als ETSI TS103523-3, „Middlebox Security Protocol, Part 3: Enterprise Transport Security“. Es ist ausschließlich für den Einsatz in proprietären Netzwerken wie Bankensystemen vorgesehen. ETS unterstützt keine Vorwärtsgeheimhaltung, um es Drittorganisationen, die mit den proprietären Netzwerken verbunden sind, zu ermöglichen, ihren privaten Schlüssel zur Überwachung des Netzwerkverkehrs auf Malware und zur Durchführung von Audits zu verwenden. ^{[ 69 ] [ 70 ]} Trotz der behaupteten Vorteile warnte die EFF, dass der Verlust der Vorwärtsgeheimhaltung die Offenlegung von Daten erleichtern könnte, und wies darauf hin, dass es bessere Methoden zur Analyse des Datenverkehrs gibt. ^{[ 68 ]}

Ein digitales Zertifikat bestätigt den Besitz eines öffentlichen Schlüssels durch den im Zertifikat genannten Inhaber und legt bestimmte zulässige Verwendungszwecke dieses Schlüssels fest. Dadurch können sich andere (vertrauenswürdige Parteien) auf Signaturen oder Aussagen des zugehörigen privaten Schlüssels verlassen. Schlüsselspeicher und Vertrauensspeicher können in verschiedenen Formaten vorliegen, z. B. .pem , .crt, .pfx und .jks .

TLS stützt sich typischerweise auf eine Reihe vertrauenswürdiger Zertifizierungsstellen, um die Authentizität von Zertifikaten zu gewährleisten. Das Vertrauen basiert üblicherweise auf einer Liste von Zertifikaten, die mit der Benutzeragenten -Software verteilt werden ^{[ 71 ]} und von der vertrauenden Partei geändert werden können.

Laut Netcraft , einem Unternehmen, das aktive TLS-Zertifikate überwacht, ist Symantec seit Beginn der Erhebung (bzw. VeriSign vor der Übernahme des Geschäftsbereichs Authentifizierungsdienste durch Symantec) die marktführende Zertifizierungsstelle (CA) . Im Jahr 2015 entfiel knapp ein Drittel aller Zertifikate und 44 % der gültigen Zertifikate der 1 Million meistbesuchten Websites (laut Netcraft) auf Symantec. ^{[ 72 ]} 2017 verkaufte Symantec sein TLS/SSL-Geschäft an DigiCert. ^{[ 73 ]} Einem aktualisierten Bericht zufolge sind IdenTrust , DigiCert und Sectigo seit Mai 2019 die drei größten Zertifizierungsstellen in Bezug auf Marktanteile. ^{[ 74 ]}

Die Verwendung von X.509 -Zertifikaten erfordert Zertifizierungsstellen und eine Public-Key-Infrastruktur, um die Beziehung zwischen Zertifikat und Inhaber zu überprüfen sowie Zertifikate zu generieren, zu signieren und deren Gültigkeit zu verwalten. Dies kann zwar bequemer sein als die Identitätsprüfung über ein Vertrauensnetzwerk , doch die Enthüllungen über Massenüberwachung im Jahr 2013 machten deutlich, dass Zertifizierungsstellen aus Sicherheitssicht eine Schwachstelle darstellen und Man-in-the-Middle-Angriffe (MITM) ermöglichen, wenn die Zertifizierungsstelle kooperiert (oder kompromittiert wird). ^{[ 75 ] [ 76 ]}

Am 11. April 2025 stimmte das CA/Browser Forum einer Abstimmung zu, die vorsieht, dass die Gültigkeitsdauer aller öffentlichen TLS-Zertifikate bis 2029 schrittweise auf 47 Tage reduziert wird. ^{[ 77 ]} Die Abstimmung wurde von Apple vorgeschlagen. ^{[ 78 ]}

Bevor Client und Server mit dem Austausch von TLS-geschützten Informationen beginnen können, müssen sie einen Verschlüsselungsschlüssel und ein Chiffrierverfahren sicher austauschen oder vereinbaren (siehe § Chiffrierverfahren ). Zu den Methoden für den Schlüsselaustausch bzw. die Schlüsselvereinbarung gehören: öffentliche und private Schlüssel, die mit RSA generiert werden (im TLS-Handshake-Protokoll als TLS_RSA bezeichnet), Diffie-Hellman (TLS_DH), ephemeres Diffie-Hellman (TLS_DHE), elliptisches Kurven-Diffie-Hellman (TLS_ECDH), ephemeres elliptisches Kurven-Diffie-Hellman (TLS_ECDHE), anonymes Diffie-Hellman (TLS_DH_anon), ^{[ 25 ]} Pre-Shared Key (TLS_PSK) ^{[ 79 ]} und Secure Remote Password (TLS_SRP). ^{[ 80 ]}

Die Schlüsselaustauschverfahren TLS_DH_anon und TLS_ECDH_anon authentifizieren weder Server noch Benutzer und werden daher selten verwendet, da sie anfällig für Man-in-the-Middle-Angriffe sind . Nur TLS_DHE und TLS_ECDHE bieten Vorwärtsgeheimhaltung .

Die während des Austauschs/der Vereinbarung verwendeten öffentlichen Schlüsselzertifikate unterscheiden sich auch in der Größe der verwendeten öffentlichen/privaten Verschlüsselungsschlüssel und damit in der Robustheit der gebotenen Sicherheit. Im Juli 2013 kündigte Google an, keine 1024-Bit-Schlüssel mehr zu verwenden, sondern stattdessen auf 2048-Bit-Schlüssel umzusteigen, um die Sicherheit der TLS-Verschlüsselung für seine Nutzer zu erhöhen, da die Verschlüsselungsstärke direkt mit der Schlüssellänge zusammenhängt . ^{[ 81 ] [ 82 ]}

Anmerkungen

Zur Sicherstellung der Datenintegrität wird ein Message Authentication Code (MAC) verwendet. HMAC kommt im CBC- Modus von Blockchiffren zum Einsatz. Authentifizierte Verschlüsselungsverfahren (AEAD) wie GCM und CCM nutzen einen AEAD-integrierten MAC und keinen HMAC . ^{[ 6 ] : §8.4} Für den TLS-Handshake wird ein HMAC-basierter PRF oder HKDF verwendet.

Bei der Anwendungsentwicklung wird TLS üblicherweise auf Transportprotokollen implementiert und verschlüsselt alle protokollbezogenen Daten von Protokollen wie HTTP , FTP , SMTP , NNTP und XMPP .

Historisch gesehen wurde TLS hauptsächlich mit zuverlässigen Transportprotokollen wie dem Transmission Control Protocol (TCP) verwendet. Es wurde jedoch auch mit datagrammorientierten Transportprotokollen wie dem User Datagram Protocol (UDP) und dem Datagram Congestion Control Protocol (DCCP) implementiert, deren Verwendung unabhängig davon unter dem Begriff Datagram Transport Layer Security ( DTLS ) standardisiert wurde .

Eine Hauptanwendung von TLS besteht darin, den mit dem HTTP-Protokoll kodierten Datenverkehr zwischen einer Website und einem Webbrowser im World Wide Web zu sichern . Diese Verwendung von TLS zur Sicherung des HTTP-Datenverkehrs stellt das HTTPS- Protokoll dar. ^{[ 102 ]}

Anmerkungen

Ab März 2025 unterstützen die neuesten Versionen aller gängigen Webbrowser TLS 1.2 und 1.3 und haben diese standardmäßig aktiviert, mit Ausnahme von IE 11. TLS 1.0 und 1.1 sind in den neuesten Versionen aller gängigen Browser standardmäßig deaktiviert.

Die Maßnahmen gegen bekannte Angriffe reichen noch nicht aus:

• Maßnahmen gegen POODLE-Angriffe : Einige Browser verhindern bereits den Fallback auf SSL 3.0; diese Schutzmaßnahme muss jedoch nicht nur von Clients, sondern auch von Servern unterstützt werden. Erforderlich sind die Deaktivierung von SSL 3.0 selbst, die Implementierung von „Anti-POODLE Record Splitting“ oder die Ablehnung von CBC-Verschlüsselungen in SSL 3.0.
  • Google Chrome: abgeschlossen (TLS_FALLBACK_SCSV ist seit Version 33 implementiert, der Fallback auf SSL 3.0 ist seit Version 39 deaktiviert, SSL 3.0 selbst ist seit Version 40 standardmäßig deaktiviert. Die Unterstützung für SSL 3.0 selbst wurde seit Version 44 eingestellt.)
  • Mozilla Firefox: vollständig (Die Unterstützung von SSL 3.0 selbst wurde seit Version 39 eingestellt . SSL 3.0 selbst ist standardmäßig deaktiviert, und der Fallback auf SSL 3.0 ist seit Version 34 deaktiviert ; TLS_FALLBACK_SCSV ist seit Version 35 implementiert. In ESR ist SSL 3.0 selbst standardmäßig deaktiviert, und TLS_FALLBACK_SCSV ist seit ESR 31.3.0 implementiert.)
  • Internet Explorer: teilweise (nur in Version 11, SSL 3.0 ist seit April 2015 standardmäßig deaktiviert. Version 10 und älter sind weiterhin anfällig für POODLE.)
  • Opera : vollständig (TLS_FALLBACK_SCSV ist seit Version 20 implementiert, "Anti-POODLE Record Splitting", das nur bei clientseitiger Implementierung wirksam ist, ist seit Version 25 implementiert, SSL 3.0 selbst ist seit Version 27 standardmäßig deaktiviert. Die Unterstützung für SSL 3.0 selbst wird ab Version 31 eingestellt.)
  • Safari: vollständig (nur unter OS X 10.8 und höher sowie iOS 8; CBC-Verschlüsselungen werden beim Fallback auf SSL 3.0 verweigert, was jedoch bedeutet, dass RC4 verwendet wird, was ebenfalls nicht empfohlen wird. Die Unterstützung für SSL 3.0 selbst wurde unter OS X 10.11 und höher sowie iOS 9 eingestellt.)
• Schutzmaßnahmen gegen RC4-Angriffe :
  • Google Chrome hat RC4 seit Version 43 deaktiviert, außer als Fallback. RC4 ist seit Chrome 48 deaktiviert.
  • Firefox hat RC4 seit Version 36 deaktiviert, außer als Fallback. Firefox 44 deaktiviert RC4 standardmäßig.
  • Opera hat RC4 seit Version 30 deaktiviert, außer als Fallback. RC4 ist seit Opera 35 deaktiviert.
  • Internet Explorer für Windows 7 /Server 2008 R2 und für Windows 8 /Server 2012 hat die Priorität von RC4 auf die niedrigste Stufe gesetzt und kann RC4 über die Registrierungseinstellungen deaktiviert werden, außer als Fallback. Internet Explorer 11 Mobile für Windows Phone 8.1 deaktiviert RC4, außer als Fallback, falls kein anderer aktivierter Algorithmus funktioniert. Edge (Legacy) und IE 11 deaktivieren RC4 seit August 2016 vollständig.
• Schutzmaßnahmen gegen FREAK-Angriffe :
  • Der in Android 4.0 und älteren Versionen enthaltene Android-Browser ist weiterhin anfällig für den FREAK-Angriff.
  • Internet Explorer 11 Mobile ist weiterhin anfällig für den FREAK-Angriff.
  • Google Chrome, Internet Explorer (Desktop), Safari (Desktop & Mobil) und Opera (Mobil) verfügen über FREAK-Schutzmechanismen.
  • Mozilla Firefox auf allen Plattformen und Google Chrome unter Windows waren von FREAK nicht betroffen.

Die meisten SSL- und TLS-Programmierbibliotheken sind freie und Open-Source-Software .

• Rustls ist eine in der Programmiersprache Rust geschriebene Implementierung von TLS 1.3, die Speichersicherheit gewährleistet.

• BoringSSL , ein Fork von OpenSSL für Chrome/Chromium und Android sowie andere Google-Anwendungen.
• Botan , eine unter der BSD-Lizenz stehende kryptografische Bibliothek, geschrieben in C++.
• BSAFE Micro Edition Suite: eine plattformübergreifende Implementierung von TLS, geschrieben in C unter Verwendung eines FIPS-validierten kryptografischen Moduls
• BSAFE SSL-J: eine TLS-Bibliothek, die sowohl eine proprietäre API als auch eine JSSE- API unter Verwendung eines FIPS-validierten kryptografischen Moduls bereitstellt.
• cryptlib : eine portable Open-Source-Kryptografiebibliothek (einschließlich TLS/SSL-Implementierung)
• Delphi- Programmierer können entweder die Bibliothek Indy verwenden, die OpenSSL nutzt , oder alternativ ICS, das jetzt TLS 1.3 unterstützt.
• GnuTLS : eine freie Implementierung ( LGPL-lizenziert )
• Java Secure Socket Extension (JSSE): die Java- API und Provider-Implementierung (mit dem Namen SunJSSE) ^{[ 106 ]}
• LibreSSL : ein Fork von OpenSSL aus dem OpenBSD-Projekt.
• MatrixSSL : eine dual lizenzierte Implementierung
• Mbed TLS (ehemals PolarSSL): Eine kleine SSL-Bibliotheksimplementierung für eingebettete Geräte, die auf einfache Handhabung ausgelegt ist
• Netzwerksicherheitsdienste : FIPS 140 -validierte Open-Source-Bibliothek
• OpenSSL : eine freie Implementierung (BSD-Lizenz mit einigen Erweiterungen)
• Schannel : eine Implementierung von SSL und TLS für Microsoft Windows als Teil des Softwarepakets.
• Sicherer Transport : eine Implementierung von SSL und TLS, die in OS X und iOS als Teil ihrer Pakete verwendet wird.
• wolfSSL (vormals CyaSSL): Eingebettete SSL/TLS-Bibliothek mit starkem Fokus auf Geschwindigkeit und Größe.

Eine auf der ACM- Konferenz 2012 über Computer- und Kommunikationssicherheit vorgestellte Arbeit ^{[ 107 ]} zeigte, dass viele Anwendungen einige dieser SSL-Bibliotheken falsch verwendeten, was zu Sicherheitslücken führte. Laut den Autoren:

„Die Hauptursache der meisten dieser Sicherheitslücken liegt im mangelhaften Design der APIs der zugrundeliegenden SSL-Bibliotheken. Anstatt die übergeordneten Sicherheitseigenschaften von Netzwerktunneln wie Vertraulichkeit und Authentifizierung abzubilden, legen diese APIs den Anwendungsentwicklern Details des SSL-Protokolls auf niedriger Ebene offen. Infolgedessen verwenden Entwickler SSL-APIs häufig falsch und interpretieren deren vielfältige Parameter, Optionen, Nebenwirkungen und Rückgabewerte falsch.“

Das Simple Mail Transfer Protocol (SMTP) kann ebenfalls durch TLS geschützt werden. Diese Anwendungen verwenden Zertifikate mit öffentlichen Schlüsseln, um die Identität der Endpunkte zu überprüfen.

TLS kann auch zum Tunneln eines kompletten Netzwerk-Stacks verwendet werden, um ein VPN zu erstellen , wie es beispielsweise bei OpenVPN und OpenConnect der Fall ist . Viele Anbieter haben mittlerweile die Verschlüsselungs- und Authentifizierungsfunktionen von TLS mit der Autorisierung kombiniert. Seit Ende der 1990er-Jahre wurden zudem erhebliche Fortschritte bei der Entwicklung von Client-Technologien außerhalb von Webbrowsern erzielt, um die Unterstützung von Client/Server-Anwendungen zu ermöglichen. Im Vergleich zu herkömmlichen IPsec- VPN-Technologien bietet TLS einige inhärente Vorteile bei der Firewall- und NAT- Traversal, die die Administration für große Gruppen von Remote-Zugriffsnutzern vereinfachen.

TLS ist auch eine Standardmethode zum Schutz der Anwendungssignalisierung gemäß dem Session Initiation Protocol (SIP). TLS kann zur Authentifizierung und Verschlüsselung der SIP-Signalisierung im Zusammenhang mit VoIP und anderen SIP-basierten Anwendungen verwendet werden. ^{[ 108 ]}

Nachfolgend sind einige bedeutende Angriffe auf TLS/SSL aufgeführt.

Im Februar 2015 veröffentlichte die IETF einen informativen RFC ^{[ 109 ]} , in dem die verschiedenen bekannten Angriffe gegen TLS/SSL zusammengefasst wurden.

Im August 2009 wurde eine Schwachstelle im Neuverhandlungsverfahren entdeckt, die zu Klartext-Injection-Angriffen gegen SSL 3.0 und alle aktuellen TLS-Versionen führen kann. ^{[ 110 ]} Beispielsweise ermöglicht sie einem Angreifer, der eine HTTPS- Verbindung kapert, eigene Anfragen in den Beginn der Kommunikation zwischen Client und Webserver einzuschleusen. Der Angreifer kann die Client-Server-Kommunikation nicht entschlüsseln, weshalb sich diese Schwachstelle von einem typischen Man-in-the-Middle-Angriff unterscheidet . Eine kurzfristige Lösung besteht darin, dass Webserver die Neuverhandlung unterbinden. Dies erfordert in der Regel keine weiteren Änderungen, es sei denn, es wird eine Clientzertifikatsauthentifizierung verwendet. Um die Schwachstelle zu beheben, wurde eine Erweiterung zur Anzeige der Neuverhandlung für TLS vorgeschlagen. ^{[ 111 ]} Diese Erweiterung verpflichtet Client und Server, Informationen über vorherige Handshakes in jeden Neuverhandlungs-Handshake einzubinden und zu überprüfen. ^{[ 112 ]} Diese Erweiterung wurde von mehreren Bibliotheken implementiert. ^{[ 113 ] [ 114 ] [ 115 ]}

Bei einem Protokoll -Downgrade-Angriff (auch Version-Rollback-Angriff genannt) wird ein Webserver dazu verleitet, Verbindungen mit früheren Versionen von TLS (wie SSLv2) auszuhandeln, die längst als unsicher aufgegeben wurden.

Frühere Modifikationen der Originalprotokolle, wie False Start ^{[ 116 ]} (übernommen und aktiviert von Google Chrome ^{[ 117 ]} ) oder Snap Start , führten Berichten zufolge zu begrenzten Downgrade-Angriffen auf das TLS-Protokoll ^{[ 118 ]} oder ermöglichten Änderungen an der vom Client an den Server gesendeten Liste der Verschlüsselungssuiten. Dadurch konnte ein Angreifer die Auswahl der Verschlüsselungssuite beeinflussen, um die ausgehandelte Suite so zu downgraden, dass entweder ein schwächerer symmetrischer Verschlüsselungsalgorithmus oder ein schwächerer Schlüsselaustausch verwendet wird. ^{[ 119 ]} Ein auf einer ACM- Konferenz für Computer- und Kommunikationssicherheit im Jahr 2012 vorgestellter Beitrag zeigte, dass die False-Start-Erweiterung ein Risiko darstellte: Unter bestimmten Umständen konnte ein Angreifer die Verschlüsselungsschlüssel offline wiederherstellen und auf die verschlüsselten Daten zugreifen. ^{[ 120 ]}

Angriffe, die die Verschlüsselung herabstufen, können Server und Clients zwingen, eine Verbindung mit kryptografisch schwachen Schlüsseln auszuhandeln. Im Jahr 2014 wurde ein Man-in-the-Middle -Angriff namens FREAK entdeckt, der den OpenSSL- Stack, den Standard -Webbrowser von Android und einige Safari -Browser betraf. ^{[ 121 ]} Bei diesem Angriff wurden Server dazu verleitet, eine TLS-Verbindung mit kryptografisch schwachen 512-Bit-Verschlüsselungsschlüsseln auszuhandeln.

Logjam ist eine im Mai 2015 entdeckte Sicherheitslücke , die die Verwendung veralteter, als „exporttauglich“ geltender 512-Bit- Diffie-Hellman- Gruppen aus den 1990er-Jahren ausnutzt. ^{[ 122 ]} Sie zwingt anfällige Server, auf kryptografisch schwache 512-Bit-Diffie-Hellman-Gruppen zurückzugreifen. Ein Angreifer kann dann die Schlüssel ermitteln, die Client und Server mithilfe des Diffie-Hellman-Schlüsselaustauschs bestimmen .

Der DROWN-Angriff ist eine Sicherheitslücke, die Server mit modernen SSL/TLS-Protokollen ausnutzt. Er greift deren Unterstützung für das veraltete und unsichere SSLv2-Protokoll an, um Verbindungen mit aktuellen, ansonsten sicheren Protokollen zu attackieren. ^{[ 123 ] [ 124 ]} DROWN nutzt eine Schwachstelle in den verwendeten Protokollen und der Serverkonfiguration aus, nicht etwa einen spezifischen Implementierungsfehler. Die vollständigen Details zu DROWN wurden im März 2016 zusammen mit einem Patch veröffentlicht. Damals waren über 81.000 der 1 Million meistbesuchten Websites TLS-geschützt und somit anfällig für den DROWN-Angriff. ^{[ 124 ]}

Am 23. September 2011 demonstrierten die Forscher Thai Duong und Juliano Rizzo einen Proof of Concept namens BEAST ( Browser Exploit Against SSL/TLS ) ^{[ 125 ]} mithilfe eines Java-Applets , um die Same-Origin-Policy- Beschränkungen für eine seit langem bekannte Cipher Block Chaining (CBC)-Schwachstelle in TLS 1.0 zu verletzen: ^{[ 126 ] [ 127 ]} Ein Angreifer, der 2 aufeinanderfolgende Chiffretextblöcke C0, C1 beobachtet, kann testen, ob der Klartextblock P1 gleich x ist, indem er den nächsten Klartextblock P2 = x ⊕ C0 ⊕ C1 wählt ; gemäß der CBC-Operation ist C2 = E(C1 ⊕ P2) = E(C1 ⊕ x ⊕ C0 ⊕ C1) = E(C0 ⊕ x) , was gleich C1 ist, wenn x = P1 . Für diese Schwachstelle , die ursprünglich 2002 von Phillip Rogaway ^{[ 128 ]} entdeckt wurde, waren zuvor keine praktischen Exploits demonstriert worden . Die Schwachstelle des Angriffs wurde 2006 mit TLS 1.1 behoben, aber TLS 1.1 hatte vor dieser Angriffsdemonstration keine breite Akzeptanz gefunden.

RC4 ist als Stromchiffre immun gegen BEAST-Angriffe. Daher wurde RC4 häufig zur Abwehr von BEAST-Angriffen auf Serverseite eingesetzt. Im Jahr 2013 entdeckten Forscher jedoch weitere Schwächen in RC4. Seitdem wird die Verwendung von RC4 auf Serverseite nicht mehr empfohlen. ^{[ 129 ]}

Chrome und Firefox selbst sind nicht anfällig für BEAST-Angriffe ^{[ 130 ] [ 131 ].} Mozilla hat jedoch seine NSS -Bibliotheken aktualisiert, um BEAST-ähnliche Angriffe abzuwehren . NSS wird von Mozilla Firefox und Google Chrome zur Implementierung von SSL verwendet. Einige Webserver mit einer fehlerhaften Implementierung der SSL-Spezifikation können dadurch möglicherweise nicht mehr funktionieren ^{[ 132 ] .}

Microsoft veröffentlichte am 10. Januar 2012 das Sicherheitsbulletin MS12-006, das die BEAST-Schwachstelle durch eine Änderung der Art und Weise behob, wie die Windows Secure Channel ( Schannel )-Komponente verschlüsselte Netzwerkpakete serverseitig überträgt. ^{[ 133 ]} Benutzer von Internet Explorer (vor Version 11), die ältere Windows-Versionen ( Windows 7 , Windows 8 und Windows Server 2008 R2 ) verwenden, können die Nutzung von TLS auf Version 1.1 oder höher beschränken.

Apple hat die BEAST-Schwachstelle durch die Implementierung einer 1/n-1-Aufteilung und deren standardmäßige Aktivierung in OS X Mavericks , das am 22. Oktober 2013 veröffentlicht wurde, entschärft. ^{[ 134 ]}

Die Autoren des BEAST-Angriffs sind auch die Entwickler des späteren CRIME- Angriffs, der es Angreifern ermöglicht, den Inhalt von Web-Cookies wiederherzustellen, wenn Datenkomprimierung zusammen mit TLS verwendet wird. ^{[ 135 ] [ 136 ]} Wird er zur Wiederherstellung des Inhalts geheimer Authentifizierungs-Cookies eingesetzt , ermöglicht er einem Angreifer die Übernahme einer authentifizierten Websitzung.

Obwohl der CRIME-Angriff als allgemeiner Angriff präsentiert wurde, der gegen eine Vielzahl von Protokollen, darunter TLS und Anwendungsschichtprotokolle wie SPDY oder HTTP , effektiv eingesetzt werden könnte, wurden lediglich Schwachstellen gegen TLS und SPDY demonstriert und in Browsern und Servern weitgehend behoben. Die CRIME-Schwachstelle gegen die HTTP-Komprimierung wurde bisher nicht behoben, obwohl die Entwickler von CRIME davor gewarnt haben, dass diese Schwachstelle möglicherweise noch weiter verbreitet ist als die kombinierte Schwachstelle von SPDY und TLS. Im Jahr 2013 wurde eine neue Variante des CRIME-Angriffs gegen die HTTP-Komprimierung, genannt BREACH , bekannt. Basierend auf dem CRIME-Angriff kann ein BREACH-Angriff Anmeldetoken, E-Mail-Adressen oder andere sensible Informationen aus TLS-verschlüsseltem Webverkehr in nur 30 Sekunden extrahieren (abhängig von der Anzahl der zu extrahierenden Bytes), vorausgesetzt, der Angreifer verleitet das Opfer dazu, einen schädlichen Weblink zu besuchen, oder kann Inhalte in legitime Seiten einschleusen, die der Benutzer besucht (z. B. in ein vom Angreifer kontrolliertes WLAN). ^{[ 137 ]} Alle Versionen von TLS und SSL sind unabhängig vom verwendeten Verschlüsselungsalgorithmus oder Chiffrierverfahren durch BREACH gefährdet. ^{[ 138 ]} Im Gegensatz zu früheren CRIME-Angriffen, die sich durch Deaktivierung der TLS- oder SPDY-Header-Komprimierung erfolgreich abwehren ließen, nutzt BREACH die HTTP-Komprimierung aus, die sich praktisch nicht deaktivieren lässt, da nahezu alle Webserver darauf angewiesen sind, um die Datenübertragungsgeschwindigkeit für die Nutzer zu verbessern. ^{[ 137 ]} Dies ist eine bekannte Schwäche von TLS, da es anfällig für Angriffe mit gewähltem Klartext auf die Anwendungsschichtdaten ist, die es eigentlich schützen soll.

Frühere TLS-Versionen waren anfällig für den im Jahr 2002 entdeckten Padding-Oracle-Angriff . Eine neue Variante, der sogenannte Lucky-Thirteen-Angriff , wurde im Jahr 2013 veröffentlicht.

Einige Experten ^{[ 98 ]} empfahlen außerdem, Triple-DES -CBC zu vermeiden. Da die letzten unterstützten Verschlüsselungsverfahren, die für Programme wie den Internet Explorer unter Windows XP mit der SSL/TLS-Bibliothek entwickelt wurden, RC4 und Triple-DES sind und RC4 mittlerweile als veraltet gilt (siehe Diskussion zu RC4-Angriffen ), ist es schwierig, SSL für Programme, die diese Bibliothek unter XP nutzen, in irgendeiner Form zu unterstützen.

Eine Lösung wurde 2014 als Erweiterung „Encrypt-then-MAC“ der TLS-Spezifikation veröffentlicht. ^{[ 139 ]} Der Lucky-Thirteen-Angriff lässt sich in TLS 1.2 durch die ausschließliche Verwendung von AES_GCM-Verschlüsselungen abschwächen; AES_CBC bleibt weiterhin anfällig. SSL kann neben seinem Hauptanwendungsfall der sicheren Datenübertragung zwischen Client und Server auch E-Mails, VoIP und andere Kommunikationsarten über unsichere Netzwerke schützen. ^{[ 2 ]}

Am 14. Oktober 2014 veröffentlichten Google-Forscher eine Schwachstelle im Design von SSL 3.0, die den CBC-Betriebsmodus mit SSL 3.0 anfällig für einen Padding-Angriff macht ( CVE - 2014-3566 ). Sie nannten diesen Angriff POODLE ( Padding Oracle On Downgraded Legacy Encryption ). Angreifer benötigen im Durchschnitt nur 256 SSL-3.0-Anfragen, um ein Byte verschlüsselter Nachrichten aufzudecken. ^{[ 105 ]}

Obwohl diese Schwachstelle nur in SSL 3.0 auftritt und die meisten Clients und Server TLS 1.0 und höher unterstützen, wechseln alle gängigen Browser freiwillig auf SSL 3.0 zurück, wenn der Handshake mit neueren TLS-Versionen fehlschlägt, es sei denn, sie bieten Benutzern oder Administratoren die Möglichkeit, SSL 3.0 zu deaktivieren, und diese Option wird genutzt. Daher kann ein Angreifer (Man-in-the-Middle) zunächst einen Versions-Rollback-Angriff durchführen und anschließend diese Schwachstelle ausnutzen. ^{[ 105 ]}

Am 8. Dezember 2014 wurde eine Variante von POODLE angekündigt, die Auswirkungen auf TLS-Implementierungen hat, welche die Anforderungen an Padding-Bytes nicht ordnungsgemäß durchsetzen. ^{[ 140 ]}

Trotz bekannter Angriffe auf RC4 , die dessen Sicherheit beeinträchtigten, galten auf RC4 basierende Verschlüsselungssammlungen in SSL und TLS bis 2013 aufgrund ihrer Verwendung in diesen Systemen als sicher. 2011 wurde die RC4-Suite sogar als Workaround für den BEAST -Angriff empfohlen. ^{[ 141 ]} Neue Angriffsformen, die im März 2013 aufgedeckt wurden, demonstrierten jedoch eindeutig die Möglichkeit, RC4 in TLS zu knacken, was nahelegte, dass es kein geeigneter Workaround für BEAST war. ^{[ 104 ]} AlFardan, Bernstein, Paterson, Poettering und Schuldt schlugen ein Angriffsszenario vor, das neu entdeckte statistische Verzerrungen in der RC4-Schlüsseltabelle nutzte ^{[ 142 ]} , um Teile des Klartextes mithilfe einer großen Anzahl von TLS-Verschlüsselungen wiederherzustellen. ^{[ 143 ] [ 144 ]} Ein Angriff auf RC4 in TLS und SSL, der 13 × ^2²⁰ Verschlüsselungen zur Entschlüsselung von RC4 erfordert, wurde am 8. Juli 2013 vorgestellt und später in der zugehörigen Präsentation auf einem USENIX Security Symposium im August 2013 als „machbar“ bezeichnet. ^{[ 145 ] [ 146 ]} Im Juli 2015 machten nachfolgende Verbesserungen des Angriffs es zunehmend einfacher, die Sicherheit von RC4-verschlüsseltem TLS zu überwinden. ^{[ 147 ]}

Da viele moderne Browser so konzipiert wurden, dass sie BEAST-Angriffe abwehren (mit Ausnahme von Safari für Mac OS X 10.7 oder älter, für iOS 6 oder älter und für Windows; siehe Abschnitt Webbrowser ), ist RC4 für TLS 1.0 nicht mehr geeignet. Die CBC-Verschlüsselungen, die in der Vergangenheit von BEAST-Angriffen betroffen waren, sind mittlerweile eine beliebtere Schutzoption. ^{[ 98 ]} Mozilla und Microsoft empfehlen, RC4 nach Möglichkeit zu deaktivieren. ^{[ 148 ] [ 149 ]} Im Februar 2015 wurde die Verwendung von RC4-Verschlüsselungssammlungen in allen TLS-Versionen offiziell verboten. ^{[ 101 ]}

Am 1. September 2015 kündigten Microsoft, Google und Mozilla an, dass RC4-Verschlüsselungssuiten in ihren Browsern ( Microsoft Edge [Legacy] , Internet Explorer 11 unter Windows 7/8.1/10, Firefox und Chrome ) ab Anfang 2016 standardmäßig deaktiviert sein würden. ^{[ 150 ] [ 151 ] [ 152 ]}

Ein TLS-Abmeldeangriff blockiert die Abmeldeanfragen eines Opfers, sodass der Benutzer unwissentlich bei einem Webdienst angemeldet bleibt. Beim Senden der Abmeldeanfrage fügt der Angreifer eine unverschlüsselte TCP- FIN-Nachricht (keine weiteren Daten vom Absender) ein, um die Verbindung zu schließen. Der Server empfängt daher die Abmeldeanfrage nicht und bemerkt die abnorme Beendigung nicht. ^{[ 153 ]}

Der im Juli 2013 veröffentlichte Angriff ^{[ 154 ] [ 155 ]} bewirkt, dass Webdienste wie Gmail und Hotmail eine Seite anzeigen, die den Benutzer über die erfolgreiche Abmeldung informiert. Gleichzeitig wird sichergestellt, dass der Browser des Benutzers weiterhin mit dem Dienst verbunden bleibt. Dadurch kann ein Angreifer, der anschließend Zugriff auf den Browser erhält, auf das angemeldete Benutzerkonto zugreifen und es übernehmen. Der Angriff erfordert keine Installation von Schadsoftware auf dem Computer des Opfers; Angreifer müssen sich lediglich zwischen Opfer und Webserver schalten (z. B. durch die Einrichtung eines manipulierten WLAN-Hotspots). ^{[ 153 ]} Diese Schwachstelle setzt außerdem Zugriff auf den Computer des Opfers voraus. Eine weitere Möglichkeit besteht darin, dass bei der Verwendung von FTP die Datenverbindung ein falsches FIN-Signal im Datenstrom enthalten kann. Werden die Protokollregeln für den Austausch von close_notify-Warnungen nicht eingehalten, kann eine Datei abgeschnitten werden.

Im Februar 2013 entdeckten zwei Forscher des Royal Holloway, University of London einen Timing-Angriff ^{[ 156 ]} , der es ihnen ermöglichte, (Teile des) Klartextes aus einer DTLS-Verbindung wiederherzustellen, indem sie die OpenSSL- oder GnuTLS-Implementierung von DTLS verwendeten, wenn die Cipher Block Chaining -Verschlüsselung zum Einsatz kam.

Dieser Mitte 2016 entdeckte Angriff nutzt Schwachstellen im Web Proxy Autodiscovery Protocol (WPAD) aus, um die URL offenzulegen, die ein Webnutzer über einen TLS-verschlüsselten Link aufrufen möchte. ^{[ 157 ]} Die Offenlegung einer URL kann die Privatsphäre eines Nutzers verletzen, nicht nur aufgrund der aufgerufenen Website, sondern auch, weil URLs häufig zur Authentifizierung von Nutzern verwendet werden. Dokumentenfreigabedienste wie Google und Dropbox funktionieren ebenfalls, indem sie dem Nutzer ein Sicherheitstoken senden, das in der URL enthalten ist. Ein Angreifer, der solche URLs erlangt, kann unter Umständen vollständigen Zugriff auf das Konto oder die Daten eines Opfers erlangen.

Die Sicherheitslücke funktioniert gegen nahezu alle Browser und Betriebssysteme.

Der Sweet32-Angriff knackt alle 64-Bit-Blockchiffren, die im CBC-Modus von TLS verwendet werden, indem er einen Birthday-Angriff und entweder einen Man-in-the-Middle-Angriff oder das Einschleusen von bösartigem JavaScript in eine Webseite ausnutzt. Ziel des Man-in-the-Middle-Angriffs oder des JavaScript-Einschleusens ist es, dem Angreifer genügend Datenverkehr abzufangen, um einen Birthday-Angriff durchzuführen. ^{[ 158 ]}

Der Heartbleed- Bug ist eine schwerwiegende Sicherheitslücke in der Implementierung von SSL/TLS der weit verbreiteten OpenSSL -Verschlüsselungsbibliothek und betrifft die Versionen 1.0.1 bis 1.0.1f. Diese im April 2014 gemeldete Schwachstelle ermöglicht es Angreifern, private Schlüssel von Servern zu extrahieren, die eigentlich geschützt sein sollten. ^{[ 159 ]} Der Heartbleed-Bug erlaubt es jedem im Internet, den Speicher von Systemen auszulesen, die durch die anfälligen OpenSSL-Versionen geschützt sind. Dadurch werden die geheimen privaten Schlüssel der öffentlichen Zertifikate, die zur Identifizierung der Dienstanbieter und zur Verschlüsselung des Datenverkehrs verwendet werden, sowie die Benutzernamen, Passwörter und Inhalte der Nutzer kompromittiert. Angreifer können so die Kommunikation abhören, Daten direkt von Diensten und Nutzern extrahieren und sich als Dienste und Nutzer ausgeben. ^{[ 160 ]} Die Sicherheitslücke wird durch einen Pufferüberlauf in der OpenSSL-Software verursacht und nicht durch einen Fehler in der SSL- oder TLS-Protokollspezifikation.

Im September 2014 veröffentlichte Intel Security Advanced Threat Research eine Variante der von Daniel Bleichenbacher entdeckten PKCS#1 v1.5 RSA-Signaturfälschungs-Schwachstelle ^{[ 161 ]} . Dieser Angriff, genannt BERserk, beruht auf einer unvollständigen ASN.1-Längendekodierung von Public-Key-Signaturen in einigen SSL-Implementierungen und ermöglicht einen Man-in-the-Middle-Angriff durch Fälschung einer Public-Key-Signatur. ^{[ 162 ]}

Nachdem Medien im Februar 2015 über die versteckte Vorinstallation der Superfish- Adware auf einigen Lenovo-Notebooks berichtet hatten ^{[ 163 ]} , entdeckte ein Forscher, dass ein vertrauenswürdiges Root-Zertifikat auf betroffenen Lenovo-Geräten unsicher war. Die Schlüssel konnten leicht mit dem Firmennamen Komodia als Passphrase ausgelesen werden. ^{[ 164 ]} Die Komodia-Bibliothek war ursprünglich für die Überwachung und das Abfangen clientseitiger TLS/SSL-Datenverkehr zur Kindersicherung entwickelt worden. Sie wurde jedoch auch in zahlreichen Adware-Programmen, darunter Superfish, verwendet, die oft unbemerkt und ohne Wissen des Nutzers installiert wurden. Diese potenziell unerwünschten Programme installierten wiederum das beschädigte Root-Zertifikat, wodurch Angreifer die vollständige Kontrolle über den Webverkehr erlangten und gefälschte Websites als authentisch einstufen konnten.

Im Mai 2016 wurde berichtet, dass Dutzende dänische HTTPS-geschützte Websites von Visa Inc. anfällig für Angriffe waren, die es Hackern ermöglichten, Schadcode und gefälschte Inhalte in die Browser der Besucher einzuschleusen. ^{[ 165 ]} Die Angriffe funktionierten, weil die auf den betroffenen Servern verwendete TLS-Implementierung Zufallszahlen ( Nonces ) fälschlicherweise wiederverwendete, die eigentlich nur einmal verwendet werden sollen und somit die Eindeutigkeit jedes TLS-Handshakes gewährleisten . ^{[ 165 ]}

Im Februar 2017 verursachte ein Implementierungsfehler, ausgelöst durch ein einzelnes falsch getipptes Zeichen im Code zum Parsen von HTML, einen Pufferüberlauf auf Cloudflare -Servern. Ähnlich wie der 2014 entdeckte Heartbleed-Bug ermöglichte dieser Überlauffehler, allgemein bekannt als Cloudbleed , unbefugten Dritten, Daten im Speicher von auf den Servern laufenden Programmen auszulesen – Daten, die eigentlich durch TLS geschützt sein sollten. ^{[ 166 ]}

Die Trustworthy Internet Movement schätzte für Juni 2025 den Anteil der Websites, die anfällig für TLS-Angriffe sind. ^{[ 103 ]}

Forward Secrecy ist eine Eigenschaft kryptografischer Systeme, die sicherstellt, dass ein aus einem Satz öffentlicher und privater Schlüssel abgeleiteter Sitzungsschlüssel nicht kompromittiert wird, falls einer der privaten Schlüssel in Zukunft kompromittiert wird. ^{[ 167 ]} Ohne Forward Secrecy wären bei Kompromittierung des privaten Schlüssels des Servers nicht nur alle zukünftigen TLS-verschlüsselten Sitzungen, die dieses Serverzertifikat verwenden, gefährdet, sondern auch alle früheren Sitzungen, die es verwendet haben (vorausgesetzt, diese früheren Sitzungen wurden zum Zeitpunkt der Übertragung abgefangen und gespeichert). ^{[ 168 ]} Eine TLS-Implementierung kann Forward Secrecy gewährleisten, indem sie die Verwendung des ephemeren Diffie-Hellman-Schlüsselaustauschs zur Einrichtung von Sitzungsschlüsseln vorschreibt. Einige namhafte TLS-Implementierungen tun dies ausschließlich, z. B. Gmail und andere Google-HTTPS-Dienste, die OpenSSL verwenden . ^{[ 169 ]} Viele Clients und Server, die TLS unterstützen (einschließlich Browser und Webserver), sind jedoch nicht für die Implementierung solcher Einschränkungen konfiguriert. ^{[ 170 ] [ 171 ]} In der Praxis kann der gesamte verschlüsselte Webverkehr eines Webdienstes, der zu und von diesem Dienst führt, von einem Dritten entschlüsselt werden, sofern dieser den Master-Schlüssel (privaten Schlüssel) des Servers erlangt, beispielsweise durch eine gerichtliche Anordnung, es sei denn, der Webdienst verwendet den Diffie-Hellman-Schlüsselaustausch zur Implementierung von Forward Secrecy. ^{[ 172 ]}

Selbst bei Verwendung des Diffie-Hellman-Schlüsselaustauschs können serverseitige Sitzungsverwaltungsmechanismen die Vorwärtsgeheimhaltung beeinträchtigen. Die Verwendung von TLS-Sitzungstickets (einer TLS-Erweiterung) führt dazu, dass die Sitzung unabhängig von anderen ausgehandelten TLS-Parametern, einschließlich der Verschlüsselungssuiten für die Vorwärtsgeheimhaltung, durch AES128-CBC-SHA256 geschützt wird. Die langlebigen TLS-Sitzungsticketschlüssel untergraben den Versuch, Vorwärtsgeheimhaltung zu implementieren. ^{[ 173 ] [ 174 ] [ 175 ]} Eine Studie der Stanford University aus dem Jahr 2014 ergab zudem, dass von 473.802 untersuchten TLS-Servern 82,9 % der Server, die den ephemeren Diffie-Hellman-Schlüsselaustausch (DHE) zur Unterstützung der Vorwärtsgeheimhaltung einsetzten, schwache Diffie-Hellman-Parameter verwendeten. Diese schwachen Parameterwahlmöglichkeiten können die Wirksamkeit der von den Servern angestrebten Vorwärtsgeheimhaltung potenziell gefährden. ^{[ 176 ]}

Seit Ende 2011 bietet Google Nutzern seines Gmail- Dienstes sowie von Google Docs und der verschlüsselten Suche sowie weiterer Dienste standardmäßig Forward Secrecy mit TLS an . ^{[ 177 ]} Seit November 2013 bietet Twitter seinen Nutzern Forward Secrecy mit TLS an. ^{[ 178 ]} Stand August 2019 sind etwa 80 % der TLS-fähigen Websites so konfiguriert, dass sie Verschlüsselungssammlungen verwenden, die Forward Secrecy für die meisten Webbrowser gewährleisten. ^{[ 103 ]}

TLS-Interception (bzw. HTTPS -Interception, wenn sie speziell auf dieses Protokoll angewendet wird) bezeichnet das Abfangen eines verschlüsselten Datenstroms, um ihn zu entschlüsseln, zu lesen und gegebenenfalls zu manipulieren, ihn anschließend wieder zu verschlüsseln und erneut zu senden. Dies geschieht mittels eines „ transparenten Proxys “: Die Interceptionssoftware beendet die eingehende TLS-Verbindung, untersucht den HTTP-Klartext und stellt dann eine neue TLS-Verbindung zum Ziel her. ^{[ 179 ]}

Die Überwachung von TLS/HTTPS-Verbindungen dient Netzwerkbetreibern als Maßnahme zur Informationssicherheit, um das Netzwerk vor schädlichen Inhalten wie Computerviren und anderer Malware zu schützen . ^{[ 179 ]} Solche Inhalte könnten andernfalls nicht erkannt werden, solange sie verschlüsselt sind, was durch die routinemäßige Nutzung von HTTPS und anderen sicheren Protokollen zunehmend der Fall ist.

Ein wesentlicher Nachteil der TLS/HTTPS-Abfangtechnologie besteht darin, dass sie neue Sicherheitsrisiken mit sich bringt. Eine wichtige Einschränkung ist, dass sie einen Punkt bietet, an dem Netzwerkverkehr unverschlüsselt zugänglich ist. Dies gibt Angreifern einen Anreiz, insbesondere diesen Punkt anzugreifen, um Zugriff auf ansonsten geschützte Inhalte zu erlangen. Die Abfangtechnologie ermöglicht es dem Netzwerkbetreiber oder Personen, die Zugriff auf sein Abfangsystem erlangen, Man-in-the-Middle-Angriffe gegen Netzwerkbenutzer durchzuführen. Eine Studie aus dem Jahr 2017 kam zu dem Schluss, dass „die HTTPS-Abfangtechnologie erschreckend weit verbreitet ist und dass Abfangprodukte als solche einen dramatisch negativen Einfluss auf die Verbindungssicherheit haben.“ ^{[ 179 ]}

Das TLS-Protokoll tauscht Datensätze aus , die die auszutauschenden Daten in einem spezifischen Format kapseln (siehe unten). Jeder Datensatz kann komprimiert, aufgefüllt, mit einem Message Authentication Code (MAC) versehen oder verschlüsselt werden, abhängig vom Verbindungsstatus. Jeder Datensatz enthält ein Feld für den Inhaltstyp , das den Typ der gekapselten Daten angibt, ein Längenfeld und ein Feld für die TLS-Version. Die gekapselten Daten können Steuerungs- oder Verfahrensnachrichten des TLS selbst oder einfach die Anwendungsdaten sein, die per TLS übertragen werden müssen. Die Spezifikationen (Verschlüsselungssuite, Schlüssel usw.), die für den Austausch von Anwendungsdaten per TLS erforderlich sind, werden im „TLS-Handshake“ zwischen dem anfragenden Client und dem antwortenden Server vereinbart. Das Protokoll definiert somit sowohl die Struktur der in TLS übertragenen Nutzdaten als auch das Verfahren zum Aufbau und zur Überwachung der Übertragung.

Beim Verbindungsaufbau enthält der Datensatz ein „Kontrollprotokoll“ – das Handshake-Messaging-Protokoll ( Inhaltstyp 22). Dieses Protokoll dient dem Austausch aller Informationen, die beide Seiten für die Übertragung der eigentlichen Anwendungsdaten per TLS benötigen. Es definiert das Nachrichtenformat und die Reihenfolge des Nachrichtenaustauschs. Diese können je nach den Anforderungen von Client und Server variieren – es gibt also mehrere mögliche Vorgehensweisen zum Verbindungsaufbau. Dieser erste Austausch führt entweder zu einer erfolgreichen TLS-Verbindung (beide Parteien sind bereit, Anwendungsdaten per TLS zu übertragen) oder zu einer Warnmeldung (wie unten beschrieben).

Im Folgenden wird ein typisches Verbindungsbeispiel dargestellt, das einen Handshake veranschaulicht , bei dem der Server (aber nicht der Client) durch sein Zertifikat authentifiziert wird:

1. Verhandlungsphase:
   • Ein Client sendet eine ClientHello -Nachricht, die die höchste unterstützte TLS-Protokollversion, eine Zufallszahl, eine Liste empfohlener Verschlüsselungssammlungen und empfohlener Komprimierungsmethoden angibt. Versucht der Client, einen fortgesetzten Handshake durchzuführen, kann er eine Sitzungs-ID senden . Unterstützt der Client die Protokollaushandlung auf Anwendungsebene (Application-Layer Protocol Negotiation , ALS), kann er eine Liste unterstützter Anwendungsprotokolle wie HTTP /2 angeben .
   • Der Server antwortet mit einer ServerHello -Nachricht, die die gewählte Protokollversion, eine Zufallszahl, die Verschlüsselungssuite und das Komprimierungsverfahren aus den vom Client angebotenen Optionen enthält. Zur Bestätigung oder zur Wiederaufnahme des Handshakes kann der Server eine Sitzungs-ID senden . Die gewählte Protokollversion sollte die höchste sein, die sowohl vom Client als auch vom Server unterstützt wird. Wenn der Client beispielsweise TLS Version 1.1 und der Server Version 1.2 unterstützt, sollte Version 1.1 gewählt werden; Version 1.2 sollte nicht gewählt werden.
   • Der Server sendet seine Zertifikatsnachricht (abhängig von der gewählten Verschlüsselungssuite kann diese vom Server weggelassen werden). ^{[ 180 ]}
   • Der Server sendet seine ServerKeyExchange- Nachricht (abhängig von der gewählten Verschlüsselungssuite kann diese vom Server weggelassen werden). Diese Nachricht wird für alle DHE- , ECDHE- und DH_anon-Verschlüsselungssuiten gesendet. ^{[ 25 ]}
   • Der Server sendet eine ServerHelloDone -Nachricht, die anzeigt, dass die Handshake-Aushandlung abgeschlossen ist.
   • Der Client antwortet mit einer ClientKeyExchange- Nachricht, die ein PreMasterSecret , einen öffentlichen Schlüssel oder nichts enthalten kann. (Dies hängt vom gewählten Verschlüsselungsverfahren ab.) Das PreMasterSecret wird mit dem öffentlichen Schlüssel des Serverzertifikats verschlüsselt.
   • Client und Server verwenden anschließend die Zufallszahlen und das PreMasterSecret , um ein gemeinsames Geheimnis, das sogenannte „Master-Secret“, zu berechnen. Alle anderen Schlüsseldaten ( Sitzungsschlüssel wie IV , symmetrischer Verschlüsselungsschlüssel , MAC- Schlüssel ^{[ 181 ]} ) für diese Verbindung werden aus diesem Master-Secret (und den vom Client und Server generierten Zufallswerten) abgeleitet, das durch eine sorgfältig entworfene Pseudozufallsfunktion geleitet wird .
2. Der Client sendet nun einen ChangeCipherSpec- Eintrag und teilt dem Server damit im Wesentlichen mit: „Alles, was ich Ihnen ab jetzt sende, wird authentifiziert (und verschlüsselt, falls im Serverzertifikat Verschlüsselungsparameter vorhanden waren).“ Der ChangeCipherSpec-Eintrag selbst ist ein Protokoll auf Datensatzebene mit dem Inhaltstyp 20.
   • Der Client sendet eine authentifizierte und verschlüsselte Finished -Nachricht, die einen Hash und einen MAC der vorherigen Handshake-Nachrichten enthält.
   • Der Server versucht, die vom Client gesendete „Fertig “-Nachricht zu entschlüsseln und Hash und MAC zu überprüfen. Schlägt die Entschlüsselung oder Überprüfung fehl, gilt der Handshake als fehlgeschlagen und die Verbindung wird getrennt.
3. Schließlich sendet der Server eine ChangeCipherSpec-Nachricht an den Client mit der Mitteilung: „Alles, was ich Ihnen von nun an mitteile, wird authentifiziert (und verschlüsselt, falls eine Verschlüsselung ausgehandelt wurde).“
   • Der Server sendet seine authentifizierte und verschlüsselte Abschlussmeldung .
   • Der Client führt das gleiche Entschlüsselungs- und Verifizierungsverfahren durch, das der Server im vorherigen Schritt durchgeführt hat.
4. Anwendungsphase: An diesem Punkt ist der „Handshake“ abgeschlossen und das Anwendungsprotokoll mit dem Inhaltstyp 23 aktiviert. Die zwischen Client und Server ausgetauschten Anwendungsnachrichten werden ebenfalls authentifiziert und optional, genau wie in der Abschlussnachricht, verschlüsselt . Andernfalls wird der Inhaltstyp 25 zurückgegeben und der Client authentifiziert sich nicht.

Das folgende vollständige Beispiel zeigt, wie ein Client (zusätzlich zum Server wie im obigen Beispiel; siehe gegenseitige Authentifizierung ) über TLS mithilfe von zwischen beiden Peers ausgetauschten Zertifikaten authentifiziert wird.

1. Verhandlungsphase:
   • Ein Client sendet eine ClientHello -Nachricht, in der die höchste unterstützte TLS-Protokollversion, eine Zufallszahl, eine Liste empfohlener Cipher Suites und Komprimierungsmethoden angegeben werden.
   • Der Server antwortet mit einer ServerHello -Nachricht, die die gewählte Protokollversion, eine Zufallszahl, die Verschlüsselungssuite und das Komprimierungsverfahren aus den vom Client angebotenen Optionen enthält. Der Server kann außerdem eine Sitzungs-ID als Teil der Nachricht senden, um den Handshake fortzusetzen.
   • Der Server sendet seine Zertifikatsnachricht (abhängig von der gewählten Verschlüsselungssuite kann diese vom Server weggelassen werden). ^{[ 180 ]}
   • Der Server sendet seine ServerKeyExchange- Nachricht (abhängig von der gewählten Verschlüsselungssuite kann diese vom Server weggelassen werden). Diese Nachricht wird für alle DHE-, ECDHE- und DH_anon-Verschlüsselungssuiten gesendet. ^[1]
   • Der Server sendet eine CertificateRequest- Nachricht, um ein Zertifikat vom Client anzufordern.
   • Der Server sendet eine ServerHelloDone -Nachricht, die anzeigt, dass die Handshake-Aushandlung abgeschlossen ist.
   • Der Client antwortet mit einer Zertifikatsnachricht , die das Zertifikat des Clients, aber nicht seinen privaten Schlüssel enthält.
   • Der Client sendet eine ClientKeyExchange- Nachricht, die ein PreMasterSecret , einen öffentlichen Schlüssel oder nichts enthalten kann. (Dies hängt vom gewählten Verschlüsselungsverfahren ab.) Das PreMasterSecret wird mit dem öffentlichen Schlüssel des Serverzertifikats verschlüsselt.
   • Der Client sendet eine CertificateVerify- Nachricht, die eine Signatur der vorherigen Handshake-Nachrichten mithilfe des privaten Schlüssels des Client-Zertifikats darstellt. Diese Signatur kann mit dem öffentlichen Schlüssel des Client-Zertifikats verifiziert werden. Dadurch weiß der Server, dass der Client Zugriff auf den privaten Schlüssel des Zertifikats hat und somit dessen Eigentümer ist.
   • Client und Server verwenden dann die Zufallszahlen und das PreMasterSecret , um ein gemeinsames Geheimnis, das sogenannte „Master-Geheimnis“, zu berechnen. Alle anderen Schlüsseldaten („Sitzungsschlüssel“) für diese Verbindung werden aus diesem Master-Geheimnis (und den vom Client und Server generierten Zufallswerten) abgeleitet, das durch eine sorgfältig entworfene Pseudozufallsfunktion geleitet wird.
2. Der Client sendet nun einen ChangeCipherSpec- Eintrag und teilt dem Server damit im Wesentlichen mit: „Alles, was ich Ihnen ab jetzt sende, wird authentifiziert (und verschlüsselt, falls eine Verschlüsselung vereinbart wurde).“ Der ChangeCipherSpec-Eintrag selbst ist ein Protokoll auf Datensatzebene und hat den Typ 20, nicht 22.
   • Zum Schluss sendet der Client eine verschlüsselte Finished- Nachricht, die einen Hash und einen MAC der vorherigen Handshake-Nachrichten enthält.
   • Der Server versucht, die vom Client gesendete „Fertig “-Nachricht zu entschlüsseln und Hash und MAC zu überprüfen. Schlägt die Entschlüsselung oder Überprüfung fehl, gilt der Handshake als fehlgeschlagen und die Verbindung wird getrennt.
3. Schließlich sendet der Server eine ChangeCipherSpec-Nachricht an den Client mit der Mitteilung: „Alles, was ich Ihnen ab jetzt mitteile, wird authentifiziert (und verschlüsselt, falls eine Verschlüsselung ausgehandelt wurde).“
   • Der Server sendet seine eigene verschlüsselte Abschlussmeldung .
   • Der Client führt das gleiche Entschlüsselungs- und Verifizierungsverfahren durch, das der Server im vorherigen Schritt durchgeführt hat.
4. Anwendungsphase: An diesem Punkt ist der „Handshake“ abgeschlossen und das Anwendungsprotokoll mit dem Inhaltstyp 23 aktiviert. Die zwischen Client und Server ausgetauschten Anwendungsnachrichten werden ebenfalls genau wie in ihrer Finished -Nachricht verschlüsselt.

Operationen mit öffentlichen Schlüsseln (z. B. RSA) sind rechenintensiv. TLS bietet im Handshake-Mechanismus eine sichere Abkürzung, um diese Operationen zu vermeiden: die Wiederaufnahme von Sitzungen. Wiederaufnahme von Sitzungen wird mithilfe von Sitzungs-IDs oder Sitzungstickets realisiert.

Neben dem Leistungsvorteil können wiederaufgenommene Sitzungen auch für Single Sign-On genutzt werden , da dadurch sichergestellt wird, dass sowohl die ursprüngliche Sitzung als auch jede wiederaufgenommene Sitzung vom selben Client stammen. Dies ist insbesondere für das FTP-over-TLS/SSL- Protokoll von Bedeutung, das andernfalls anfällig für Man-in-the-Middle-Angriffe wäre, bei denen ein Angreifer die Inhalte der sekundären Datenverbindungen abfangen könnte. ^{[ 182 ]}

Der TLS 1.3-Handshake wurde auf nur noch einen Roundtrip verkürzt, im Vergleich zu den zwei Roundtrips, die in früheren Versionen von TLS/SSL erforderlich waren.

Um den Handshake zu starten, versucht der Client, den vom Server gewählten Schlüsselaustauschalgorithmus zu erraten, und sendet eine ClientHello -Nachricht an den Server. Diese enthält eine Liste der unterstützten Verschlüsselungsverfahren (in der Reihenfolge der Clientpräferenz) sowie die öffentlichen Schlüssel für einige oder alle seiner Vermutungen. Gelingt es dem Client, den Schlüsselaustauschalgorithmus zu erraten, entfällt ein Roundtrip im Handshake. Nach Empfang der ClientHello-Nachricht wählt der Server ein Verschlüsselungsverfahren aus und sendet eine ServerHello-Nachricht mit seinem öffentlichen Schlüssel zurück, gefolgt von den Nachrichten „Server Certificate“ und „Finished “. ^{[ 183 ]}

Nachdem der Client die Abschlussmeldung des Servers erhalten hat, stimmt er sich mit dem Server darüber ab, welche Verschlüsselungssuite verwendet werden soll. ^{[ 184 ]}

Bei einem herkömmlichen vollständigen Handshake sendet der Server eine Sitzungs-ID als Teil der ServerHello -Nachricht. Der Client verknüpft diese Sitzungs-ID mit der IP-Adresse und dem TCP-Port des Servers, sodass er beim erneuten Verbinden mit diesem Server die Sitzungs-ID nutzen kann , um den Handshake abzukürzen. Auf dem Server ist die Sitzungs-ID den zuvor ausgehandelten kryptografischen Parametern, insbesondere dem „Master-Secret“, zugeordnet. Beide Seiten müssen dasselbe „Master-Secret“ verwenden, andernfalls schlägt der fortgesetzte Handshake fehl (dies verhindert, dass ein Angreifer die Sitzungs-ID abfängt ). Die Zufallsdaten in den ClientHello- und ServerHello- Nachrichten gewährleisten praktisch, dass sich die generierten Verbindungsschlüssel von denen der vorherigen Verbindung unterscheiden. In den RFCs wird diese Art von Handshake als verkürzter Handshake bezeichnet. In der Literatur wird er auch als Neustart -Handshake beschrieben.

1. Verhandlungsphase:
   • Ein Client sendet eine ClientHello- Nachricht, die die höchste unterstützte TLS-Protokollversion, eine Zufallszahl, eine Liste empfohlener Verschlüsselungssammlungen und Komprimierungsmethoden sowie die Sitzungs-ID der vorherigen TLS-Verbindung enthält.
   • Der Server antwortet mit einer ServerHello -Nachricht, die die gewählte Protokollversion, eine Zufallszahl, die Verschlüsselungssuite und die Komprimierungsmethode aus den vom Client angegebenen Optionen enthält. Erkennt der Server die vom Client gesendete Sitzungs-ID , antwortet er mit derselben Sitzungs-ID . Der Client erkennt daran, dass ein fortgesetzter Handshake durchgeführt wird. Erkennt der Server die vom Client gesendete Sitzungs-ID nicht, sendet er einen anderen Wert für seine Sitzungs-ID . Dies signalisiert dem Client, dass kein fortgesetzter Handshake durchgeführt wird. Nun verfügen sowohl Client als auch Server über das „Master-Secret“ und die Zufallsdaten, um die für diese Verbindung zu verwendenden Schlüsseldaten zu generieren.
2. Der Server sendet nun einen ChangeCipherSpec- Eintrag und teilt dem Client damit im Wesentlichen mit: „Alles, was ich Ihnen ab jetzt mitteile, wird verschlüsselt.“ Der ChangeCipherSpec selbst ist ein Protokoll auf Datensatzebene und hat den Typ 20 und nicht 22.
   • Zum Schluss sendet der Server eine verschlüsselte Finished -Nachricht, die einen Hash und einen MAC der vorherigen Handshake-Nachrichten enthält.
   • Der Client versucht, die vom Server gesendete „Fertig “-Nachricht zu entschlüsseln und Hash und MAC zu überprüfen. Schlägt die Entschlüsselung oder Überprüfung fehl, gilt der Handshake als fehlgeschlagen und die Verbindung wird getrennt.
3. Zum Schluss sendet der Client ein ChangeCipherSpec-Paket und teilt dem Server damit mit: „Alles, was ich Ihnen von nun an mitteile, wird verschlüsselt.“
   • Der Client sendet seine eigene verschlüsselte Finished -Nachricht.
   • Der Server führt das gleiche Entschlüsselungs- und Verifizierungsverfahren durch, das der Client im vorherigen Schritt durchgeführt hat.
4. Anwendungsphase: An diesem Punkt ist der „Handshake“ abgeschlossen und das Anwendungsprotokoll mit dem Inhaltstyp 23 aktiviert. Die zwischen Client und Server ausgetauschten Anwendungsnachrichten werden ebenfalls genau wie in ihrer Finished -Nachricht verschlüsselt.

Anstelle von Sitzungs-IDs kann TLS auch durch die Verwendung von Sitzungstickets erweitert werden. ^{[ 185 ]} Dies definiert eine Möglichkeit, eine TLS-Sitzung fortzusetzen, ohne dass der sitzungsspezifische Zustand auf dem TLS-Server gespeichert werden muss.

Bei Verwendung von Session-Tickets speichert der TLS-Server seinen sitzungsspezifischen Status in einem Session-Ticket und sendet dieses zur Speicherung an den TLS-Client. Der Client setzt eine TLS-Sitzung fort, indem er das Session-Ticket an den Server sendet. Der Server setzt die Sitzung daraufhin anhand des im Ticket enthaltenen sitzungsspezifischen Status fort. Das Session-Ticket wird vom Server verschlüsselt und authentifiziert. Der Server überprüft seine Gültigkeit, bevor er dessen Inhalt verwendet.

Eine besondere Schwäche dieser Methode mit OpenSSL besteht darin, dass die Sicherheit der Verschlüsselung und Authentifizierung des übertragenen TLS-Session-Tickets stets auf einen bestimmten Wert beschränkt ist AES128-CBC-SHA256, unabhängig von den anderen für die eigentliche TLS-Sitzung ausgehandelten TLS-Parametern. ^{[ 174 ]} Dies bedeutet, dass die Zustandsinformationen (das TLS-Session-Ticket) nicht so gut geschützt sind wie die TLS-Sitzung selbst. Besonders problematisch ist die Speicherung der Schlüssel durch OpenSSL in einem anwendungsweiten Kontext ( SSL_CTX), d. h. für die gesamte Laufzeit der Anwendung, und die Tatsache, dass die AES128-CBC-SHA256TLS-Session-Tickets nicht neu generiert werden können, ohne den anwendungsweiten OpenSSL-Kontext zurückzusetzen (was unüblich, fehleranfällig ist und oft einen manuellen Eingriff der Administration erfordert). ^{[ 175 ] [ 173 ]}

Dies ist das allgemeine Format aller TLS-Einträge.

Allgemeines TLS-Datensatzformat

Offset	Oktett	0								1								2								3
Oktett	Bisschen	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Inhaltstyp								Ältere Version (Haupt-/Nebenversion)																Länge↴
4	32	↪Länge (Fortsetzung)
8	64	Protokollnachricht(en)
12	96
⋮	⋮
⁠ ⁠${\displaystyle 5+m}$	⁠ ⁠${\displaystyle 40+m*8}$	Message Authentication Code (optional)
⋮	⋮
⋮	⋮
⁠ ⁠${\displaystyle 5+m+q}$	⁠ ⁠${\displaystyle 40+(m+q)*8}$	Auffüllung (nur Blockchiffren)

Inhaltstyp: 8 Bit

Dieses Feld kennzeichnet den im Datensatz enthaltenen Datensatzschichtprotokolltyp.

Inhaltstypen

Verhexen	Dezember	Typ
0x14	20	ChangeCipherSpec
0x15	21	Alarm
0x16	22	Handschlag
0x17	23	Anwendung
0x18	24	Herzschlag

Ältere Version: 16 Bit

Dieses Feld gibt die Haupt- und Nebenversion von TLS vor TLS 1.3 für die enthaltene Nachricht an. Bei einer ClientHello -Nachricht muss dies nicht die höchste vom Client unterstützte Version sein. Ab TLS 1.3 muss dieses Feld auf 0x0303 gesetzt werden, und die Anwendung muss unterstützte Versionen in einem zusätzlichen Nachrichtenerweiterungsblock senden.

Versionen

Hauptversion​	Nebenversion​	Versionstyp
3	0	SSL 3.0
3	1	TLS 1.0
3	2	TLS 1.1
3	3	TLS 1.2
3	4	TLS 1.3

Länge: 16 Bit; Länge < 2 ^¹⁴

Die Gesamtlänge der Protokollnachricht(en) , des MAC-Felds und der Padding- Felder. Die Länge sollte 2 ^¹⁴ Byte (16 KiB) nicht überschreiten.

Protokollnachricht(en): Variable

Eine oder mehrere Nachrichten, die durch das Feld „Protokoll“ identifiziert werden. Beachten Sie, dass dieses Feld je nach Verbindungsstatus verschlüsselt sein kann. Die Länge (in Bytes) aller Nachrichten wird durch den Buchstaben „m“ angegeben .

Message Authentication Code  (MAC): 16, 20 oder 32 Bytes (optional)

Ein Message Authentication Code (MAC), berechnet anhand des Felds „Protokollnachricht(en)“ und einschließlich zusätzlichem Schlüsselmaterial. 32 Byte für den SHA-256- basierten HMAC, 20 Byte für den SHA-1- basierten HMAC und 16 Byte für den MD5 -basierten HMAC. Dieses Feld kann je nach Verbindungsstatus verschlüsselt oder vollständig weggelassen sein. Die Länge des MAC (in Byte) wird durch den Buchstaben „ q“ angegeben .

Auffüllung: variabel (optional)

Polsterung wird nur bei Bedarf hinzugefügt.

Am Ende von TLS-Datensätzen dürfen keine MAC- oder Padding- Felder vorhanden sein, bevor alle Verschlüsselungsalgorithmen und -parameter ausgehandelt und per Handshake bestätigt wurden und anschließend durch Senden eines CipherStateChange- Datensatzes (siehe unten) signalisiert wurde, dass diese Parameter in allen weiteren vom selben Peer gesendeten Datensätzen wirksam werden.

Die meisten Nachrichten, die während des Aufbaus der TLS-Sitzung ausgetauscht werden, basieren auf diesem Datensatz, es sei denn, es tritt ein Fehler oder eine Warnung auf, die durch einen Alert-Protokolldatensatz signalisiert werden muss (siehe unten), oder der Verschlüsselungsmodus der Sitzung wird durch einen anderen Datensatz geändert (siehe ChangeCipherSpec -Protokoll unten).

Inhaltstyp: 8 Bit; == 22

Dieses Feld gibt den Handshake- Protokolltyp an.

Nachrichtentyp: 8 Bit

Dieses Feld kennzeichnet den Typ der Handshake-Nachricht.

Nachrichtentypen

Code	Beschreibung
0	HalloAnfrage
1	ClientHallo
2	ServerHallo
4	NewSessionTicket
8	Verschlüsselte Erweiterungen (nur TLS 1.3)
11	Zertifikat
12	ServerKeyExchange
13	Zertifikatsanforderung
14	ServerHelloDone
15	Zertifikatsprüfung
16	ClientKeyExchange
20	Fertig

Länge der Handshake-Nachrichtendaten: 24 Bit

Dies ist ein 3-Byte-Feld, das die Länge der Handshake-Daten angibt, ohne den Header.

Handshake-Nachricht: variabel

Daten der Handshake-Nachricht selbst.

Beachten Sie, dass mehrere Handshake-Nachrichten in einem Datensatz zusammengefasst werden können.

Dieser Datensatz sollte normalerweise nicht während des normalen Handshakes oder Anwendungsaustauschs gesendet werden. Er kann jedoch jederzeit während des Handshakes bis zum Verbindungsabbruch gesendet werden. Wird er verwendet, um einen schwerwiegenden Fehler zu signalisieren, wird die Sitzung unmittelbar nach dem Senden dieses Datensatzes geschlossen. Der Datensatz dient daher dazu, den Grund für den Verbindungsabbruch anzugeben. Ist die Warnstufe auf „Warnung“ gesetzt, kann die Gegenstelle die Sitzung schließen, wenn sie diese für ihre Zwecke als nicht zuverlässig genug einstuft (vorher kann die Gegenstelle auch ein eigenes Signal senden).

Inhaltstyp: 8 Bit; == 21

Dieses Feld gibt den Alarmprotokolltyp an .

Länge: 16 Bit; == 2

Die Länge der übrigen Felder beträgt 2.

Level: 8 Bit

Dieses Feld kennzeichnet die Alarmstufe. Bei einer kritischen Alarmstufe sollte der Absender die Sitzung sofort beenden. Andernfalls kann der Empfänger die Sitzung selbst beenden, indem er eine eigene kritische Alarmstufe sendet und die Sitzung anschließend sofort schließt. Die Verwendung von Alarmdatensätzen ist optional. Fehlt ein solcher Datensatz vor dem Sitzungsschluss, kann die Sitzung (mit ihren Handshakes) automatisch wiederaufgenommen werden.

Der normale Abschluss einer Sitzung nach Beendigung der übertragenen Anwendung sollte vorzugsweise mit einer Benachrichtigung vom Typ „Schließen“ (mit einfacher Warnstufe) signalisiert werden, um die automatische Wiederaufnahme einer neuen Sitzung zu verhindern. Die explizite Signalisierung des normalen Abschlusses einer sicheren Sitzung vor dem effektiven Schließen der Transportschicht ist hilfreich, um Angriffe zu verhindern oder zu erkennen (z. B. Versuche, die sicher übertragenen Daten abzuschneiden, falls diese keine vordefinierte Länge oder Dauer haben, die der Empfänger der sicheren Daten erwarten kann).

Alarmstufenarten

Code	Ebenentyp	Verbindungsstatus
1	Warnung	Die Verbindung oder die Sicherheit könnte instabil sein.
2	tödlich	Die Verbindung oder die Sicherheit könnten beeinträchtigt sein, oder es ist ein nicht behebbarer Fehler aufgetreten.

Beschreibung: 8 Bit

Dieses Feld gibt an, welche Art von Benachrichtigung gesendet wird.

Arten der Alarmbeschreibung

Code	Beschreibung	Ebenentypen	Notiz
0	Benachrichtigung schließen	Warnung / tödlich
10	Unerwartete Nachricht	tödlich
20	Fehlerhafter Datensatz MAC	tödlich	Möglicherweise liegt eine fehlerhafte SSL-Implementierung vor oder die Nutzdaten wurden manipuliert, z. B. durch eine Firewall-Regel auf dem FTPS- Server.
21	Entschlüsselung fehlgeschlagen	tödlich	Nur TLS, reserviert
22	Datensatzüberlauf	tödlich	TLS-only
30	Dekompressionsversagen	tödlich
40	Handshake fehlgeschlagen	tödlich
41	Kein Zertifikat	Warnung / tödlich	Nur SSL 3.0, reserviert
42	Schlechtes Zertifikat	Warnung / tödlich
43	Nicht unterstütztes Zertifikat	Warnung / tödlich	Das Zertifikat hat beispielsweise nur die Serverauthentifizierung aktiviert und wird als Clientzertifikat präsentiert.
44	Zertifikat widerrufen	Warnung / tödlich
45	Zertifikat abgelaufen	Warnung / tödlich	Prüfen Sie, ob das Serverzertifikat abgelaufen ist, und prüfen Sie auch, ob in der vorgelegten Zertifikatskette kein Zertifikat abgelaufen ist.
46	Zertifikat unbekannt	Warnung / tödlich
47	Ungültiger Parameter	tödlich
48	Unbekannte Zertifizierungsstelle (CA )	tödlich	TLS-only
49	Zugriff verweigert	tödlich	Nur TLS – z. B. wurde kein Clientzertifikat vorgelegt (TLS: Meldung "Leeres Zertifikat" oder SSLv3: Warnung "Kein Zertifikat"), der Server ist jedoch so konfiguriert, dass er ein Zertifikat erfordert.
50	Dekodierungsfehler	tödlich	TLS-only
51	Entschlüsselungsfehler	Warnung / tödlich	TLS-only
60	Ausfuhrbeschränkung	tödlich	Nur TLS, reserviert
70	Protokollversion	tödlich	TLS-only
71	Unzureichende Sicherheit	tödlich	TLS-only
80	Interner Fehler	tödlich	TLS-only
86	Unangemessener Ausweichmechanismus	tödlich	TLS-only
90	Nutzer hat abgebrochen	tödlich	TLS-only
100	Keine Neuverhandlung	Warnung	TLS-only
110	Nicht unterstützte Erweiterung	Warnung	TLS-only
111	Zertifikat nicht erhältlich	Warnung	TLS-only
112	Unbekannter Name	Warnung / tödlich	Nur TLS; der Server Name Indicator des Clients gab einen vom Server nicht unterstützten Hostnamen an.
113	Antwort auf den Status „Schlechtes Zertifikat“	tödlich	TLS-only
114	Ungültiger Zertifikat-Hashwert	tödlich	TLS-only
115	Unbekannte PSK- Identität	tödlich	Nur TLS. Wird in TLS-PSK und TLS-SRP verwendet .
116	Zertifikat erforderlich	tödlich	Nur TLS Version 1.3
120 oder 255	Kein Anwendungsprotokoll	tödlich	Nur TLS Version 1.3

Inhaltstyp: 8 Bit; == 20

Dieses Feld gibt den ChangeCipherSpec -Protokolltyp an.

Länge: 16 Bit; == 1

Die Länge der übrigen Felder beträgt 1.

CCS-Protokolltyp: 8 Bit

Dieses Feld kennzeichnet den CCS-Protokolltyp. Derzeit gibt es nur einen.

Anwendungs-TLS-Datensatzformat

Offset	Oktett	0								1								2								3
Oktett	Bisschen	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Inhaltstyp  (23)								Ältere Version (Haupt-/Nebenversion)																Länge↴
4	32	↪Länge (Fortsetzung)
8	64	Anwendungsdaten
12	96
⋮	⋮
⁠ ⁠${\displaystyle 5+m}$	⁠ ⁠${\displaystyle 40+m*8}$	Message Authentication Code (optional)
⋮	⋮
⋮	⋮
⁠ ⁠${\displaystyle 5+m+q}$	⁠ ⁠${\displaystyle 40+(m+q)*8}$	Auffüllung (nur Blockchiffren)

Inhaltstyp: 8 Bit; == 23

Dieses Feld kennzeichnet den Anwendungsprotokolltyp .

Länge: 16 Bit; Länge < 2 ^¹⁴

Die Gesamtlänge der Felder „Anwendungsdaten“ , „MAC“ und „Auffüllung“ . Die Länge sollte 2 ^¹⁴ Byte (16 KiB) nicht überschreiten .

Anwendungsdaten: Variable

Daten der Anwendung. Die Länge (in Bytes) der Daten wird durch den Buchstaben m angegeben .

Message Authentication Code  (MAC): 16, 20 oder 32 Bytes (optional)

Ein Message Authentication Code ( MAC ), berechnet anhand des Anwendungsdatenfelds . 32 Byte für den SHA-256- basierten HMAC, 20 Byte für den SHA-1- basierten HMAC, 16 Byte für den MD5 -basierten HMAC. Die Länge (in Byte) des MAC wird durch den Buchstaben „q“ angegeben .

Auffüllung: variabel (optional)

Das letzte Byte enthält die Länge des Padding-Bereichs.

Aus Sicht des Anwendungsprotokolls gehört TLS einer niedrigeren Schicht an, obwohl das TCP/IP-Modell dies nicht adäquat darstellt. Das bedeutet, dass der TLS-Handshake üblicherweise (außer im Fall von STARTTLS ) vor dem Start des Anwendungsprotokolls durchgeführt wird. Bei der von der Anwendungsschicht bereitgestellten Funktion namensbasierter virtueller Server verwenden alle gemeinsam gehosteten virtuellen Server dasselbe Zertifikat, da der Server unmittelbar nach der ClientHello-Nachricht ein Zertifikat auswählen und senden muss. Dies stellt in Hosting-Umgebungen ein erhebliches Problem dar, da entweder alle Kunden dasselbe Zertifikat verwenden oder jedem Kunden eine andere IP-Adresse zugewiesen werden muss.

Es gibt zwei bekannte Umgehungslösungen, die von X.509 bereitgestellt werden :

• Gehören alle virtuellen Server zur selben Domäne, kann ein Wildcard-Zertifikat verwendet werden. ^{[ 186 ]} Abgesehen von der möglicherweise problematischen, aber nicht uneingeschränkten Wahl des Hostnamens besteht keine allgemeine Übereinkunft darüber, wie Wildcard-Zertifikate zugeordnet werden sollen. Je nach Anwendungsprotokoll oder verwendeter Software gelten unterschiedliche Regeln. ^{[ 187 ]}
• Fügen Sie jeden virtuellen Hostnamen in die SubjectAltName-Erweiterung ein. Das Hauptproblem besteht darin, dass das Zertifikat jedes Mal neu ausgestellt werden muss, wenn ein neuer virtueller Server hinzugefügt wird.

Um den Servernamen anzugeben, ermöglichen die TLS-Erweiterungen (Transport Layer Security) Clients, eine Server Name Indication (SNI)-Erweiterung in die erweiterte ClientHello-Nachricht einzufügen. ^{[ 188 ] : §3} Diese Erweiterung gibt dem Server sofort einen Hinweis darauf, mit welchem ​​Namen der Client eine Verbindung herstellen möchte, sodass der Server das entsprechende Zertifikat auswählen und an die Clients senden kann.

Es gibt auch eine Methode zur Implementierung namensbasierter virtueller Hosting-Lösungen durch ein Upgrade von HTTP auf TLS mittels eines HTTP/1.1-Upgrade-Headers . ^{[ 2 ]} Normalerweise dient dies dazu, HTTP über TLS innerhalb des Haupt -URI-Schemas „http“ anstelle des üblicherweise verwendeten „https“-Schemas sicher zu implementieren . Dadurch würde eine Verzweigung des URI-Bereichs vermieden und die Anzahl der verwendeten Ports reduziert. Allerdings unterstützen derzeit nur wenige Implementierungen diese Methode.

• Protokollverhandlung auf Anwendungsschicht – eine TLS-Erweiterung, die für SPDY und TLS False Start verwendet wird
• Bullrun (Entschlüsselungsprogramm) – ein geheimes Anti-Verschlüsselungsprogramm der US-amerikanischen National Security Agency.
• Zertifizierungsstelle
• Zertifikat Transparenz
• Datagramm-TLS (DTLS)
• Delegierte Berechtigung
• HTTP Strict Transport Security – HSTS
• Schlüsselringdatei
• Private Communications Technology (PCT) – ein historischer Microsoft-Konkurrent von SSL 2.0
• QUIC (Quick UDP Internet Connections) – „…wurde entwickelt, um einen Sicherheitsschutz zu bieten, der TLS/SSL gleichwertig ist“; das Hauptziel von QUIC ist die Verbesserung der wahrgenommenen Leistung von verbindungsorientierten Webanwendungen, die derzeit TCP verwenden.
• Servergesteuerte Kryptographie
• tcpcrypt
• Datagramm-Transportschichtsicherheit
• TLS-Beschleunigung

• Wagner, David; Schneier, Bruce (November 1996). „Analyse des SSL 3.0-Protokolls“ (PDF) . Tagungsband des zweiten USENIX-Workshops zum Thema elektronischer Handel . USENIX Press. S.  29–40 . Archiviert (PDF) vom Original am 16.10.2006 . Abgerufen am 12.10.2006 .
• Rescorla, Eric (2001). SSL und TLS: Entwurf und Aufbau sicherer Systeme . Vereinigte Staaten: Addison-Wesley Pub Co. ISBN 978-0-201-61598-2Die
• Stephen A. Thomas (2000). SSL und TLS Grundlagen: Das Web sichern . New York: Wiley. ISBN 978-0-471-38354-3Die
• Bard, Gregory (2006). „Ein anspruchsvoller, aber machbarer blockweise-adaptiver Angriff mit gewähltem Klartext auf SSL“ . International Association for Cryptologic Research (136). Archiviert vom Original am 23.09.2011 . Abgerufen am 23.09.2011 .
• Canvel, Brice. „Passwortabfang in einem SSL/TLS-Kanal“ . Archiviert vom Original am 20.04.2016 . Abgerufen am 20.04.2007 .
• VPNs mit IPsec und SSL/TLS erstellen (Archiviert am 12.04.2015 im Internet Archive) – Linux Journal-Artikel von Rami Rosen
• Joshua Davies (2010). Implementierung von SSL/TLS . Wiley. ISBN 978-0470920411Die
• Polk, Tim; McKay, Kerry; Chokhani, Santosh (April 2014). „Richtlinien für die Auswahl, Konfiguration und Verwendung von TLS-Implementierungen“ (PDF) . National Institute of Standards and Technology. Archiviert vom Original (PDF) am 8. Mai 2014. Abgerufen am 7. Mai 2014 .
• Abdou, AbdelRahman; van Oorschot, Paul (August 2017). „Server Location Verification (SLV) and Server Location Pinning: Augmenting TLS Authentication“ . ACM Transactions on Privacy and Security . 21 (1): 1:1–1:26. doi : 10.1145/3139294 . S2CID  5869541. Archiviert vom Original am 22.03.2019 . Abgerufen am 11.01.2018 .
• Ivan Ristic (2022). Bulletproof TLS and PKI, Zweite Auflage . Feisty Duck. ISBN 978-1907117091Die

• Internet Engineering Task Force – TLS-Arbeitsgruppe (Archiviert am 11.01.2014 im Internet Archive)

Die aktuell genehmigte Version von (D)TLS ist Version 1.3, die wie folgt spezifiziert ist:

• RFC  8446 – " Das Transport Layer Security (TLS) Protokoll Version 1.3, " ^{[ 6 ]} Vorgeschlagener Standard.
• RFC  9147 – " Das Datagram Transport Layer Security (DTLS) Protokoll Version 1.3, " ^{[ 11 ]} Vorgeschlagener Standard.

Die aktuellen Standards ersetzen diese früheren Versionen:

• RFC  5246 – " Das Transport Layer Security (TLS) Protokoll Version 1.2, " ^{[ 25 ]} Veraltet.
• RFC  6347 – " Datagram Transport Layer Security Version 1.2, " ^{[ 8 ]} Veraltet.
• RFC  4346 – " Das Transport Layer Security (TLS) Protokoll Version 1.1, " ^{[ 46 ]} Historisch.
• RFC  2246 – " Das TLS-Protokoll Version 1.0, " ^{[ 189 ]} Historisch.
• RFC  6101 – " Das Secure Sockets Layer (SSL) Protokoll Version 3.0, " ^{[ 190 ]} Historisch.
• Internet-Entwurf (1995) : „Das SSL-Protokoll“

Weitere RFCs erweiterten (D)TLS.

Erweiterungen von (D)TLS 1.3 umfassen:

• RFC  9367 – " GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3, " ^{[ 87 ]} Informational.

Erweiterungen von (D)TLS 1.2 umfassen:

• RFC  5288 – " AES Galois Counter Mode (GCM) Cipher Suites for TLS, " ^{[ 88 ]} Proposed Standard.
• RFC  5289 – " TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM), " ^{[ 89 ]} Proposed Standard.
• RFC  5746 – " Transport Layer Security (TLS) Renegotiation Indication Extension, " ^{[ 111 ]} Vorgeschlagener Standard.
• RFC  5878 – " Transport Layer Security (TLS) Authorization Extensions, " ^{[ 191 ]} Experimentell.
• RFC  5932 – " Camellia Cipher Suites for TLS, " ^{[ 93 ]} Vorgeschlagener Standard.
• RFC  6066 – " Transport Layer Security (TLS) Extensions: Extension Definitions, " ^{[ 188 ]} Proposed Standard.
  Beinhaltet Server Name Indication und OCSP-Stapling .
• RFC  6091 – " Verwendung von OpenPGP- Schlüsseln für die Transport Layer Security (TLS)-Authentifizierung, " ^{[ 192 ]} Information.
• RFC  6176 – " Verbot von Secure Sockets Layer (SSL) Version 2.0, " ^{[ 19 ]} Vorgeschlagener Standard.
• RFC  6209 – " Hinzufügung der ARIA Cipher Suites zu Transport Layer Security (TLS), " ^{[ 94 ]} Information.
• RFC  6347 – " Datagram Transport Layer Security Version 1.2, " ^{[ 8 ]} Veraltet.
  Die Definition ist nun Teil der DTLS 1.3-Spezifikation.
• RFC  6367 – " Hinzufügung der Camellia Cipher Suites zu Transport Layer Security (TLS), " ^{[ 92 ]} Information.
• RFC  6460 – " Suite B Profile for Transport Layer Security (TLS), " ^{[ 193 ]} Historisch.
  Die Unterstützung für Suite B Cryptography wurde von der National Security Agency eingestellt .
• RFC  6655 – " AES-CCM Cipher Suites for Transport Layer Security (TLS), " ^{[ 90 ]} Vorgeschlagener Standard.
• RFC  7027 – " Elliptische Kurvenkryptographie (ECC) Brainpool-Kurven für Transport Layer Security (TLS), " ^{[ 194 ]} Informational.
• RFC  7251 – " AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS, " ^{[ 91 ]} Informational.
• RFC  7301 – " Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension, " ^{[ 195 ]} Vorgeschlagener Standard.
• RFC  7366 – " Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS), " ^{[ 139 ]} Proposed Standard.
• RFC  7465 – " Verbot von RC4-Verschlüsselungssuiten, " ^{[ 101 ]} Vorgeschlagener Standard.
• RFC  7507 – " TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks, " ^{[ 196 ]} Veraltet.
• RFC  7568 – " Abschaffung von Secure Sockets Layer Version 3.0, " ^{[ 20 ]} Vorgeschlagener Standard.
• RFC  7627 – " Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension, " ^{[ 197 ]} Proposed Standard.
• RFC  7685 – " Eine ClientHello-Padding-Erweiterung für Transport Layer Security (TLS) " ^{[ 198 ]} Vorgeschlagener Standard.
• RFC  8422 – " Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Version 1.2 and Earlier, " ^{[ 84 ]} Proposed Standard.
• RFC  9189 – " GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.2, " ^{[ 86 ]} Informational.

Erweiterungen von (D)TLS 1.1 umfassen:

• RFC  4366 – " Transport Layer Security (TLS) Extensions, " ^{[ 199 ]} Veraltet.
  Beschreibt sowohl eine Reihe spezifischer Erweiterungen als auch einen generischen Erweiterungsmechanismus.
• RFC  4492 – " Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS), " ^{[ 200 ]} Veraltet.
• RFC  4680 – " TLS Handshake Message for Supplemental Data, " ^{[ 201 ]} Proposed Standard.
• RFC  4681 – " TLS User Mapping Extension, " ^{[ 202 ]} Vorgeschlagener Standard.
• RFC  4785 – " Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS), " ^{[ 203 ]} Proposed Standard.
• RFC  5054 – " Verwendung des Secure Remote Password (SRP)-Protokolls für die TLS-Authentifizierung, " ^{[ 204 ]} Information.
  Definiert die TLS-SRP- Verschlüsselungssammlungen.
• RFC  5077 – " Transport Layer Security (TLS) Session Resumption without Server-Side State, " ^{[ 185 ]} Veraltet.
• RFC  5081 – " Verwendung von OpenPGP-Schlüsseln für die Transport Layer Security (TLS)-Authentifizierung, " ^{[ 205 ]} Experimentell.
• RFC  5216 – " Das EAP -TLS Authentifizierungsprotokoll, " ^{[ 206 ]} Vorgeschlagener Standard.

Zu den Erweiterungen von TLS 1.0 gehören:

• RFC  2595 – " Using TLS with IMAP, POP3 and ACAP, " ^{[ 207 ]} Proposed Standard.
  Beschreibt eine Erweiterung der IMAP-, POP3- und ACAP-Dienste, die es Server und Client ermöglicht, Transport-Layer-Security zu verwenden, um eine private, authentifizierte Kommunikation über das Internet zu gewährleisten.
• RFC  2712 – " Hinzufügung von Kerberos -Verschlüsselungssammlungen zur Transport Layer Security (TLS) " , ^{[ 208 ]} Vorgeschlagener Standard.
  Die in diesem Memo definierten 40-Bit-Verschlüsselungssuiten werden nur zu dem Zweck aufgeführt, zu dokumentieren, dass diese Verschlüsselungssuiten-Codes bereits vergeben wurden.
• RFC  2817 – " Upgrade auf TLS innerhalb von HTTP/1.1, " ^{[ 2 ]} Vorgeschlagener Standard.
  Erklärt, wie der Upgrade-Mechanismus in HTTP/1.1 verwendet wird , um Transport Layer Security (TLS) über eine bestehende TCP-Verbindung zu initiieren. Dadurch können ungesicherter und gesicherter HTTP-Datenverkehr denselben bekannten Port nutzen (in diesem Fall http: auf Port 80 statt https: auf Port 443).
• RFC  2818 – " HTTP Over TLS, " ^{[ 209 ]} Veraltet.
  Unterscheidet gesicherten Datenverkehr von ungesichertem Datenverkehr durch die Verwendung eines anderen „Server-Ports“.
• RFC  3207 – " SMTP Service Extension for Secure SMTP over Transport Layer Security, " ^{[ 210 ]} Proposed Standard.
  Beschreibt eine Erweiterung des SMTP-Dienstes, die es einem SMTP-Server und -Client ermöglicht, Transport-Layer-Security zu verwenden, um eine private, authentifizierte Kommunikation über das Internet zu gewährleisten.
• RFC  3268 – " Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS), " ^{[ 211 ]} Veraltet.
  Fügt den bereits bestehenden symmetrischen Verschlüsselungsverfahren Advanced Encryption Standard (AES)-Verschlüsselungssuiten hinzu.
• RFC  3546 – ​​" Transport Layer Security (TLS) Extensions, " ^{[ 212 ]} Veraltet.
  Fügt einen Mechanismus zur Aushandlung von Protokollerweiterungen während der Sitzungsinitialisierung hinzu und definiert einige Erweiterungen.
• RFC  3749 – " Transport Layer Security Protocol Compression Methods, " ^{[ 213 ]} Proposed Standard.
  Legt den Rahmen für Komprimierungsmethoden und die DEFLATE -Komprimierungsmethode fest.
• RFC  3943 – " Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS), " ^{[ 214 ]} Informational.
• RFC  4132 – " Hinzufügung von Camellia Cipher Suites zu Transport Layer Security (TLS), " ^{[ 215 ]} Veraltet.
• RFC  4162 – " Hinzufügung von SEED-Verschlüsselungssammlungen zur Transport Layer Security (TLS) " , ^{[ 95 ]} Vorgeschlagener Standard.
• RFC  4217 – " Sicherung von FTP mit TLS " , ^{[ 216 ]} Vorgeschlagener Standard.
• RFC  4279 – " Pre-Shared Key Ciphersuites for Transport Layer Security (TLS), " ^{[ 217 ]} Proposed Standard.
  Fügt drei neue Cipher-Suites für das TLS-Protokoll hinzu, um die Authentifizierung auf Basis von vorab vereinbarten Schlüsseln zu unterstützen.

• RFC  7457 – " Zusammenfassung bekannter Angriffe auf Transport Layer Security (TLS) und Datagram TLS (DTLS), " ^{[ 218 ]} Information.
• RFC  9325 – " Empfehlungen für die sichere Verwendung von Transport Layer Security (TLS) und Datagram Transport Layer Security (DTLS), " ^{[ 219 ]} Best Current Practice 195.