7. Sicherheitserwägungen (Security Considerations)

7.1. Angeheftete Zertifikate (Pinned Certificates)

Wie in Abschnitt 1.8 definiert, wird ein Zertifikat als an einen DNS-Domänennamen "angeheftet" bezeichnet, wenn der Benutzer trotz der Tatsache, dass das Zertifikat andere DNS-Domänennamen enthält, explizit entschieden hat, das Zertifikat des Dienstes mit diesem DNS-Domänennamen zu assoziieren (z. B. hat ein Benutzer explizit "apps.example.net" als eine mit der Quelldomäne "example.com" verbundene Domäne genehmigt). Die zwischengespeicherte Namensassoziierung MUSS (MUST) sowohl das präsentierte Zertifikat als auch den Kontext berücksichtigen, in dem es akzeptiert oder konfiguriert wurde (wobei "Kontext" die Zertifikatskette vom präsentierten Zertifikat bis zum Vertrauensanker, die Quelldomäne, den Anwendungsdienst-Typ sowie die abgeleitete Domäne und Portnummer des Dienstes umfasst, sowie alle anderen relevanten Informationen, die vom Benutzer bereitgestellt oder vom Client assoziiert wurden).

7.2. Wildcard-Zertifikate (Wildcard Certificates)

Dieses Dokument legt fest, dass das Wildcard-Zeichen '*' NICHT in präsentierte Identifikatoren aufgenommen werden SOLLTE (SHOULD NOT), aber von Anwendungsclients überprüft werden KANN (MAY) (hauptsächlich für die Abwärtskompatibilität mit installierter Infrastruktur). Infolgedessen sind die in diesem Dokument bereitgestellten Regeln restriktiver als die Regeln vieler bestehender Anwendungstechnologien (wie diejenigen, die in Anhang B beschrieben sind). Mehrere Sicherheitserwägungen rechtfertigen die Verschärfung der Regeln:

Wildcard-Zertifikate bürgen automatisch für jeden einzelnen Hostnamen in ihrer Domäne. Dies kann für Administratoren bequem sein, birgt jedoch auch das Risiko, für bösartige oder fehlerhafte Hosts zu bürgen. Siehe z. B. [Defeating-SSL] (ab Folie 91) und [HTTPSbytes] (Folien 38-40).
Die Spezifikationen für bestehende Anwendungstechnologien sind nicht klar oder konsistent in Bezug auf die zulässigen Positionen für das Wildcard-Zeichen, z. B. ob es sein kann:
- Nur das vollständige linke Label (z. B. *.example.com)
- Ein Fragment des linken Labels (z. B. fo*.example.com, f*o.example.com oder *oo.example.com)
- Das Ganze oder ein Teil eines anderen als des linken Labels (z. B. www.*.example.com oder www.foo*.example.com)
- Das Ganze oder ein Teil eines Labels, das ein sogenanntes "Public Suffix" identifiziert (z. B. *.co.uk oder *.com)
- Mehr als einmal in einem gegebenen Label enthalten (z. B. fbr.example.com)
- Als Ganzes oder Teil von mehr als einem Label enthalten (z. B. ..example.com)
Diese Unklarheiten führen wahrscheinlich zu ausnutzbaren Abweichungen im Verhalten der Identitätsüberprüfung zwischen Client-Implementierungen und können übermäßig komplexe und ineffiziente Identitätsüberprüfungsalgorithmen erfordern.
Es gibt keine Spezifikation, die definiert, wie das Wildcard-Zeichen in ein A-Label oder U-Label [IDNA-DEFS] eines internationalisierten Domänennamens [IDNA-PROTO] eingebettet werden kann; folglich wird Implementierungen dringend davon abgeraten, eingebettete Wildcard-Zeichen in ein A-Label oder U-Label eines internationalisierten Domänennamens aufzunehmen oder zu versuchen, diese zu überprüfen (z. B. "xn--kcry6tjko*.example.org"). Beachten Sie jedoch, dass ein präsentierter Domänennamen-Identifikator das Wildcard-Zeichen enthalten KANN (MAY), solange dieses Zeichen die gesamte Position des linken Labels einnimmt, wenn alle verbleibenden Labels gültige NR-LDH-Labels, A-Labels oder U-Labels sind (z. B. "*.xn--kcry6tjko.example.org").

Ungeachtet der vorstehenden Sicherheitserwägungen kann eine Spezifikation, die diese Spezifikation wiederverwendet, die fortgesetzte Unterstützung des Wildcard-Zeichens legitimerweise fördern, wenn es gute Gründe dafür gibt, wie z. B. die Abwärtskompatibilität mit installierter Infrastruktur (siehe z. B. [EV-CERTS]).

7.3. Internationalisierte Domänennamen (Internationalized Domain Names)

Die Zulassung von internationalisierten Domänennamen kann zur Aufnahme von visuell ähnlichen (sogenannten "verwechselbaren") Zeichen in Zertifikate führen; für eine Diskussion siehe z. B. [IDNA-DEFS].

7.4. Mehrere Identifikatoren (Multiple Identifiers)

Ein gegebener Anwendungsdienst kann aus verschiedenen Gründen über mehrere DNS-Domänennamen adressiert werden, und eine gegebene Bereitstellung kann mehrere Domänen bedienen (z. B. in sogenannten "Virtual Hosting"-Umgebungen). Die Verwendung mehrerer Identifikatoren wird wie folgt gehandhabt:

Im Standard-TLS-Handshake-Austausch kann der Client den DNS-Domänennamen, mit dem er kommunizieren möchte, nicht angeben, und der TLS-Server gibt nur ein Zertifikat zurück, das sein eigenes ist. Ohne Erweiterungen für TLS ist die typische Problemumgehung zur Erleichterung der Zuordnung von Anwendungsdiensten zu mehreren DNS-Domänennamen das Einbetten aller Domänennamen in ein einziges Zertifikat.

Ein neuerer Ansatz (formalisiert in [TLS-EXT]) besteht darin, dass der Client den DNS-Domänennamen, den er für den Dienst erwartet oder wünscht, unter Verwendung der TLS "Server Name Indication" (SNI) Erweiterung beim Senden der client_hello-Nachricht angibt. Der Dienst kann dann das entsprechende Zertifikat in seiner Certificate-Nachricht zurückgeben, und dieses Zertifikat kann einen einzelnen DNS-Domänennamen darstellen.

Um die Problemumgehung zu berücksichtigen, die vor der Entwicklung der SNI-Erweiterung erforderlich war, erlaubt diese Spezifikation das Vorhandensein mehrerer DNS-IDs, SRV-IDs oder URI-IDs in einem Zertifikat; sie rät jedoch explizit von mehreren CN-IDs ab. Obwohl es wünschenswert wäre, mehrere CN-IDs vollständig zu verbieten, gibt es mehrere Gründe, warum diese Spezifikation derzeit vorschreibt, dass sie NICHT (SHOULD NOT) (anstatt NICHT DÜRFEN (MUST NOT)) aufgenommen werden sollten:

Mindestens eine bedeutende Gemeinschaft von technischem Interesse erlaubt explizit mehrere CN-IDs [EV-CERTS].
Mindestens eine bedeutende Zertifizierungsstelle ist dafür bekannt, Zertifikate auszustellen, die mehrere CN-IDs enthalten.
Viele Dienstanbieter halten es oft für notwendig, mehrere CN-IDs in Virtual-Hosting-Umgebungen aufzunehmen, da mindestens ein weit verbreitetes Betriebssystem die SNI-Erweiterung noch nicht unterstützt.

Es ist zu hoffen, dass die Empfehlung bezüglich mehrerer CN-IDs in Zukunft weiter verschärft wird.