7. Sicherheitsüberlegungen

Dieses gesamte Dokument erörtert Sicherheitspraktiken, die Anwendungen, die das TLS-Protokoll verwenden, direkt betreffen. Dieser Abschnitt enthält breitere Sicherheitsüberlegungen im Zusammenhang mit den Technologien, die in Verbindung mit oder von TLS verwendet werden. Der Leser wird auf die Abschnitte zu Sicherheitsüberlegungen von TLS 1.3 [RFC8446], DTLS 1.3 [RFC9147], TLS 1.2 [RFC5246] und DTLS 1.2 [RFC6347] für weiteren Kontext verwiesen.

7.1. Hostnamenvalidierung

Anwendungsautoren sollten beachten, dass einige TLS-Implementierungen keine Hostnamen validieren. Wenn die von ihnen verwendete TLS-Implementierung keine Hostnamen validiert, müssen Autoren möglicherweise ihren eigenen Validierungscode schreiben oder die Verwendung einer anderen TLS-Implementierung in Betracht ziehen.

Es ist anzumerken, dass die Anforderungen an die Hostnamenvalidierung (und im Allgemeinen an die Bindung zwischen der TLS-Schicht und dem darüber liegenden Protokoll) zwischen verschiedenen Protokollen variieren. Für HTTPS werden solche Anforderungen durch die Abschnitte 4.3.3, 4.3.4 und 4.3.5 von [RFC9110] definiert.

Die Hostnamenvalidierung ist sicherheitskritisch für alle gängigen TLS-Anwendungsfälle. Ohne sie stellt TLS sicher, dass das Zertifikat gültig ist und gewährleistet den Besitz des privaten Schlüssels, garantiert jedoch nicht, dass die Verbindung am gewünschten Endpunkt endet. Leser werden auf [RFC6125] verwiesen für Details zur generischen Hostnamenvalidierung im TLS-Kontext. Zusätzlich enthält dieser RFC eine lange Liste von Anwendungsprotokollen, von denen einige eine ganz andere Richtlinie als HTTPS implementieren.

Wenn der Hostname indirekt und unsicher entdeckt wird (z. B. durch eine Klartext-DNS-Abfrage für einen SRV- oder Mail Exchange (MX)-Eintrag), SOLLTE er selbst dann nicht als Referenzidentifikator [RFC6125] verwendet werden, wenn er mit dem präsentierten Zertifikat übereinstimmt. Diese Klausel gilt nicht, wenn der Hostname sicher entdeckt wird (für weitere Diskussionen siehe [RFC7673] und [RFC7672]).

Die Hostnamenvalidierung gilt typischerweise nur für das Blatt-"Endentitäts"-Zertifikat. Um eine ordnungsgemäße Authentifizierung im Kontext der PKI zu gewährleisten, müssen Anwendungsclients natürlich den vollständigen Zertifizierungspfad in Übereinstimmung mit [RFC5280] verifizieren.

7.2. AES-GCM

Abschnitt 4.2 empfiehlt die Verwendung des authentifizierten Verschlüsselungsalgorithmus AES-GCM. Bitte beachten Sie Abschnitt 6 von [RFC5288] für Sicherheitsüberlegungen, die speziell für AES-GCM gelten, wenn es mit TLS verwendet wird.

7.2.1. Nonce-Wiederverwendung in TLS 1.2

Die Existenz von bereitgestellten TLS-Stacks, die den AES-GCM-Nonce fälschlicherweise wiederverwenden, ist in [Boeck2016] dokumentiert, was zeigt, dass ein reales Risiko besteht, dass AES-GCM unsicher implementiert wird, wodurch TLS-Sitzungen, die eine AES-GCM-Cipher-Suite verwenden, anfällig für Angriffe wie [Joux2006] werden. (Siehe Datensätze [CVE]: CVE-2016-0270, CVE-2016-10213, CVE-2016-10212 und CVE-2017-5933.)

Obwohl dieses Problem in TLS 1.3 behoben wurde, das eine deterministische Methode zur Generierung von Nonces aus Datensatzsequenznummern und gemeinsamen Geheimnissen für alle seine AEAD-Cipher-Suites (einschließlich AES-GCM) erzwingt, könnten TLS 1.2-Implementierungen immer noch ihre eigenen (potenziell unsicheren) Nonce-Generierungsmethoden wählen.

Es wird daher EMPFOHLEN, dass TLS 1.2-Implementierungen die 64-Bit-Sequenznummer verwenden, um den nonce_explicit-Teil des GCM-Nonce zu füllen, wie in den ersten beiden Absätzen von Abschnitt 5.3 von [RFC8446] beschrieben. Diese stärkere Empfehlung aktualisiert Abschnitt 3 von [RFC5288], der spezifiziert, dass die Verwendung von 64-Bit-Sequenznummern zur Füllung des nonce_explicit-Feldes optional ist.

Wir stellen fest, dass zum Zeitpunkt des Schreibens keine Cipher-Suites für Algorithmen definiert sind, die gegen Nonce-Wiederverwendung resistent sind, wie AES-GCM-SIV [RFC8452].

7.3. Forward Secrecy

Forward Secrecy (auch "Perfect Forward Secrecy" oder "PFS" genannt und in [RFC4949] definiert) ist eine Verteidigung gegen einen Angreifer, der verschlüsselte Gespräche aufzeichnet, bei denen die Sitzungsschlüssel nur mit den langfristigen Schlüsseln der kommunizierenden Parteien verschlüsselt sind.

Sollte es dem Angreifer gelingen, diese langfristigen Schlüssel zu einem späteren Zeitpunkt zu erhalten, könnten die Sitzungsschlüssel und damit das gesamte Gespräch entschlüsselt werden.

Im Kontext von TLS und DTLS ist eine solche Kompromittierung langfristiger Schlüssel nicht völlig unplausibel. Sie kann beispielsweise auftreten aufgrund von:

• Einem Client oder Server, der durch einen anderen Angriffsvektor angegriffen wird und dessen privater Schlüssel abgerufen wird.

• Einem langfristigen Schlüssel, der von einem Gerät abgerufen wird, das verkauft oder anderweitig außer Betrieb genommen wurde, ohne vorher gelöscht zu werden.

• Einem langfristigen Schlüssel, der auf einem Gerät als Standardschlüssel verwendet wird [Heninger2012].

• Einem Schlüssel, der von einer vertrauenswürdigen dritten Partei wie einer CA generiert und später durch Erpressung oder Kompromittierung von ihr abgerufen wird [Soghoian2011].

• Einem kryptographischen Durchbruch oder der Verwendung von asymmetrischen Schlüsseln mit unzureichender Länge [Kleinjung2010].

• Social-Engineering-Angriffen gegen Systemadministratoren.

• Sammlung privater Schlüssel aus unzureichend geschützten Backups.

Forward Secrecy stellt in solchen Fällen sicher, dass es einem Angreifer nicht möglich ist, die Sitzungsschlüssel zu bestimmen, selbst wenn der Angreifer die langfristigen Schlüssel einige Zeit nach dem Gespräch erhalten hat. Es schützt auch gegen einen Angreifer, der im Besitz der langfristigen Schlüssel ist, aber während des Gesprächs passiv bleibt.

Forward Secrecy wird im Allgemeinen durch Verwendung des Diffie-Hellman-Schemas zur Ableitung von Sitzungsschlüsseln erreicht. Das Diffie-Hellman-Schema ermöglicht es beiden Parteien, private Geheimnisse zu bewahren und Parameter über das Netzwerk als modulare Potenzen über bestimmte zyklische Gruppen zu senden. Die Eigenschaften des sogenannten Diskreten Logarithmus-Problems (DLP) ermöglichen es den Parteien, die Sitzungsschlüssel abzuleiten, ohne dass ein Lauscher dies tun kann. Es gibt derzeit keinen bekannten Angriff gegen DLP, wenn ausreichend große Parameter gewählt werden. Eine Variante des Diffie-Hellman-Schemas verwendet elliptische Kurven anstelle der ursprünglich vorgeschlagenen modularen Arithmetik. Angesichts des aktuellen Stands der Technik scheint Elliptic Curve Diffie-Hellman effizienter zu sein, erlaubt kürzere Schlüssellängen und lässt weniger Spielraum für Implementierungsfehler als Finite-Field Diffie-Hellman.

Leider wurden viele TLS/DTLS-Cipher-Suites ohne Forward-Secrecy-Funktionalität definiert, z. B. TLS_RSA_WITH_AES_256_CBC_SHA256. Dieses Dokument befürwortet daher die strikte Verwendung von Chiffren nur mit Forward Secrecy.

7.4. Diffie-Hellman-Exponenten-Wiederverwendung

Aus Leistungsgründen ist es nicht ungewöhnlich, dass TLS-Implementierungen Diffie-Hellman- und Elliptic Curve Diffie-Hellman-Exponenten über mehrere Verbindungen hinweg wiederverwenden. Eine solche Wiederverwendung kann zu schweren Sicherheitsproblemen führen:

• Wenn Exponenten zu lange wiederverwendet werden (in einigen Fällen sogar nur wenige Stunden), kann ein Angreifer, der Zugriff auf den Host erhält, frühere Verbindungen entschlüsseln. Mit anderen Worten, Exponenten-Wiederverwendung negiert die Effekte von Forward Secrecy.

• TLS-Implementierungen, die Exponenten wiederverwenden, sollten den öffentlichen DH-Schlüssel, den sie erhalten, auf Gruppenmitgliedschaft testen, um einige bekannte Angriffe zu vermeiden. Diese Tests sind in TLS zum Zeitpunkt des Schreibens nicht standardisiert, obwohl allgemeine Anleitungen in diesem Bereich durch [NIST.SP.800-56A] bereitgestellt werden und in zahlreichen Protokollimplementierungen verfügbar sind.

• Unter bestimmten Bedingungen kann die Verwendung von statischen Finite-Field DH-Schlüsseln oder von ephemeren Finite-Field DH-Schlüsseln, die über mehrere Verbindungen hinweg wiederverwendet werden, zu Timing-Angriffen führen (wie die in [RACCOON] beschriebenen) auf die gemeinsamen Geheimnisse, die im Diffie-Hellman-Schlüsselaustausch verwendet werden.

• Ein Angriff mit "ungültiger Kurve" kann gegen Elliptic Curve DH durchgeführt werden, wenn das Opfer nicht verifiziert, dass der empfangene Punkt auf der richtigen Kurve liegt. Wenn das Opfer DH-Geheimnisse wiederverwendet, kann der Angreifer die Sondierung mit variierenden Punkten wiederholen, um das vollständige Geheimnis wiederherzustellen (siehe [Antipa2003] und [Jager2015]).

Um diese Bedenken auszuräumen:

• TLS-Implementierungen SOLLTEN keine statischen Finite-Field DH-Schlüssel verwenden und SOLLTEN ephemere Finite-Field DH-Schlüssel NICHT über mehrere Verbindungen hinweg wiederverwenden.

• Serverimplementierungen, die Elliptic Curve DH-Schlüssel wiederverwenden möchten, SOLLTEN entweder eine "sichere Kurve" [SAFECURVES] (z. B. X25519) verwenden oder die in [NIST.SP.800-56A] beschriebenen Überprüfungen an den empfangenen Punkten durchführen.

7.5. Zertifikatswiderruf

Die folgenden Überlegungen und Empfehlungen stellen den aktuellen Stand der Technik hinsichtlich des Zertifikatswiderrufs dar, auch wenn keine vollständige und effiziente Lösung für das Problem der Überprüfung des Widerrufsstatus gängiger Public-Key-Zertifikate [RFC5280] existiert:

• Zertifikatswiderruf ist ein wichtiges Werkzeug bei der Wiederherstellung nach Angriffen auf die TLS-Implementierung sowie in Fällen von falsch ausgestellten Zertifikaten. TLS-Implementierungen MÜSSEN eine Strategie implementieren, um widerrufenen Zertifikaten zu misstrauen.

• Obwohl Zertifikatswiderrufslisten (CRLs) der am weitesten verbreitete Mechanismus zur Verteilung von Widerrufsinformationen sind, weisen sie bekannte Skalierungsprobleme auf, die ihren Nutzen einschränken, trotz Workarounds wie partitionierten CRLs und Delta-CRLs. Das modernere [CRLite] und die Let's Revoke-Suite [LetsRevoke] bauen auf der Verfügbarkeit von Certificate Transparency-Protokollen [RFC9162] und aggressiver Komprimierung auf, um eine praktische Nutzung der CRL-Infrastruktur zu ermöglichen, aber zum Zeitpunkt des Schreibens wird keine der beiden Lösungen für die clientseitige Widerrufsverarbeitung im großen Maßstab eingesetzt.

• Proprietäre Mechanismen, die Widerrufslisten in die Webbrowser-Konfigurationsdatenbank einbetten, können nicht über die wenigen am häufigsten verwendeten Webserver hinaus skalieren.

• Das Online Certification Status Protocol (OCSP) [RFC6960] in seiner Grundform weist Skalierungs- und Datenschutzprobleme auf. Darüber hinaus "scheitern" Clients typischerweise "weich", was bedeutet, dass sie die TLS-Verbindung nicht abbrechen, wenn der OCSP-Server nicht antwortet. (Dies könnte jedoch ein Workaround sein, um Denial-of-Service-Angriffe zu vermeiden, wenn ein OCSP-Responder offline geschaltet wird.) Für eine aktuelle Untersuchung des Status der OCSP-Bereitstellung in der Web-PKI siehe [Chung18].

• Die TLS Certificate Status Request-Erweiterung (Abschnitt 8 von [RFC6066]), allgemein bekannt als "OCSP Stapling", löst die operativen Probleme mit OCSP. Sie ist jedoch in Gegenwart eines aktiven Angreifers auf dem Pfad immer noch ineffektiv, da der Angreifer die Anfrage des Clients nach einer gehefteten OCSP-Antwort einfach ignorieren kann.

• [RFC7633] definiert eine Zertifikatserweiterung, die anzeigt, dass Clients geheftete OCSP-Antworten für das Zertifikat erwarten müssen und den Handshake abbrechen müssen ("harter Fehler"), wenn eine solche Antwort nicht verfügbar ist.

• OCSP-Stapling, wie es in TLS 1.2 verwendet wird, erstreckt sich nicht auf Zwischenzertifikate innerhalb einer Zertifikatskette. Die Multiple Certificate Status-Erweiterung [RFC6961] behebt dieses Manko, hat aber wenig Verbreitung gefunden und wurde durch [RFC8446] veraltet. Daher wird diese Erweiterung, obwohl sie in [RFC7525] für TLS 1.2 empfohlen wurde, von diesem Dokument nicht mehr empfohlen.

• TLS 1.3 (Abschnitt 4.4.2.1 von [RFC8446]) ermöglicht die Verknüpfung von OCSP-Informationen mit Zwischenzertifikaten unter Verwendung einer Erweiterung der CertificateEntry-Struktur. Die Nutzung dieser Möglichkeit bleibt jedoch unpraktisch, da viele Zertifizierungsstellen (CAs) kein OCSP für CA-Zertifikate veröffentlichen oder OCSP-Berichte mit einer zu langen Lebensdauer veröffentlichen, um nützlich zu sein.

• Sowohl CRLs als auch OCSP hängen von einer relativ zuverlässigen Verbindung zum Internet ab, die für bestimmte Arten von Knoten möglicherweise nicht verfügbar ist. Ein häufiges Beispiel sind neu bereitgestellte Geräte, die eine sichere Verbindung herstellen müssen, um zum ersten Mal zu starten.

Für gängige Anwendungsfälle von Public-Key-Zertifikaten in TLS SOLLTEN Server Folgendes als Best Practice angesichts des aktuellen Stands der Technik und als Grundlage für eine mögliche zukünftige Lösung unterstützen: OCSP [RFC6960] und OCSP-Stapling unter Verwendung der in [RFC6066] definierten Erweiterung status_request. Beachten Sie, dass sich der genaue Mechanismus zur Einbindung der status_request-Erweiterung zwischen TLS 1.2 und 1.3 unterscheidet. Als Frage der lokalen Richtlinie KÖNNEN Serverbetreiber CAs bitten, Must-Staple-Zertifikate [RFC7633] für den Server und/oder für die Clientauthentifizierung auszustellen, aber wir empfehlen, die betrieblichen Bedingungen zu überprüfen, bevor Sie sich für diesen Ansatz entscheiden.

Die Überlegungen in diesem Abschnitt gelten nicht für Szenarien, in denen der DNS-Based Authentication of Named Entities (DANE) TLSA-Ressourcendatensatz [RFC6698] verwendet wird, um einem Client zu signalisieren, welches Zertifikat ein Server als gültig und gut für TLS-Verbindungen erachtet.