11. Sicherheitsüberlegungen

11.1. Sicherheitsüberlegungen zu server_name

Wenn ein Server Sicherheitsdomänen auf Namensebene implementiert, SOLLTE er Versuche von Clients, Namen in der falschen Sicherheitsdomäne aufzulösen, ordnungsgemäß behandeln. Eine Warnung SOLLTE NICHT verwendet werden; ein Server SOLLTE entweder die Verbindung mit einer geeigneten fatalen Warnung ablehnen oder mit der von ihm ausgewählten Sicherheitsdomäne fortfahren.

Beachten Sie, dass Servernamen in den server_name-Erweiterungen nicht durch den TLS-Handshake authentifiziert werden. Es gibt keine Garantie, dass der vom Client präsentierte Servername mit dem Namen im Serverzertifikat übereinstimmt, und es gibt keine Authentifizierung des Namens selbst. Anwendungen, die sich auf Serverauthentifizierung verlassen, MÜSSEN ihre eigenen Identitätsprüfungen (wie die in [RFC6125] beschriebenen) unter Verwendung des im Serverzertifikat präsentierten Namens durchführen.

Es kann Fälle geben, in denen ein Server mehrere Domänen hostet und es unangemessen wäre, dass eine Domäne erfährt, dass der Client versuchte, eine andere Domäne zu kontaktieren. In solchen Fällen kann es vorzuziehen sein, dass Server unabhängig vom Servernamen identisch reagieren; beispielsweise könnte ein Multi-Domänen-Server ein Zertifikat zurückgeben, das für alle von ihm gehosteten Domänen gültig ist, oder könnte in allen Fällen die gleiche Warnung zurückgeben. Dies verhindert, dass ein Beobachter bestimmen kann, welche der Domänen des Servers ein Client zu kontaktieren versuchte.

Es besteht ein Denial-of-Service-Risiko, wenn ein Server viele verschiedene Zertifikate basierend auf dem Servernamen aus der server_name-Erweiterung lädt. Der Server SOLLTE Mechanismen implementieren, um die durch die Verarbeitung der server_name-Erweiterung verursachte Last zu begrenzen, wie z. B. das Zwischenspeichern von Zertifikaten oder die Begrenzung der Anzahl verschiedener Zertifikate, die er lädt.

11.2. Sicherheitsüberlegungen zu max_fragment_length

Die Reduzierung der maximalen Fragmentgröße kann die Anfälligkeit für Seitenkanalangriffe erhöhen, da sie Informationen über das Verkehrsmuster offenbaren kann. Wenn beispielsweise eine Anwendung eine kleine Menge sensibler Daten sendet, könnten Angreifer möglicherweise die Datenmenge einfach durch Beobachtung der Anzahl der Fragmente ableiten.

Implementierungen SOLLTEN die Seitenkanalrisiken bei der Verhandlung reduzierter Fragmentgrößen berücksichtigen, insbesondere für Anwendungen, die sensible Daten verarbeiten.

Die Verhandlung kleinerer Fragmentgrößen kann Implementierungen auch Fragmentierungsangriffen aussetzen, bei denen ein Angreifer versucht, die Implementierung mit vielen kleinen Fragmenten zu überlasten. Implementierungen SOLLTEN angemessene Grenzen für die Anzahl der zu verarbeitenden Fragmente haben.

11.3. Sicherheitsüberlegungen zu client_certificate_url

Wenn Client-Zertifikat-URLs verwendet werden, erhält der Server die Zertifikate von einem externen Netzwerkstandort. Dies führt zu mehreren Sicherheitsrisiken:

URL-Spoofing-Angriffe: Ein Angreifer könnte URLs bereitstellen, die auf von ihm kontrollierte Zertifikate verweisen, was möglicherweise eine nicht autorisierte Authentifizierung ermöglicht. Server MÜSSEN:

• Validieren, dass das von der URL erhaltene Zertifikat von einer vertrauenswürdigen CA signiert ist.
• Alle von [RFC5246] geforderten Standard-Zertifikatsprüfungen durchführen.
• Validieren, dass der Client den privaten Schlüssel besitzt, der dem öffentlichen Schlüssel des Zertifikats entspricht (dies geschieht während des TLS-Handshakes).

Man-in-the-Middle-Angriffe: Wenn ein Angreifer die Kommunikation zwischen dem Server und der Zertifikat-URL abfangen oder modifizieren kann, könnte er ein anderes Zertifikat ersetzen. Um dieses Risiko zu mindern:

• Server SOLLTEN HTTPS verwenden, um Zertifikate von URLs abzurufen.
• Wenn ein Zertifikat-Hash bereitgestellt wird, MÜSSEN Server überprüfen, dass der Hash des erhaltenen Zertifikats mit dem bereitgestellten Hash übereinstimmt.

Denial-of-Service-Angriffe: Ein böswilliger Client könnte URLs bereitstellen, die:

• Auf Server verweisen, die langsam reagieren oder überhaupt nicht reagieren.
• Auf extrem große Ressourcen verweisen.
• Darauf ausgelegt sind, übermäßige serverseitige Verarbeitung zu verursachen.

Um diese Risiken zu mindern, SOLLTEN Server:

• Angemessene Zeitüberschreitungen für das URL-Abrufen implementieren.
• Die maximale Größe der abzurufenden Zertifikate begrenzen.
• Die Anzahl der durchzuführenden Abrufversuche begrenzen.
• Ratenbegrenzung für Zertifikatsabrufanfragen implementieren.

Datenschutzbedenken: Die Verwendung von Zertifikat-URLs offenbart dem Server, der die URL hostet, dass der Client versucht, sich bei einem bestimmten Dienst zu authentifizieren. Dies könnte die Verfolgung von Clientaktivitäten ermöglichen. Clients SOLLTEN diese Datenschutzimplikationen bei der Verwendung der client_certificate_url-Erweiterung berücksichtigen.

Offenlegung von Zertifikatsinformationen: Wenn Zertifikat-URLs ohne Authentifizierung öffentlich zugänglich sind, könnte dies Zertifikatsinformationen offenlegen, die privat sein sollten. Clients SOLLTEN überlegen, ob ihre Zertifikate sensible Informationen enthalten, und geeignete Hosting-Mechanismen wählen.

Hash-Replay-Angriffe: Wenn ein Server Zertifikate basierend auf Hashes zwischenspeichert, könnte ein Angreifer möglicherweise einen alten Hash wiederverwenden, wenn das zwischengespeicherte Zertifikat noch existiert. Zur Minderung:

• Server SOLLTEN angemessene Cache-Ablaufrichtlinien implementieren.
• Server MÜSSEN überprüfen, dass zwischengespeicherte Zertifikate noch gültig und nicht gesperrt sind.

11.4. Sicherheitsüberlegungen zu trusted_ca_keys

Die trusted_ca_keys-Erweiterung offenbart dem Server, welche Zertifizierungsstellen vom Client vertraut werden. Dies könnte Informationen über die Vertrauensumgebung des Clients offenbaren, die für Fingerprinting oder Profiling verwendet werden könnten.

Wenn ein Client eine lange Liste vertrauenswürdiger CAs bereitstellt, könnte dies außerdem:

• Ein Denial-of-Service-Risiko schaffen, indem es übermäßige serverseitige Verarbeitung verursacht.
• Informationen über die Geschäftspartner oder organisatorischen Beziehungen des Clients offenbaren.

Clients SOLLTEN sorgfältig überlegen, ob diese Erweiterung verwendet werden soll und, falls ja, welche CAs in die Liste aufgenommen werden sollen. Server SOLLTEN angemessene Grenzen für die Anzahl der zu verarbeitenden CAs implementieren.

11.5. Sicherheitsüberlegungen zu truncated_hmac

Die truncated_hmac-Erweiterung reduziert die MAC-Länge von 160 Bits (für SHA-1) auf 80 Bits. Dies reduziert erheblich die Sicherheitsstärke des MAC.

Ein 80-Bit-MAC bietet etwa 2^80 Operationen Widerstand gegen Brute-Force-Angriffe, was nach modernen Standards als marginal sicher gilt. Mit zunehmender Rechenleistung verringert sich diese Sicherheitsmarge.

Die folgenden Überlegungen gelten:

• Implementierungen SOLLTEN truncated_hmac NICHT für hochsichere Anwendungen verwenden.
• Die truncated_hmac-Erweiterung SOLLTE NUR verwendet werden, wenn Bandbreitenbeschränkungen erheblich sind und das reduzierte Sicherheitsrisiko akzeptabel ist.
• Auch mit verkürzten MACs gelten weiterhin alle anderen TLS-Sicherheitsüberlegungen.
• Implementierungen SOLLTEN die Verwendung von Cipher-Suiten mit nativ kürzeren MACs (wie solche mit AEAD-Chiffren) anstelle der Verwendung von truncated_hmac in Betracht ziehen.

Potenzielle Angriffe gegen verkürzte MACs umfassen:

Kollisionsangriffe: Bei einem 80-Bit-MAC hat ein Angreifer eine nicht vernachlässigbare Wahrscheinlichkeit (etwa 2^40 Versuche), eine Kollision unter Verwendung eines Geburtstagsangriffs zu finden. Das Ausnutzen einer MAC-Kollision in TLS würde jedoch erfordern, dass der Angreifer den Klartext manipulieren und die MACs beobachten kann, was im Allgemeinen schwierig ist.

Fälschungsangriffe: Ein Angreifer, der versucht, einen MAC zu fälschen, würde etwa 2^80 Versuche benötigen, was immer noch rechnerisch teuer, aber im Bereich des Möglichen für gut finanzierte Gegner ist.

Angesichts dieser Überlegungen sollte die Verwendung von truncated_hmac sorgfältig auf der Grundlage des Bedrohungsmodells der spezifischen Anwendung bewertet werden.

11.6. Sicherheitsüberlegungen zu status_request

Die Sicherheitsüberlegungen für die status_request-Erweiterung werden ausführlich in Abschnitt 8.4 diskutiert. Zu den Hauptpunkten gehören:

• Server können veraltete oder falsche OCSP-Antworten bereitstellen.
• Clients müssen empfangene OCSP-Antworten vollständig validieren.
• Kompromittierte Server könnten Statusinformationen für gesperrte Zertifikate weglassen.
• Die Erweiterung verbessert die Privatsphäre, indem vermieden wird, dass Clients OCSP-Responder direkt kontaktieren.

11.7. Allgemeine Sicherheitsüberlegungen

Erweiterungsverhandlung: Der Erweiterungsverhandlungsmechanismus selbst muss sicher sein. Angreifer sollten nicht in der Lage sein:

• Die Verwendung oder Nichtverwendung bestimmter Erweiterungen durch Unterdrückung oder Injektion von Nachrichten zu erzwingen.
• Sensible Informationen zu erfahren, indem sie beobachten, welche Erweiterungen verhandelt werden.

Der TLS-Handshake-Mechanismus schützt vor Änderung der Erweiterungsverhandlung über die Finished-Nachricht, die alle Handshake-Nachrichten einschließlich der Erweiterungen abdeckt.

Erweiterungsinkompatibilitäten: Clients und Server müssen Situationen ordnungsgemäß behandeln, in denen:

• Eine Erweiterung von einer Partei verstanden wird, aber nicht von der anderen.
• Verschiedene Versionen einer Erweiterung unterstützt werden.
• Widersprüchliche Erweiterungen angefordert werden.

Implementierungen SOLLTEN sicher fehlschlagen, wenn sie auf unverständliche oder widersprüchliche Erweiterungen stoßen.

Leistungs- und Sicherheitsüberlegungen: Einige Erweiterungen können Leistungsauswirkungen haben, die die Sicherheit beeinflussen. Zum Beispiel:

• Kleinere Fragmentgrößen können die Verarbeitungslast erhöhen.
• Das Abrufen von Zertifikaten von URLs kann Verzögerungen einführen.
• Die Verarbeitung großer Listen vertrauenswürdiger CAs kann Ressourcen verbrauchen.

Implementierungen SOLLTEN das Gleichgewicht zwischen Funktionsvorteilen und potenziellen Denial-of-Service-Risiken oder Leistungsverschlechterung berücksichtigen.

Datenschutzüberlegungen: Mehrere Erweiterungen offenbaren Informationen über den Client oder Server:

• server_name offenbart, welchen Server der Client zu kontaktieren versucht.
• trusted_ca_keys offenbart die Vertrauensumgebung des Clients.
• client_certificate_url kann die Aktivitäten des Clients dem Server offenbaren, der die URLs hostet.

Implementierungen SOLLTEN Benutzern ermöglichen, zu kontrollieren, welche Informationen durch diese Erweiterungen offenbart werden, insbesondere in Umgebungen, in denen Datenschutz ein Anliegen ist.

Zukünftige Erweiterbarkeit: Wenn neue Erweiterungen definiert werden, muss jede sorgfältig bewertet werden für:

• Die Sicherheitsimplikationen der Erweiterung selbst.
• Interaktionen mit bestehenden Erweiterungen.
• Auswirkungen auf das Gesamtsicherheitsmodell von TLS.

Ersteller neuer Erweiterungen SOLLTEN eine gründliche Sicherheitsanalyse in ihren Spezifikationen bereitstellen.