Zusammenfassung

  • HTTP 511 meldet, dass ein Client zunächst eine Bedingung des Zugangsnetzes erfüllen muss. Der Status ist für einen abfangenden Proxy gedacht, nicht für den in der Anfrage genannten Ursprung.
  • Die Antwort soll auf eine getrennte Anmeldestelle verweisen, statt unter der Identität des Ursprungs nach Zugangsdaten zu fragen. Der Code begrenzt Verwechslungen, macht das Abfangen aber weder vertrauenswürdig noch mit fremdem TLS vereinbar.

In einer Antwort sprachen zwei verschiedene Instanzen

Sobald sich ein Gerät mit einem neuen Netz verbindet, fragen Wetter-App, Kalender und Aktualisierungsdienst wie gewohnt ihre Server ab. Ein Hotel- oder Flughafennetz kann die erste Anfrage jedoch anhalten und durch seine Nutzungsseite ersetzen. Für einen Menschen ist das vielleicht als WLAN-Anmeldung erkennbar. Für einen Hintergrundprozess sieht es so aus, als habe der angefragte Dienst plötzlich fremdes HTML geliefert.

Das Problem ist keine bloße Umleitung, sondern ein Konflikt der Zuständigkeit. Die URL benennt einen Ursprung; die Bytes stammen von einem Vermittler im Übertragungsweg. Ein Browser kann den Menschen um eine Entscheidung bitten. Ein API-Client kann die Seite als fehlerhafte Nutzdaten parsen, zwischenspeichern, wiederholt abrufen oder einer Umleitung folgen, ohne den Wechsel des Sprechers zu verstehen.

RFC 6585 führte 2012 511 Network Authentication Required ein, um diesen Eingriff genauer zu benennen. Der Status sagt: Für den Netzzugang fehlt eine Voraussetzung. Ebenso wichtig ist seine Absenderregel. Nicht der angefragte Ursprung soll ihn erzeugen, sondern ein abfangender Proxy, der den Zugang kontrolliert.

Netzzulassung und Anmeldung beim Dienst sind verschiedene Verträge

Das Wort „Authentifizierung“ verdeckt leicht zwei Beziehungen. Ein Webdienst kann ein Konto prüfen, bevor er eine Ressource freigibt. Ein Netz kann Zahlung, Zustimmung zu Bedingungen oder eine andere Interaktion verlangen, bevor es Verkehr weiterleitet. Aus der Fähigkeit, Pakete zu sperren, folgt kein Recht, im Namen des Ziels zu sprechen.

Deshalb soll ein Ursprungsserver laut RFC 6585 keinen 511 erzeugen. Die Anwendung verfügt über gewöhnliche HTTP-Mechanismen für Authentifizierung und Autorisierung. Der 511 bezeichnet eine Vorbedingung des Zugangswegs und zeigt dem Client, dass eine Reparatur seines Anwendungskontos das Problem wahrscheinlich nicht lösen wird.

Seine Beweiskraft bleibt begrenzt. Er kann einen Zulassungszustand melden. Er bestätigt weder die Seriosität des Portals noch die Angemessenheit seiner Bedingungen und identifiziert auch nicht die Person hinter dem Gerät.

Ein Verweis trennt Rollen, ein Formular vermischt sie

RFC 6585 empfiehlt, in der 511-Darstellung auf eine Ressource zu verlinken, an der die nötige Interaktion stattfinden kann. Die Darstellung selbst soll weder eine Authentifizierungsaufforderung noch die Anmeldemaske enthalten.

Ein Browser zeigt die Antwort im Zusammenhang mit der ursprünglich aufgerufenen URL. Erscheint dort ein Passwortfeld, kann es aussehen, als fordere die Zielwebsite das Geheimnis an. Auch eine Authentifizierungsaufforderung des Vermittlers kann fälschlich dem Ursprung zugerechnet werden.

Ein Link verschiebt die Handlung wenigstens auf einen eigenen Namen. Er ist noch kein Vertrauensbeweis: Der Client muss den tatsächlichen Hostnamen anzeigen, das TLS-Zertifikat prüfen und das Portal darf nur Daten verlangen, die es verarbeiten darf. 511 beschreibt eine Übergabe, keinen erfolgreichen Abschluss. Nach der Freischaltung muss der Client die ursprüngliche Anfrage erneut an den Ursprung senden.

Automatisierte Clients tragen die Kosten des Abfangens

RFC 6585 beschreibt 511 ausdrücklich als Schadensbegrenzung für Captive Portals, besonders gegenüber Programmen, die keine Browser sind. Das ist keine Empfehlung zur Interzeption.

Ein Aktualisierer hält Portal-HTML anstelle eines Manifests für beschädigte Metadaten. Ein Synchronisationsprogramm meldet einen falschen WebDAV-Fehler. Eine Umleitung beseitigt die Zuständigkeitsfrage nicht, denn die Software kann ihr folgen und die Portalausgabe weiterhin als Teil ihres ursprünglichen Arbeitsablaufs verarbeiten.

Je mehr Protokolle HTTP als Unterbau verwenden, desto mehr unbekannte Anwendungsgrenzen überschreitet eine pauschale Ersetzung. Ein eigener Status gibt robusten Clients wenigstens einen Grund, die Arbeit mit dem Ursprung auszusetzen, statt falsche Inhalte zu speichern, Zustände zu verändern oder blind weiterzuversuchen.

Ein Cache darf die Gefangenschaft nicht konservieren

511-Antworten dürfen nicht zwischengespeichert werden. Der Zustand gehört zu einem bestimmten Zugangsnetz, einer Zulassungssitzung und einem Zeitpunkt. Ein gespeicherter 511 könnte nach erfolgreicher Freischaltung fortbestehen oder das Gerät in ein anderes Netz begleiten. Er würde die Behauptung des Vermittlers erneut als Zustand des Ursprungs ausgeben.

Nur das aktuelle Durchsetzungssystem kann eine frische Zugangsentscheidung liefern. Ein Cache besitzt keine Befugnis, den Eingriff zu verlängern.

TLS legt die geliehene Identität offen

Bei unverschlüsseltem HTTP kann ein Vermittler die Antwort austauschen und 511 hinzufügen. Bei HTTPS authentisiert der Client zuerst den Servernamen über TLS. Das Portal hat kein Zertifikat für den gewünschten Ursprung und kann den Handshake nicht ehrlich abschließen. RFC 6585 weist deshalb auf den entstehenden Zertifikatsfehler hin.

511 kann nicht nach einer vertrauenswürdigen TLS-Verbindung erscheinen, die das Portal gar nicht herstellen konnte. Würde ein System die Zertifikatswarnung unterdrücken, um dennoch die Portalseite zu zeigen, verliehe es dem Netz genau die Ursprungsidentität, deren Verwechslung der Statuscode eingrenzen soll.

Das Risiko reicht weiter. Vermittler können ungeschütztes Authentifizierungsmaterial beobachten oder Cookies im Namensraum eines Ursprungs beeinflussen. RFC 6585 betont, dass diese Gefahren mit und ohne 511 bestehen. Eine präzisere Fehlermeldung reinigt keinen unsicheren Übertragungsweg.

Vom überraschenden Eingriff zum bereitgestellten Zustand

Die Captive Portal Architecture in RFC 8952 teilt die Aufgaben: Bereitstellung nennt dem Endgerät die Captive-Portal-API, die API meldet den Zustand, ein Benutzerportal führt die Interaktion, und eine Durchsetzungsinstanz sperrt oder erlaubt Verkehr. RFC 8908 definiert den HTTPS-Austausch mit der API.

Damit muss der Client nicht mehr eine unbeteiligte HTTP-Seite als Prüfmarke aufrufen und auf Manipulation warten. Beim Beitritt erhält er eine API-URI, validiert das Zertifikat des API-Servers und fragt seinen eigenen Zustand ab. Die Antwort enthält den obligatorischen Wahrheitswert captive und gegebenenfalls eine HTTPS-Adresse des Benutzerportals.

Nach der Interaktion fragt der Client erneut, ob die Sperre tatsächlich aufgehoben wurde. Ein abgesendetes Formular oder eine erfolgreiche Umleitung reicht nicht als Beweis. API und Durchsetzung müssen zudem dieselbe Endgeräteidentität meinen.

Die Architektur beseitigt alte Portale nicht sofort und stellt weiterhin Anforderungen an die Identitätsbindung. Sie verlegt die Aussage des Netzes jedoch auf einen Namen und einen Kanal, die ihm zustehen. Der Wetterdienst muss nicht länger zufällig als Entdeckungsfläche herhalten.

Die schmale Wahrheit, die 511 tragen kann

511 authentisiert kein Portal, legitimiert keine Interzeption, überwindet TLS nicht und beweist keine Zustimmung einer Person. Für einen Ursprung ist er kein Ersatz für 401 oder 403. Sein Beitrag ist kleiner und genauer: die Zulassungsforderung dem Zugangsnetz zuordnen und verhindern, dass sie wie wiederverwendbarer Ursprungsinhalt wirkt.

Die spätere API-Architektur führt denselben Grundsatz fort. Wer Macht ausübt, soll unter der eigenen Identität sprechen. Ein Netz darf Weiterleitung kontrollieren. Es muss nicht die Stimme des Ziels übernehmen, um diese Kontrolle zu erklären.

Quellen