3. Allgemeine Empfehlungen

Dieser Abschnitt enthält allgemeine Empfehlungen zur sicheren Verwendung von TLS. Empfehlungen zu Cipher-Suites werden im folgenden Abschnitt behandelt.

3.1. Protokollversionen

3.1.1. SSL/TLS-Protokollversionen

Es ist wichtig, sowohl die Verwendung alter, weniger sicherer Versionen von SSL/TLS einzustellen als auch moderne, sicherere Versionen zu verwenden; daher sind folgende Empfehlungen bezüglich der TLS/SSL-Protokollversionen zu beachten:

• Implementierungen DÜRFEN NICHT SSL Version 2 aushandeln.

  Grund: SSLv2 gilt heute als unsicher [RFC6176].

• Implementierungen DÜRFEN NICHT SSL Version 3 aushandeln.

  Grund: SSLv3 [RFC6101] war eine Verbesserung gegenüber SSLv2 und schloss einige wichtige Sicherheitslücken, unterstützte jedoch keine starken Cipher-Suites. SSLv3 unterstützt keine TLS-Erweiterungen, von denen einige (z. B. renegotiation_info [RFC5746]) sicherheitskritisch sind. Außerdem wird SSLv3 mit dem Aufkommen des Padding Oracle On Downgraded Legacy Encryption (POODLE)-Angriffs [POODLE] nun allgemein als grundlegend unsicher angesehen. Siehe [RFC7568] für weitere Details.

• Implementierungen DÜRFEN NICHT TLS Version 1.0 [RFC2246] aushandeln.

  Grund: TLS 1.0 (veröffentlicht 1999) unterstützt viele moderne, starke Cipher-Suites nicht. Darüber hinaus fehlt TLS 1.0 ein Initialisierungsvektor (IV) pro Datensatz für Cipher-Block-Chaining (CBC)-basierte Cipher-Suites und warnt nicht vor häufigen Padding-Fehlern. Diese und andere Empfehlungen in diesem Abschnitt stehen im Einklang mit [RFC8996].

• Implementierungen DÜRFEN NICHT TLS Version 1.1 [RFC4346] aushandeln.

  Grund: TLS 1.1 (veröffentlicht 2006) ist eine Sicherheitsverbesserung gegenüber TLS 1.0, unterstützt aber immer noch bestimmte stärkere Cipher-Suites nicht, die mit der Standardisierung von TLS 1.2 im Jahr 2008 eingeführt wurden, einschließlich der Cipher-Suites, die durch dieses Dokument für TLS 1.2 empfohlen werden (siehe Abschnitt 4.2 unten).

• Implementierungen MÜSSEN TLS 1.2 [RFC5246] unterstützen.

  Grund: TLS 1.2 ist derzeit weiter verbreitet implementiert und eingesetzt als TLS 1.3, und wenn die Empfehlungen dieses Dokuments befolgt werden, um bekannte Angriffe zu mindern, ist die Verwendung von TLS 1.2 ebenso sicher wie die Verwendung von TLS 1.3. Für die meisten Anwendungsprotokolle, die TLS und DTLS wiederverwenden, besteht kein unmittelbarer Bedarf, nur auf TLS 1.3 zu migrieren. Da viele Anwendungsclients auf TLS-Bibliotheken oder Betriebssysteme angewiesen sind, die TLS 1.3 noch nicht unterstützen, würde eine proaktive Veraltung von TLS 1.2 erhebliche Interoperabilitätsprobleme mit sich bringen und somit der Sicherheit mehr schaden als nützen. Dennoch wird erwartet, dass eine zukünftige Version dieses BCP die Verwendung von TLS 1.2 veralten wird, wenn dies angemessen ist.

• Implementierungen SOLLTEN TLS 1.3 [RFC8446] unterstützen und, falls implementiert, MÜSSEN es vorziehen, TLS 1.3 gegenüber früheren Versionen von TLS auszuhandeln.

  Grund: TLS 1.3 ist eine grundlegende Überarbeitung des Protokolls und behebt viele der Sicherheitsprobleme mit TLS 1.2. Soweit eine Implementierung TLS 1.2 unterstützt (auch wenn sie standardmäßig TLS 1.3 verwendet), MUSS sie den Empfehlungen zu TLS 1.2 folgen, die in diesem Dokument spezifiziert sind.

• Neue Transportprotokolle, die das TLS/DTLS-Handshake-Protokoll und/oder die Record-Layer integrieren, MÜSSEN nur TLS/DTLS 1.3 verwenden (z. B. hat QUIC [RFC9001] diesen Ansatz gewählt). Neue Anwendungsprotokolle, die TLS/DTLS für Kanal- oder Sitzungsverschlüsselung verwenden, MÜSSEN sowohl in die TLS/DTLS-Versionen 1.2 als auch 1.3 integriert werden; dennoch KÖNNEN Anwendungsprotokolldesigner in seltenen Fällen, in denen eine breite Interoperabilität kein Anliegen ist, auf TLS 1.2 verzichten.

  Grund: Die sichere Bereitstellung von TLS 1.3 ist deutlich einfacher und weniger fehleranfällig als die sichere Bereitstellung von TLS 1.2. Beim Entwurf eines neuen sicheren Transportprotokolls wie QUIC gibt es keinen Grund, TLS 1.2 zu unterstützen. Im Gegensatz dazu müssen neue Anwendungsprotokolle, die TLS wiederverwenden, sowohl TLS 1.3 als auch TLS 1.2 unterstützen, um die Unterstützung der zugrunde liegenden Bibliotheken oder des Betriebssystems für beide Versionen nutzen zu können.

Dieses BCP gilt für TLS 1.3, TLS 1.2 und frühere Versionen. Es ist nicht sicher für Leser, anzunehmen, dass die Empfehlungen in diesem BCP für zukünftige Versionen von TLS gelten.

3.1.2. DTLS-Protokollversionen

DTLS, eine Anpassung von TLS für UDP-Datagramme, wurde bei der Veröffentlichung von TLS 1.1 eingeführt. Folgende Empfehlungen gelten für DTLS:

• Implementierungen DÜRFEN NICHT DTLS Version 1.0 [RFC4347] aushandeln.

  Version 1.0 von DTLS entspricht Version 1.1 von TLS (siehe oben).

• Implementierungen MÜSSEN DTLS 1.2 [RFC6347] unterstützen.

  Version 1.2 von DTLS entspricht Version 1.2 von TLS (siehe oben). (Es gibt keine Version 1.1 von DTLS.)

• Implementierungen SOLLTEN DTLS 1.3 [RFC9147] unterstützen und, falls implementiert, MÜSSEN es vorziehen, DTLS Version 1.3 gegenüber früheren Versionen von DTLS auszuhandeln.

  Version 1.3 von DTLS entspricht Version 1.3 von TLS (siehe oben).

3.1.3. Fallback auf niedrigere Versionen

TLS/DTLS 1.2-Clients DÜRFEN KEINEN Fallback auf frühere TLS-Versionen durchführen, da diese Versionen veraltet sind [RFC8996]. Infolgedessen wird der Downgrade Protection Signaling Cipher Suite Value (SCSV)-Mechanismus [RFC7507] für Clients nicht mehr benötigt. Darüber hinaus implementiert TLS 1.3 einen neuen Versionsaushandlungsmechanismus.

3.2. Strict TLS

Die folgenden Empfehlungen werden bereitgestellt, um "SSL Stripping" und STARTTLS-Befehlsinjektion zu verhindern (Angriffe, die in [RFC7457] zusammengefasst sind):

• Viele bestehende Anwendungsprotokolle wurden entworfen, bevor die Verwendung von TLS üblich wurde. Diese Protokolle unterstützen TLS typischerweise auf eine von zwei Arten: entweder über einen separaten Port nur für TLS-Kommunikation (z. B. Port 443 für HTTPS) oder über eine Methode zur dynamischen Aktualisierung eines unverschlüsselten Kanals auf einen TLS-geschützten Kanal (z. B. STARTTLS, das in Protokollen wie IMAP und XMPP verwendet wird). Unabhängig davon, welcher Mechanismus zum Schutz des Kommunikationskanals verwendet wird (nur TLS-Port oder dynamisches Upgrade), zählt der resultierende Zustand des Kanals. Wenn ein Protokoll sowohl eine Methode für dynamisches Upgrade als auch eine separate Methode nur für TLS definiert, dann MUSS die separate Methode nur für TLS von Implementierungen unterstützt werden und MUSS von Administratoren konfiguriert werden, um gegenüber der Methode für dynamisches Upgrade bevorzugt zu werden. Wenn ein Protokoll nur eine Methode für dynamisches Upgrade unterstützt, MÜSSEN Implementierungen Administratoren eine Möglichkeit bieten, eine strikte lokale Richtlinie festzulegen, die die Verwendung von Klartext in Abwesenheit eines ausgehandelten TLS-Kanals verbietet, und Administratoren MÜSSEN diese Richtlinie verwenden.

• HTTP-Client- und Serverimplementierungen, die für die Verwendung im World Wide Web bestimmt sind (siehe Abschnitt 5), MÜSSEN das Header-Feld HTTP Strict Transport Security (HSTS) [RFC6797] unterstützen, damit Webserver ankündigen können, dass sie bereit sind, Nur-TLS-Clients zu akzeptieren. Webserver SOLLTEN HSTS verwenden, um ihre Bereitschaft anzuzeigen, Nur-TLS-Clients zu akzeptieren, es sei denn, sie sind so bereitgestellt, dass die Verwendung von HSTS tatsächlich die Gesamtsicherheit schwächen würde (z. B. kann es problematisch sein, HSTS mit selbstsignierten Zertifikaten zu verwenden, wie in Abschnitt 11.3 von [RFC6797] beschrieben). Ähnliche Technologien existieren für Nicht-HTTP-Anwendungsprotokolle, wie Mail Transfer Agent Strict Transport Security (MTA-STS) für Mail Transfer Agents [RFC8461] und Methoden basierend auf DNS-Based Authentication of Named Entities (DANE) [RFC6698] für SMTP [RFC7672] und XMPP [RFC7712].

Grund: Die Kombination von ungeschützter und TLS-geschützter Kommunikation eröffnet SSL-Stripping und ähnliche Angriffe, da ein anfänglicher Teil der Kommunikation nicht integritätsgeschützt ist und daher von einem Angreifer manipuliert werden kann, dessen Ziel es ist, die Kommunikation im Klartext zu halten.

3.3. Komprimierung

Um komprimierungsbezogene Angriffe (zusammengefasst in Abschnitt 2.6 von [RFC7457]) bei Verwendung von TLS 1.2 zu verhindern, SOLLTEN Implementierungen und Bereitstellungen die Komprimierung auf TLS-Ebene (Abschnitt 6.2.2 von [RFC5246]) NICHT unterstützen; die einzige Ausnahme ist, wenn das betreffende Anwendungsprotokoll nachweislich nicht für solche Angriffe offen ist. Aber selbst in diesem Fall ist aufgrund des Potenzials für zukünftige komprimierungsbezogene TLS-Angriffe äußerste Vorsicht geboten. Insbesondere ist bekannt, dass das HTTP-Protokoll für komprimierungsbezogene Angriffe anfällig ist. (Diese Empfehlung gilt nur für TLS 1.2, da die Komprimierung aus TLS 1.3 entfernt wurde.)

Grund: TLS-Komprimierung war Gegenstand von Sicherheitsangriffen wie dem Compression Ratio Info-leak Made Easy (CRIME)-Angriff.

Implementierer sollten beachten, dass Komprimierung auf höheren Protokollebenen einem aktiven Angreifer ermöglichen kann, Klartextinformationen aus der Verbindung zu extrahieren. Der Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH)-Angriff ist ein solcher Fall. Diese Probleme können nur außerhalb von TLS gemildert werden und liegen daher außerhalb des Geltungsbereichs dieses Dokuments. Siehe Abschnitt 2.6 von [RFC7457] für weitere Details.

3.3.1. Zertifikatskomprimierung

Zertifikatsketten nehmen oft den Großteil der während des Handshakes übertragenen Bytes ein. Um ihre Größe zu verwalten, können einige oder alle der folgenden Methoden angewendet werden (siehe auch Abschnitt 4 von [RFC9191] für weitere Vorschläge):

• Begrenzen Sie die Anzahl der Namen oder Erweiterungen.

• Verwenden Sie Schlüssel mit kleinen Darstellungen öffentlicher Schlüssel, wie den Elliptic Curve Digital Signature Algorithm (ECDSA).

• Verwenden Sie Zertifikatskomprimierung.

Um letzteres zu erreichen, definiert TLS 1.3 die Erweiterung compress_certificate in [RFC8879]. Siehe auch Abschnitt 5 von [RFC8879] für Sicherheits- und Datenschutzüberlegungen im Zusammenhang mit ihrer Verwendung. Um Zweifel auszuschließen: Angriffe im CRIME-Stil auf die TLS-Komprimierung gelten nicht für die Zertifikatskomprimierung.

Aufgrund der hohen Wahrscheinlichkeit von Störungen durch Middleboxen wurde die Komprimierung im Stil von [RFC8879] in TLS 1.2 nicht verfügbar gemacht. Theoretisch könnte die in [RFC7924] definierte Erweiterung cached_info verwendet werden, wird jedoch nicht breit genug unterstützt, um als praktische Alternative in Betracht gezogen zu werden.

3.4. TLS-Sitzungswiederaufnahme

Die Sitzungswiederaufnahme reduziert die Anzahl der vollständigen TLS-Handshakes erheblich und ist daher ein wesentliches Leistungsmerkmal für die meisten Bereitstellungen.

Zustandslose Sitzungswiederaufnahme mit Sitzungstickets ist eine beliebte Strategie. Für TLS 1.2 ist es in [RFC5077] spezifiziert. Für TLS 1.3 wird ein sichererer Mechanismus basierend auf der Verwendung eines Pre-Shared Key (PSK) in Abschnitt 4.6.1 von [RFC8446] beschrieben. Siehe [Springall16] für eine quantitative Studie über die Risiken, die durch TLS-Kryptografie-"Abkürzungen", einschließlich Sitzungswiederaufnahme, entstehen.

Wenn verwendet, MÜSSEN Wiederaufnahmeinformationen authentifiziert und verschlüsselt werden, um Änderungen oder Abhören durch einen Angreifer zu verhindern. Weitere Empfehlungen gelten für Sitzungstickets:

• Bei der Verschlüsselung des Tickets MUSS eine starke Verschlüsselung verwendet werden (mindestens so stark wie die Haupt-TLS-Cipher-Suite).

• Ticketverschlüsselungsschlüssel MÜSSEN regelmäßig gewechselt werden, z. B. einmal pro Woche, um den Nutzen von Forward Secrecy nicht zunichte zu machen (siehe Abschnitt 7.3 für Details zu Forward Secrecy). Alte Ticketverschlüsselungsschlüssel MÜSSEN am Ende der Gültigkeitsdauer vernichtet werden.

• Aus ähnlichen Gründen MUSS die Gültigkeit des Sitzungstickets auf eine angemessene Dauer beschränkt werden (z. B. die Hälfte der Gültigkeit des Ticketverschlüsselungsschlüssels).

• TLS 1.2 rolliert den Sitzungsschlüssel nicht innerhalb einer Sitzung. Um einen Angriff zu verhindern, bei dem der Ticketverschlüsselungsschlüssel des Servers gestohlen und verwendet wird, um den gesamten Inhalt einer Sitzung zu entschlüsseln (wodurch das Konzept der Forward Secrecy zunichte gemacht wird), SOLLTE ein TLS 1.2-Server KEINE zu alten Sitzungen wiederaufnehmen, z. B. Sitzungen, die länger als zwei Rotationsperioden des Ticketverschlüsselungsschlüssels offen waren.

Grund: Sitzungswiederaufnahme ist eine andere Art von TLS-Handshake und muss daher genauso sicher sein wie der ursprüngliche Handshake. Dieses Dokument (Abschnitt 4) empfiehlt die Verwendung von Cipher-Suites, die Forward Secrecy bieten, d. h. die einen Angreifer, der momentanen Zugriff auf den TLS-Endpunkt (Client oder Server) und seine Geheimnisse erhält, daran hindern, vergangene oder zukünftige Kommunikation zu lesen. Tickets müssen so verwaltet werden, dass diese Sicherheitseigenschaft nicht zunichte gemacht wird.

TLS 1.3 bietet die leistungsstarke Option von Forward Secrecy sogar innerhalb einer lang andauernden Verbindung, die regelmäßig wiederaufgenommen wird. Abschnitt 2.2 von [RFC8446] empfiehlt, dass Clients beim Initiieren der Sitzungswiederaufnahme einen "key_share" senden SOLLTEN. Um Forward Secrecy zu erreichen, empfiehlt dieses Dokument, dass Serverimplementierungen den PSK-Schlüsselaustauschmodus "psk_dhe_ke" auswählen und mit einem "key_share" antworten SOLLTEN, um bei jeder Sitzungswiederaufnahme einen Ephemeral Elliptic Curve Diffie-Hellman (ECDHE)-Austausch durchzuführen. Als leistungsfähigere Alternative KÖNNEN Serverimplementierungen darauf verzichten, mit einem "key_share" zu antworten, bis eine bestimmte Zeit (z. B. gemessen in Stunden) seit dem letzten ECDHE-Austausch vergangen ist; dies impliziert, dass die "key_share"-Operation für die vermutliche Mehrheit der Sitzungswiederaufnahmeanträge (die innerhalb weniger Stunden erfolgen würden) nicht stattfinden würde, während Forward Secrecy für länger andauernde Sitzungen gewährleistet wäre.

Die TLS-Sitzungswiederaufnahme führt potenzielle Datenschutzprobleme ein, bei denen der Server den Client verfolgen kann, in einigen Fällen auf unbestimmte Zeit. Siehe [Sy2018] für weitere Details.

3.5. Neuverhandlung in TLS 1.2

Die Empfehlungen in diesem Abschnitt gelten nur für TLS 1.2, da die Neuverhandlung aus TLS 1.3 entfernt wurde.

Neuverhandlung in TLS 1.2 ist ein Handshake, der neue kryptographische Parameter für eine bestehende Sitzung festlegt. Der Mechanismus existierte in TLS 1.2 und in früheren Versionen des Protokolls und wurde nach mehreren großen Angriffen, einschließlich eines Klartextinjektionsangriffs, CVE-2009-3555 [CVE], verbessert.

TLS 1.2-Clients und -Server MÜSSEN die Erweiterung renegotiation_info implementieren, wie in [RFC5746] definiert.

TLS 1.2-Clients MÜSSEN renegotiation_info im Client Hello senden. Wenn der Server die Erweiterung nicht erkennt, MUSS der Client ein fatales Handshake_failure-Alarm generieren, bevor er die Verbindung beendet.

Grund: Es ist für einen Client nicht sicher, sich mit einem TLS 1.2-Server zu verbinden, der renegotiation_info nicht unterstützt, unabhängig davon, ob einer der Endpunkte tatsächlich eine Neuverhandlung implementiert. Siehe auch Abschnitt 4.1 von [RFC5746].

Ein damit zusammenhängender Angriff, der aus unzureichend authentifizierten TLS-Sitzungsparametern resultiert, ist ein Triple Handshake [Triple-Handshake]. Um diesem Angriff entgegenzuwirken, MÜSSEN TLS 1.2-Implementierungen die in [RFC7627] definierte Erweiterung extended_master_secret unterstützen.

3.6. Post-Handshake-Authentifizierung

Die Neuverhandlung in TLS 1.2 wurde in TLS 1.3 (teilweise) durch separate Mechanismen für Post-Handshake-Authentifizierung und Schlüsselaktualisierung ersetzt. Im Kontext von Protokollen, die Anfragen über eine einzelne Verbindung multiplexen (wie HTTP/2 [RFC9113]), stellt die Post-Handshake-Authentifizierung dieselben Probleme wie die TLS 1.2-Neuverhandlung dar. Multiplexing-Protokolle SOLLTEN den Anweisungen für HTTP/2 in Abschnitt 9.2.3 von [RFC9113] folgen.

3.7. Server Name Indication (SNI)

TLS-Implementierungen MÜSSEN die Erweiterung Server Name Indication (SNI), definiert in Abschnitt 3 von [RFC6066], für Protokolle auf höherer Ebene unterstützen, die davon profitieren würden, einschließlich HTTPS. Die tatsächliche Verwendung von SNI unter bestimmten Umständen ist jedoch eine Frage der lokalen Richtlinie. Zum Zeitpunkt des Schreibens wird innerhalb der TLS-Arbeitsgruppe eine Technologie zur SNI-Verschlüsselung (als Encrypted Client Hello bezeichnet) erarbeitet [TLS-ECH]. Sobald diese Methode standardisiert und weit verbreitet implementiert ist, wird es wahrscheinlich angemessen sein, ihre Verwendung in einer zukünftigen Version dieses BCP zu empfehlen.

Grund: SNI unterstützt die Bereitstellung mehrerer virtueller Server, die durch TLS auf einer einzigen Adresse geschützt sind, und ermöglicht daher eine feinkörnige Sicherheit für diese virtuellen Server, indem jedem ein eigenes Zertifikat zugewiesen werden kann. SNI gibt jedoch auch die Zieldomäne für eine bestimmte Verbindung preis; dieses Informationsleck wird durch die Verwendung von TLS Encrypted Client Hello geschlossen, sobald diese Methode standardisiert ist.

Um die in [ALPACA] beschriebenen Angriffe zu verhindern, SOLLTE ein Server, der den präsentierten Servernamen nicht erkennt, den Handshake NICHT fortsetzen und stattdessen mit einem fatalen Alarm unrecognized_name(112) fehlschlagen. Beachten Sie, dass diese Empfehlung Abschnitt 3 von [RFC6066] aktualisiert, der besagte:

| Wenn der Server die ClientHello-Erweiterung verstanden hat, aber den Servernamen nicht erkennt, SOLLTE der Server eine von zwei Maßnahmen ergreifen: entweder den Handshake durch Senden eines fatalen Alarms unrecognized_name(112) abbrechen oder den Handshake fortsetzen.

Clients SOLLTEN den Handshake abbrechen, wenn der Server die SNI-Erweiterung bestätigt, aber ein Zertifikat mit einem anderen Hostnamen als dem vom Client gesendeten präsentiert.

3.8. Application-Layer Protocol Negotiation (ALPN)

TLS-Implementierungen (sowohl Client- als auch Server-seitig) MÜSSEN die Erweiterung Application-Layer Protocol Negotiation (ALPN) [RFC7301] unterstützen.

Um Cross-Protocol-Angriffe zu verhindern, die daraus resultieren, dass nicht sichergestellt wird, dass eine Nachricht, die für die Verwendung in einem Protokoll bestimmt ist, nicht mit einer Nachricht verwechselt wird, die für die Verwendung in einem anderen Protokoll bestimmt ist, wird Servern geraten, das in Abschnitt 3.2 von [RFC7301] vorgeschriebene Verhalten strikt durchzusetzen:

| Für den Fall, dass der Server keines der vom Client angezeigten Protokolle unterstützt, MUSS der Server mit einem fatalen Alarm 'no_application_protocol' antworten.

Clients SOLLTEN den Handshake abbrechen, wenn der Server die ALPN-Erweiterung bestätigt, aber kein Protokoll aus der Liste des Clients auswählt. Wenn dies nicht geschieht, kann dies zu Angriffen wie den in [ALPACA] beschriebenen führen.

Protokollentwickler werden dringend ermutigt, eine ALPN-Kennung für ihre Protokolle zu registrieren. Dies gilt sowohl für neue Protokolle als auch für etablierte Protokolle; da letztere jedoch möglicherweise eine große installierte Basis haben, ist eine strikte Durchsetzung der ALPN-Nutzung möglicherweise nicht durchführbar, wenn eine ALPN-Kennung für ein etabliertes Protokoll registriert wird.

3.9. Multi-Server-Bereitstellung

Bereitstellungen mit mehreren Servern oder Diensten können die Größe der Angriffsfläche für TLS erhöhen. Zwei Szenarien sind von Interesse:

1. Bereitstellungen, bei denen mehrere Dienste denselben Domainnamen über verschiedene Protokolle verarbeiten (z. B. HTTP und IMAP). In diesem Fall könnte ein Angreifer möglicherweise einen Verbindungsendpunkt zu dem Dienst leiten, der ein anderes Protokoll anbietet, und einen Cross-Protocol-Angriff durchführen. Bei einem Cross-Protocol-Angriff glauben Client und Server, dass sie unterschiedliche Protokolle verwenden, was der Angreifer ausnutzen könnte, wenn im einen Protokoll gesendete Nachrichten im anderen Protokoll mit unerwünschten Effekten interpretiert werden (siehe [ALPACA] für detailliertere Informationen zu dieser Klasse von Angriffen). Um diese Bedrohung zu mindern, SOLLTEN Dienstanbieter ALPN bereitstellen (siehe Abschnitt 3.8). Darüber hinaus, wo möglich, SOLLTEN sie sicherstellen, dass mehrere Dienste, die denselben Domainnamen verwalten, gleichwertige Sicherheitsniveaus bieten, die den Empfehlungen dieses Dokuments entsprechen; solche Maßnahmen SOLLTEN die Behandlung von Konfigurationen über mehrere TLS-Server hinweg und Schutzmaßnahmen gegen die Kompromittierung von Anmeldeinformationen, die von diesen Servern gehalten werden, umfassen.

2. Bereitstellungen, bei denen mehrere Server denselben Dienst bereitstellen, aber unterschiedliche TLS-Konfigurationen haben. In diesem Fall könnte ein Angreifer möglicherweise einen Verbindungsendpunkt zu einem Server mit einer leichter ausnutzbaren TLS-Konfiguration leiten (siehe [DROWN] für detailliertere Informationen zu dieser Klasse von Angriffen). Um diese Bedrohung zu mindern, SOLLTEN Dienstanbieter sicherstellen, dass alle Server, die denselben Dienst bereitstellen, gleichwertige Sicherheitsniveaus bieten, die den Empfehlungen dieses Dokuments entsprechen.

3.10. Zero Round-Trip Time (0-RTT) Daten in TLS 1.3

Die Funktion für frühe 0-RTT-Daten ist neu in TLS 1.3. Sie bietet eine reduzierte Latenz bei der Wiederaufnahme von TLS-Verbindungen, potenziell auf Kosten einiger Sicherheitseigenschaften. Daher erfordert sie besondere Aufmerksamkeit von Implementierern sowohl auf der Server- als auch auf der Client-Seite. Im Allgemeinen erstreckt sich dies auf die TLS-Bibliothek sowie auf die darüber liegenden Protokollschichten.

Für HTTP über TLS, siehe [RFC8470] für Anleitungen.

Für QUIC über TLS, siehe Abschnitt 9.2 von [RFC9001].

Für andere Protokolle werden generische Anleitungen in Abschnitt 8 und Anhang E.5 von [RFC8446] gegeben. Um Anhang E.5 zu paraphrasieren: Anwendungen MÜSSEN diese Funktion vermeiden, es sei denn, es existiert eine explizite Spezifikation für das betreffende Anwendungsprotokoll, um zu klären, wann 0-RTT angemessen und sicher ist. Dies kann die Form eines IETF-RFC, eines Nicht-IETF-Standards oder einer Dokumentation zu einem Nicht-Standard-Protokoll annehmen.