Appendix A. Design Rationale (Anhang A. Designbegründung)

Appendix A. Design Rationale (Designbegründung)

Die TLS-ALPN-Challenge existiert, um die in frühen ACME-Entwürfen definierte TLS-SNI-Challenge weiterzuentwickeln. Die TLS-SNI-Challenge war für Dienstanbieter praktisch, die entweder große TLS-Lastverteilungssysteme betrieben, an denen sie die Validierung durchführen wollten, oder Server mit sehr vielen DNS-Namen auf einem einzigen Host betrieben, da sie eine Validierung rein innerhalb der TLS-Schicht ermöglichte. Der Nutzen der TLS-SNI-Challenge wurde als groß genug erachtet, um dieses Dokument zu verfassen und einen neuen Challenge-Typ bereitzustellen, der die bestehenden Sicherheitsbedenken adressiert.

Ein Sicherheitsproblem in der TLS-SNI-Challenge wurde von Frans Rosen entdeckt; es erlaubte Nutzern verschiedener Dienstanbieter, widerrechtlich die Kontrolle über die DNS-Namen anderer Nutzer des Anbieters zu validieren. Bei der Entwicklung der TLS-SNI-Challenge wurde angenommen, dass ein Nutzer nur auf TLS-Datenverkehr über SNI für Domainnamen reagieren kann, die er beim Dienstanbieter registriert hat (d. h. wenn ein Nutzer a.example registrierte, konnte er nur auf SNI-Anfragen für a.example und nicht für b.example antworten). Es stellt sich heraus, dass eine Reihe großer Dienstanbieter diese Eigenschaft nicht einhalten. Dadurch konnten Nutzer auf SNI-Anfragen für die Namen antworten, die im Validierungsprozess der TLS-SNI-Challenge verwendet wurden. Das bedeutete: (1) Wenn Nutzer A und B jeweils Host A und Host B registriert hatten, konnte Nutzer A den konstruierten SNI-Challenge-Namen für Host B beanspruchen, und (2) wenn die Validierungsverbindung hergestellt wurde, konnte Nutzer A antworten und damit widerrechtlich die „Kontrolle“ über Host B beweisen. Da der verwendete SNI-Name eine Subdomain des zu validierenden Domainnamens war und nicht der Domainname selbst, war er wahrscheinlich noch nicht beim Dienstanbieter für das Traffic-Routing registriert, was ein Hijacking erleichterte.