Ohne Zertifikat beweisen, wem ein Hostname gehört

Jedes Produkt, das einen Kunden einen Hostnamen eintippen lässt und ihn dann jede Minute prüft, hat zwei Dinge gebaut. Das erste ist Überwachung. Das zweite ist ein verteilter Anfragenerzeuger, gerichtet wohin der Kunde will, mit dem Namen Ihres Unternehmens im User-Agent und der Rechnungsadresse Ihres Kunden dahinter.

Der übliche Einwand lautet, das Ziel habe eine öffentliche Adresse, jeder könne ihm also ohnehin Verkehr schicken. Das stimmt, und darum geht es nicht. Eine öffentliche Adresse ist keine Erlaubnis, jemanden zu vermessen, und „das könnte jeder“ ist keine Verteidigung, die die erste Missbrauchsmeldung überlebt, besonders dann nicht, wenn der Verkehr regelmäßig und dauerhaft ist und von einer identifizierbaren kommerziellen Plattform ausgeht.

Ein Hostnamen-Ziel muss also verdient werden. Das ist der Entwurf, auf den wir uns festgelegt haben, einschließlich der Teile, die weniger offensichtlich sind, als sie aussehen.

Zwei Methoden, die Verschiedenes beweisen

Es gibt zwei praktikable Wege für jemanden, zu zeigen, dass ein Name ihm gehört, und es lohnt sich klarzustellen, dass sie nicht gleichwertig sind.

Ein DNS-TXT-Eintrag beweist die Kontrolle über die Zone. Wer dort einen Wert hinterlegen kann, entscheidet, wohin der Name zeigt, und das ist die stärkste Aussage über einen Namen, die es gibt.

Eine Datei auf dem Webserver beweist die Kontrolle über die Maschine, auf die der Name derzeit auflöst. Das ist schwächer: Auf gemeinsam genutztem Hosting können mehr Leute sie erzeugen, als die Zone bearbeiten können. Für einen Kunden, der einen Server hat, aber keinen Zugang zum DNS-Anbieter seines Arbeitgebers, ist sie zugleich viel besser erreichbar.

Das ist dasselbe Paar von Abwägungen, das Zertifizierungsstellen mit ihren beiden gängigen Challenge-Arten treffen, und es folgt derselbe Schluss: beide anbieten, festhalten, welche benutzt wurde, und nicht so tun, als hätten sie gleiches Gewicht.

Die Form der Challenge

Der TXT-Eintrag steht unter einem eigenen Label und nicht auf der Domain selbst. Das ist keine Ordnungsliebe. Ein Eintrag auf dem Apex landet neben den Einträgen zur Mailrichtlinie des Kunden, wo jede zusätzliche Zeichenfolge die Antwort näher an die Größe drückt, ab der Resolver einen schlechten Tag bekommen, und wo das Aufräumen „alter TXT-Einträge“ durch jemand anderen ihn ohne böse Absicht entfernt. Unter einem eigenen Label steht er allein.

Die Datei liegt unter einem reservierten Pfad mit dem Token als Dateinamen, und die Datei enthält den Token und sonst nichts.

Der Token selbst besteht aus zweiunddreißig hexadezimalen Zeichen, also einhundertachtundzwanzig Bit. Er ist kein Geheimnis und kein Schlüssel: Er wird im öffentlichen DNS oder auf einem öffentlichen Webserver stehen. Was er sein muss, ist nicht erratbar, denn wer einen gültigen Token vorhersagen kann, kann einen Namen beanspruchen, der ihm nicht gehört, indem er ihn zuerst auf seinem eigenen Server ablegt. Kleingeschriebenes Hex hält ihn sicher für einen DNS-Eintrag, sicher in einer URL und frei von Zeichen, die beim Abtippen durch einen Kunden verwechselt werden können.

Eine strukturelle Regel: Genau eine Stelle im Code schreibt die Challenge aus, und das Ergebnis reist mit der Anfrage zu demjenigen, der die Prüfung durchführt. Wüssten beide Seiten das Präfix unabhängig voneinander, käme irgendwann der Tag, an dem das Panel ein Label anzeigt und der Prüfer ein anderes nachschlägt, und die daraus entstehende Meldung lautet „der Eintrag ist nicht da“ über einen Eintrag, der da ist. Nichts ist im Support teurer als eine richtige Antwort auf eine Frage, die niemand gestellt hat.

Warum der Agent das Abrufen übernimmt

Das ist die Entscheidung, an der der Rest hängt.

Die Plattform löst den Namen nicht auf und ruft die Datei nicht ab. Täte sie es, würde unsere eigene Infrastruktur Verbindungen zu einem Namen aufbauen, den ein Benutzer eingetippt hat, und das ist serverseitige Anfragefälschung mit einem Formularfeld als Angriffsfläche. Das klassische Ergebnis ist eine Anfrage an einen Cloud-Metadaten-Endpunkt aus unserem eigenen Netz heraus, von uns gestellt, auf Wunsch.

Stattdessen tut es der eigene Agent des Kunden: derselbe Agent, der die Prüfungen danach ausführen wird, der im eigenen Netz des Kunden sitzt und sich ausschließlich nach außen verbindet. Über das Ergebnis zu lügen bringt nichts ein, denn die Belohnung ist die Erlaubnis, etwas zu messen, das der Agent ohnehin schon erreichen konnte. Die Verifikation wird von der Partei durchgeführt, die den Zugang bereits hat, und das ist die einzige Anordnung, in der der Anreiz zu schummeln verschwindet.

Es gibt eine Folge, die es wert ist, laut ausgesprochen zu werden, denn sie sieht wie eine fehlende Schutzmaßnahme aus. Anleitungen für diese Art von Funktion sagen üblicherweise, man solle private Bereiche, Loopback, Link-Local und Metadaten-Adressen sperren. Diese Regel gehört zu gehosteten Sonden, also zu Messpunkten, die wir betreiben und die in unserem Netz stehen. Für einen Agenten im eigenen Netz des Kunden sind private Adressen der Normalfall: sein Hypervisor, sein Switch, sein Speicher. Sie zu sperren würde die einzige Messquelle für genau die Lage abschalten, für die sie da ist.

Was beide Wege teilen, ist eine einzige Funktion, die entscheidet, welche Adressen zulässig sind. Hätten Verifikation und Messung je eine eigene Liste, käme ein Tag, an dem sie sich widersprechen, und an diesem Tag ist die eine ein Umweg um die andere.

Bei gemischten Antworten dichtmachen

Ein Name kann auf mehrere Adressen auflösen, und sie müssen nicht gleich annehmbar sein.

Wenn ein Name sowohl mit der öffentlichen Adresse des Kunden als auch mit einem Metadaten-Endpunkt antwortet, dann ist jede Ausführung eine neue Ziehung. Neun Durchläufe messen die öffentliche Adresse, und der zehnte spricht mit etwas ganz anderem. Die Anzahl der annehmbaren Antworten trägt also überhaupt keine Information: Eine verbotene Adresse in der Menge macht den ganzen Namen unbrauchbar, und dem Kunden wird gesagt, welche Adresse es war, denn eine Ablehnung, auf die er nicht reagieren kann, ist bloß eine Fehlermeldung.

Dasselbe gilt während der Verifikation und während der gewöhnlichen Prüfungen, was wiederum der Grund ist, warum es eine Adressrichtlinie gibt und nicht zwei.

Einzelheiten, die man nur im Betrieb lernt

Drei davon sind beim Bau des Prüfers entstanden; die vierte ist eine Entwurfsentscheidung, die zu ihnen gehört.

Mit „enthält“ vergleichen, nicht auf Gleichheit. Ein DNS-Anbieter darf einen TXT-Wert mit Anführungszeichen darum herum darstellen, und manche Bedienoberflächen fügen Anführungszeichen hinzu, die sie in ihrer eigenen Anzeige wieder entfernen. Der Token ist lang und undurchsichtig: Er ist entweder darin oder nicht, und auf einer genauen Übereinstimmung zu bestehen bestraft nur Kunden, die alles richtig gemacht haben.

Den Namen im Host-Header und im TLS-Servernamen senden. Die Verbindung geht an eine Adresse, die die Adressrichtlinie bereits bestanden hat, aber einem Webserver mit mehreren Seiten muss gesagt werden, nach welcher gefragt wird. Ohne beides scheitert ein richtig eingerichteter Kunde an der Verifikation, weil ihm die Standardseite von jemand anderem ausgeliefert wurde.

Genau eine Weiterleitung zulassen. Ein Webserver, der alles auf HTTPS schiebt, ist normal, und die Weiterleitung abzulehnen würde das halbe Internet scheitern lassen. Viele zuzulassen würde den Nachweis ganz woanders landen lassen. Ein Sprung, und nur zum selben Host.

Für die Datei-Challenge kein HTTPS verlangen. Der Nachweis ist der Token. Ein Zertifikat fügt ihm nichts hinzu, und eines zu verlangen macht aus einer Besitzprüfung eine Zertifikatsprüfung, was eine andere Frage mit anderen Fehlerbildern ist. Das ist dieselbe Überlegung, die hinter der einfachen HTTP-Challenge bei der Zertifikatsausstellung steht. Beachten Sie, dass dieser Standard nur für die Verifikation gilt: Wenn das Schema selbst das ist, was gemessen wird, würde es zu raten eine grüne Messung von etwas anderem erzeugen als dem, was der Kunde eingerichtet hat, und dort ist Ablehnen das richtige Verhalten.

Ein Nachweis läuft ab, weil Domains den Besitzer wechseln

Ein verifizierter Name sollte nicht für immer verifiziert bleiben, und der Grund ist keine Sorge um unsere eigenen Aufzeichnungen.

Domains wechseln den Besitzer, ohne dass es jemand mitteilt. Ein Kunde lässt eine Registrierung auslaufen, jemand anderes greift sie auf, und von diesem Moment an vermessen wir jede Minute die Maschine einer fremden Person, mit dem Namen unseres Kunden am Zeitplan. Niemand in dieser Kette hat etwas falsch gemacht, und das Ergebnis ist trotzdem nicht hinnehmbar.

Neunzig Tage ist die Gültigkeit, die wir gewählt haben, was in derselben Größenordnung liegt wie ein kurzlebiges Zertifikat und aus demselben Grund: kurz genug, dass ein Übergang schnell auffällt, lang genug, dass Kunden nicht jede Woche Papierkram erledigen. Die erneute Verifikation beginnt vierzehn Tage vor Ablauf, was bewusst großzügig ist, denn eine gescheiterte erneute Verifikation bedeutet meist, dass der Agent offline war oder ein Resolver langsam, und nicht, dass sich der Besitz geändert hat.

Versuche sind auf einen alle sechs Stunden begrenzt, nicht an das Überwachungsintervall gebunden. Eine Verifikation ist keine Messung: Sie sagt nichts über Verfügbarkeit, sie gehört nicht in eine Verfügbarkeitszahl, und häufiger zu fragen erzeugt nur Verkehr gegen das DNS des Kunden. Sechs Stunden über vierzehn Tage sind mehr als fünfzig Versuche, was aus „abgelaufen“ ein echtes Signal statt eines Pechs macht.

Die Zustände, die dabei herauskommen, sind ausstehend, verifiziert, ablaufend, abgelaufen und widerrufen, und einer davon ist kein Tor. Ablaufend gibt es, damit die Oberfläche jemanden warnen kann; ein Nachweis, der in zehn Tagen verfällt, ist heute gültig, und die Prüfungen laufen weiter. Ihn als eigenen Torzustand zu behandeln würde einem Kunden die Überwachung an einem Tag nehmen, an dem sich nichts geändert hat.

Die Datenbank erzwingt das Paar, statt dem Code zu vertrauen: Eine Zeile hat entweder eine Verifikationszeit und eine Ablaufzeit oder keine von beiden. Eine verifizierte Zeile ohne Ablauf ist eine dauerhafte Erlaubnis, die niemand gewählt hat, und genau das ist das, was dieser ganze Entwurf verhindern soll.

Was wir aufschreiben würden

1. 01Entscheiden, was die Challenge beweist, Kontrolle über die Zone oder über die Maschine, und festhalten, welche benutzt wurde.
2. 02Die Challenge unter ein eigenes Label setzen, nie auf den Apex neben die Mail-Einträge von jemandem.
3. 03Die Partei prüfen lassen, die den Zugang schon hat. Wenn Ihre Plattform einen vom Benutzer angegebenen Namen abruft, haben Sie eine Funktion zur Anfragefälschung gebaut.
4. 04Eine Adressrichtlinie für Verifikation und Messung. Zwei Listen werden zu zwei Verhaltensweisen.
5. 05Bei gemischten Antworten dichtmachen, und die störende Adresse in der Ablehnung benennen.
6. 06Dem Nachweis ein Ablaufdatum geben, und lange vorher mit der Erneuerung beginnen, denn der Fehlerfall, gegen den Sie sich absichern, ist seinem Wesen nach lautlos.

Zur Klarheit über unseren eigenen Stand: Das ist ein Entwurf, der als Code mit eigenen Tests existiert, Überwachung ist heute nichts, was Sie bei uns kaufen können, und nichts vom Obigen sollte als Produktankündigung gelesen werden. Es ist die Form, die wir wieder bauen würden.

Aus der Überwachungsarbeit an Provibr. Die verwandte Frage, wie man misst, ohne anzufassen, und wie viele Bytes eine Prüfung senden darf, steht in warum ein Scanner null Bytes senden sollte; wie ein Agent entscheidet, welchen von mehreren Messpunkten er nimmt, steht in wie ein Agent den richtigen Edge-Server wählt.