3.2 Strict TLS

3.2 Strict TLS

Die folgenden Empfehlungen werden bereitgestellt, um SSL Stripping zu verhindern (ein Angriff, der in Abschnitt 2.1 von [RFC7457] zusammengefasst wird):

• In Fällen, in denen ein Anwendungsprotokoll Implementierungen oder Einsätzen eine Wahl zwischen strikter TLS-Konfiguration und dynamischem Upgrade von unverschlüsseltem zu TLS-geschütztem Verkehr (wie STARTTLS) ermöglicht, SOLLTEN Clients und Server strikte TLS-Konfiguration bevorzugen.

• Anwendungsprotokolle bieten typischerweise eine Möglichkeit für den Server, TLS während eines anfänglichen Protokollaustauschs anzubieten, und manchmal auch eine Möglichkeit für den Server, Unterstützung für TLS anzukündigen (z.B. durch ein Flag, das anzeigt, dass TLS erforderlich ist); leider werden diese Hinweise gesendet, bevor der Kommunikationskanal verschlüsselt ist. Ein Client SOLLTE versuchen, TLS zu verhandeln, auch wenn diese Hinweise nicht vom Server kommuniziert werden.

• HTTP-Client- und Server-Implementierungen MÜSSEN den HTTP Strict Transport Security (HSTS) Header [RFC6797] unterstützen, um es Webservern zu ermöglichen, anzukündigen, dass sie bereit sind, nur TLS-Clients zu akzeptieren.

• Webserver SOLLTEN HSTS verwenden, um anzuzeigen, dass sie bereit sind, nur TLS-Clients zu akzeptieren, es sei denn, sie werden auf eine Weise eingesetzt, die 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).

Begründung: Die Kombination von ungeschützter und TLS-geschützter Kommunikation öffnet den Weg für 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.