1. Einführung

Transport Layer Security (TLS) und Datagram Transport Layer Security (DTLS) werden verwendet, um Daten zu schützen, die über eine Vielzahl von Anwendungsprotokollen ausgetauscht werden, darunter HTTP [RFC9112] [RFC9113], IMAP [RFC9051], Post Office Protocol (POP) [STD53], SIP [RFC3261], SMTP [RFC5321] und Extensible Messaging and Presence Protocol (XMPP) [RFC6120]. Solche Protokolle verwenden sowohl das TLS- oder DTLS-Handshake-Protokoll als auch die TLS- oder DTLS-Record-Layer. Obwohl das TLS-Handshake-Protokoll auch mit verschiedenen Record-Layern verwendet werden kann, um sichere Transportprotokolle zu definieren (das prominenteste Beispiel ist QUIC [RFC9000]), liegen solche Transportprotokolle nicht im direkten Geltungsbereich dieses Dokuments; dennoch können viele der hier enthaltenen Empfehlungen gelten, soweit solche Protokolle das TLS-Handshake-Protokoll verwenden.

In den Jahren bis 2015 war die Branche Zeuge schwerwiegender Angriffe auf TLS und DTLS, einschließlich Angriffen auf die am häufigsten verwendeten Cipher-Suites und ihre Betriebsarten. Zum Beispiel wurden die Verschlüsselungsalgorithmen AES-CBC [RFC3602] und RC4 [RFC7465], die einst die am weitesten verbreiteten Chiffren waren, im Kontext von TLS angegriffen. Detaillierte Informationen zu den vor 2015 bekannten Angriffen finden sich in einem Begleitdokument [RFC7457] zur früheren Version der TLS-Empfehlungen [RFC7525], das dem Leser hilft, die Gründe für die hier gegebenen Empfehlungen zu verstehen. Dieses Dokument wurde nicht im Einklang mit diesem aktualisiert; stattdessen werden neuere Angriffe in diesem Dokument beschrieben, ebenso wie Abhilfemaßnahmen für diese Angriffe.

Die TLS-Community hat auf die in [RFC7457] beschriebenen Angriffe auf verschiedene Weise reagiert:

• Es wurden detaillierte Anleitungen zur Verwendung von TLS 1.2 [RFC5246] und DTLS 1.2 [RFC6347] sowie älterer Versionen des Protokolls veröffentlicht. Diese Anleitung ist im ursprünglichen [RFC7525] enthalten und wird in dieser überarbeiteten Version weitgehend beibehalten; beachten Sie, dass diese Anleitung seit der Veröffentlichung von RFC 7525 im Jahr 2015 von der Branche weitgehend übernommen wurde.

• Versionen von TLS vor 1.2 wurden veraltet [RFC8996].

• Version 1.3 von TLS [RFC8446] wurde veröffentlicht, gefolgt von Version 1.3 von DTLS [RFC9147]; diese Versionen mildern oder lösen die beschriebenen Angriffe weitgehend.

Diejenigen, die TLS und TLS-basierte Protokolle implementieren und bereitstellen, benötigen Anleitungen, wie sie sicher verwendet werden können. Dieses Dokument bietet Anleitungen für bereitgestellte Dienste sowie für Softwareimplementierungen, unter der Annahme, dass der Implementierer erwartet, dass sein Code in den in Abschnitt 5 definierten Umgebungen bereitgestellt wird. In Bezug auf die Bereitstellung richtet sich dieses Dokument an ein breites Publikum, nämlich an alle Bereitsteller, die Authentifizierung (sei es einseitig oder gegenseitig), Vertraulichkeit und Datenintegritätsschutz zu ihrer Kommunikation hinzufügen möchten.

Die hier enthaltenen Empfehlungen berücksichtigen die Sicherheit verschiedener Mechanismen, ihre technische Reife und Interoperabilität sowie ihre Verbreitung in Implementierungen zum Zeitpunkt des Schreibens. Sofern nicht ausdrücklich angegeben ist, dass eine Empfehlung nur für TLS oder nur für DTLS gilt, gilt jede Empfehlung sowohl für TLS als auch für DTLS.

Dieses Dokument versucht, neue Anleitungen für TLS 1.2-Implementierungen zu minimieren, und der allgemeine Ansatz besteht darin, Systeme zu ermutigen, auf TLS 1.3 zu migrieren. Dies ist jedoch nicht immer praktikabel. Neu entdeckte Angriffe sowie Änderungen im Ökosystem haben einige neue Anforderungen erforderlich gemacht, die für TLS 1.2-Umgebungen gelten. Diese sind in Anhang A zusammengefasst.

Natürlich sind zukünftige Angriffe wahrscheinlich, und dieses Dokument kann sie nicht ansprechen. Diejenigen, die TLS/DTLS und TLS/DTLS-basierte Protokolle implementieren und bereitstellen, werden dringend gebeten, zukünftige Entwicklungen im Auge zu behalten. Insbesondere, obwohl bekannt ist, dass die Schaffung von Quantencomputern erhebliche Auswirkungen auf die Sicherheit kryptographischer Primitive und der Technologien haben wird, die sie verwenden, ist die Post-Quanten-Kryptographie derzeit ein laufendes Projekt und es ist zu früh, um Empfehlungen abzugeben; sobald relevante Spezifikationen in der IETF oder anderswo standardisiert sind, muss dieses Dokument aktualisiert werden, um die dann aktuellen besten Praktiken widerzuspiegeln.

Wie bereits erwähnt, behebt die TLS 1.3-Spezifikation viele der in diesem Dokument aufgeführten Schwachstellen. Ein System, das TLS 1.3 einsetzt, sollte weniger Schwachstellen aufweisen als TLS 1.2 oder niedriger. Daher ersetzt dieses Dokument [RFC7525] mit dem ausdrücklichen Ziel, die Migration der meisten Verwendungen von TLS 1.2 auf TLS 1.3 zu fördern.

Dies sind Mindestempfehlungen für die Verwendung von TLS in der überwiegenden Mehrheit der Implementierungs- und Bereitstellungsszenarien, mit Ausnahme von TLS ohne Authentifizierung (siehe Abschnitt 5). Andere Spezifikationen, die auf dieses Dokument verweisen, können strengere Anforderungen in Bezug auf einen oder mehrere Aspekte des Protokolls haben, abhängig von ihren besonderen Umständen (z. B. zur Verwendung mit einem bestimmten Anwendungsprotokoll); wenn dies der Fall ist, wird den Implementierern geraten, diese strengeren Anforderungen zu erfüllen. Darüber hinaus bietet dieses Dokument einen Boden, keine Decke: Wo immer möglich, werden Service-Administratoren ermutigt, über die in Implementierungen verfügbare Mindestunterstützung hinauszugehen, um die stärkstmögliche Sicherheit zu bieten. Beispielsweise könnte ein bestimmter Dienstanbieter aufgrund von Kenntnissen über die installierte Basis für ein bestehendes Anwendungsprotokoll und einer Kosten-Nutzen-Analyse hinsichtlich der Stärke der Sicherheit versus Interoperabilität entscheiden, TLS 1.2 vollständig zu deaktivieren und nur TLS 1.3 anzubieten.

Das Wissen der Community über die Stärke verschiedener Algorithmen und machbare Angriffe kann sich schnell ändern, und die Erfahrung zeigt, dass ein Best Current Practice (BCP)-Dokument zur Sicherheit eine Momentaufnahme ist. Leser werden auf Errata oder Aktualisierungen hingewiesen, die für dieses Dokument gelten.

Dieses Dokument aktualisiert [RFC5288] angesichts des [Boeck2016]-Angriffs. Siehe Abschnitt 7.2.1 für Details.

Dieses Dokument aktualisiert [RFC6066] angesichts des [ALPACA]-Angriffs. Siehe Abschnitt 3.7 für Details.