5. Security Considerations (Sicherheitsaspekte)

5. Security Considerations (Sicherheitsaspekte)

Das Design dieser Challenge basiert auf einigen Annahmen im Zusammenhang mit dem Verhalten eines HTTPS-Servers während der Validierung.

Die erste Annahme ist, dass ein HTTPS-Server, der Inhalte für mehrere DNS-Namen von einer einzigen IP-Adresse aus bereitstellt, die Kontrolle über diese Namen ordnungsgemäß den Benutzern zuordnet, die sie besitzen. Das bedeutet: Registriert Benutzer A Host A und Benutzer B Host B, sollte der HTTPS-Server nicht zulassen, dass eine TLS-Anfrage mit einem SNI-Wert für Host A von Benutzer B bedient wird oder eine TLS-Verbindung mit einer server_name-Erweiterung, die Host B identifiziert, von Benutzer A beantwortet wird. Wenn der HTTPS-Server Benutzer B erlaubt, diese Anfrage zu bedienen, kann dieser widerrechtlich die Kontrolle über Host A gegenüber dem ACME-Server validieren.

Die zweite Annahme ist, dass ein Server [RFC7301] nicht verletzt, indem er blind zustimmt, das Protokoll acme-tls/1 zu verwenden, ohne es tatsächlich zu verstehen.

Um das Risiko weiter zu mindern, dass Benutzer Domainnamen beanspruchen, die von anderen Benutzern auf derselben Infrastruktur genutzt werden, SOLLEN Hosting-Anbieter, CDNs und andere Dienstanbieter Benutzern nicht erlauben, eigene Zertifikate für den TLS-ALPN-Validierungsprozess bereitzustellen. Wenn Anbieter TLS-ALPN-Validation implementieren wollen, SOLLEN sie die für die Validation verwendeten Zertifikate nur selbst erzeugen und diese Funktionalität nicht für Benutzer freigeben.

Die in diesem Dokument beschriebenen Erweiterungen des ACME-Protokolls bauen auf den Sicherheitsüberlegungen und dem Bedrohungsmodell auf, die in Abschnitt 10.1 von [RFC8555] definiert sind.