3.1 Protocol Versions (Protokollversionen)

3.1.1 SSL/TLS Protocol Versions (SSL/TLS-Protokollversionen)

Es ist wichtig, sowohl die Verwendung alter, weniger sicherer Versionen von SSL/TLS zu beenden als auch moderne, sicherere Versionen zu verwenden; daher sind die folgenden Empfehlungen zu TLS/SSL-Protokollversionen zu beachten:

Implementierungen MÜSSEN SSL Version 2 NICHT verhandeln.

Begründung: Heutzutage wird SSLv2 als unsicher angesehen [RFC6176].
Implementierungen MÜSSEN SSL Version 3 NICHT verhandeln.

Begründung: SSLv3 [RFC6101] war eine Verbesserung gegenüber SSLv2 und stopfte einige bedeutende Sicherheitslücken, unterstützte jedoch keine starken Cipher-Suiten. SSLv3 unterstützt keine TLS-Erweiterungen, von denen einige (z.B. renegotiation_info [RFC5746]) sicherheitskritisch sind. Darüber hinaus wird SSLv3 mit dem Aufkommen des POODLE-Angriffs [POODLE] heute weithin als grundsätzlich unsicher anerkannt. Siehe [DEP-SSLv3] für weitere Details.
Implementierungen SOLLTEN TLS Version 1.0 [RFC2246] NICHT verhandeln; die einzige Ausnahme ist, wenn keine höhere Version in der Verhandlung verfügbar ist.

Begründung: TLS 1.0 (veröffentlicht 1999) unterstützt viele moderne, starke Cipher-Suiten nicht. Darüber hinaus fehlt TLS 1.0 ein per-record Initialization Vector (IV) für CBC-basierte Cipher-Suiten und warnt nicht vor häufigen Padding-Fehlern.
Implementierungen SOLLTEN TLS Version 1.1 [RFC4346] NICHT verhandeln; die einzige Ausnahme ist, wenn keine höhere Version in der Verhandlung verfügbar ist.

Begründung: TLS 1.1 (veröffentlicht 2006) ist eine Sicherheitsverbesserung gegenüber TLS 1.0, unterstützt jedoch immer noch bestimmte stärkere Cipher-Suiten nicht.
Implementierungen MÜSSEN TLS 1.2 [RFC5246] unterstützen und MÜSSEN bevorzugen, TLS Version 1.2 gegenüber früheren Versionen von TLS zu verhandeln.

Begründung: Mehrere stärkere Cipher-Suiten sind nur mit TLS 1.2 (veröffentlicht 2008) verfügbar. Tatsächlich sind die von diesem Dokument empfohlenen Cipher-Suiten (Abschnitt 4.2 unten) nur in TLS 1.2 verfügbar.

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

3.1.2 DTLS Protocol Versions (DTLS-Protokollversionen)

DTLS, eine Anpassung von TLS für UDP-Datagramme, wurde eingeführt, als TLS 1.1 veröffentlicht wurde. Die folgenden Empfehlungen gelten für DTLS:

Implementierungen SOLLTEN DTLS Version 1.0 [RFC4347] NICHT verhandeln.

Version 1.0 von DTLS korreliert mit Version 1.1 von TLS (siehe oben).
Implementierungen MÜSSEN DTLS Version 1.2 [RFC6347] unterstützen und MÜSSEN bevorzugen, diese zu verhandeln.

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

3.1.3 Fallback to Lower Versions (Rückfall auf niedrigere Versionen)

Clients, die nach Ablehnung höherer Versionen des Protokolls durch den Server auf niedrigere Versionen des Protokolls "zurückfallen", DÜRFEN NICHT auf SSLv3 oder früher zurückfallen.

Begründung: Einige Client-Implementierungen kehren zu niedrigeren Versionen von TLS oder sogar zu SSLv3 zurück, wenn der Server höhere Versionen des Protokolls ablehnt. Dieser Rückfall kann von einem Man-in-the-Middle (MITM) Angreifer erzwungen werden. TLS 1.0 und SSLv3 sind deutlich weniger sicher als TLS 1.2, die von diesem Dokument empfohlene Version. Während TLS 1.0-only Server noch recht häufig sind, zeigen IP-Scans, dass SSLv3-only Server nur etwa 3% der aktuellen Webserver-Population ausmachen. (Zum Zeitpunkt der Erstellung dieses Dokuments wurde kürzlich eine explizite Methode zur Verhinderung von Downgrade-Angriffen in [RFC7507] definiert.)