Die Protokoll-Lücke bei Captive Portals

In dieser Reihe möchten wir die Probleme aufzeigen, welche bei der Kommunikation zwischen Hotspots/Captive Portals und den Endgeräten auftreten. Der Laie mag denken, dass die Hersteller von Netzwerkhardware und Betriebssystemen sich schon vor langer Zeit diesem Problem angenommen und es sauber durch ein Netzwerk-Protokoll gelöst haben, doch das ist leider ein Irrtum. Es klafft eine mächtige Lücke in der Protokoll-Landschaft und die derzeit eingesetzten Lösungen verdienen mehr die Bezeichnung Workaround und nicht selten sogar dirty Hack.

Die Protokoll-Lücke

Derzeit gibt es kein Netzwerk-Protokoll, mit welchem ein Captive Portal mit dem Client kommunizieren kann. Es geht darum, dem Endgerät einfache Dinge mitzuteilen, wie z.B. dass eine Anmeldung nötig ist, bevor dieses Netzwerk benutzt werden kann. Im Enterprise-Bereich kann 802.1x diesen Part übernehmen, doch ist diese Technologie eher nur im Firmen-Bereich anzusiedeln, da sie zum einen nur die Anmeldung via Benutzername und Passwort und sonst keine der zahlreichen Szenarien abdeckt. Zum anderen sind viele Endbenutzer wie z.B. Hotelgäste mit einer WPA2-Enterprise Anmeldung überfordert und an dieser Stelle ist auch keine Online Hilfestellung möglich.

Das Weiterleitungs-Problem

Üblicherweise muss ein WLAN-Benutzer sich authentifizieren, ein Ticket kaufen, oder lediglich den Nutzungsbedingungen zustimmen, damit er das Netzwerk benutzen kann. Es gibt hier eine Vielzahl von Varianten, was aber nichts zur Sache tut – das Problem ist immer dasselbe. Der Benutzer möchte komfortabel, ohne spezielle Aktionen auf seinem Gerät auszuführen, auf die Anmeldeseite kommen. Weil es für diesen Ablauf keinen Standard gibt, müssen Captive Portals verschiedene, teils fragwürdige Manipulationen am Netzwerk-Verkehr vornehmen, um diese Funktionalität anbieten zu können.

Vor langer Zeit war es noch so, dass der Benutzer manuell den Webbrowser öffnen und eine beliebige unverschlüsselte Webseite (über HTTP) aufrufen musste, dann konnte das Captive Portal bequem via HTTP Response-Code 302 den Browser auf die Anmeldeseite umleiten.

Die Anzahl an verschlüsselten Webseiten mittels TLS steigt seit langem an, in letzter Zeit sogar stark. Was für das Internet und den Endbenutzer eine gute Sache ist, verhindert allerdings die Weiterleitung auf die Anmeldeseite. Wenn der Browser des Gastes eine verschlüsselte Seite via HTTPS aufruft, kann dieser nicht ohne Warnungen umgeleitet werden. In den wilden Tagen hatte man diese Weiterleitung dennoch einfach gemacht und darauf gehofft, dass der Gast die SSL/TLS Zertifikatswarnung einfach wegklickt. Mittlerweile halten es die meisten, zu recht, für grob fahrlässig, einem Laien ein Verhalten anzugewöhnen, das bei Internet-Banking und Online-Shops zu einem fatalen Problem werden könnte.

In den letzten Jahren wurden zu TLS ergänzende Standards implementiert, welche TLS noch sicherer (bzw. erst richtig sicher) machen, unter anderem

• HSTS (HTTP Strict Transport Security)
• und HPKP (HTTP Persistent Key Pinning).

HSTS ist eine Trust-on-first-use Erweiterung, die dem Browser mitteilt, dass diese Webseite nur via TLS aufgerufen werden soll, somit kein TLS-Striping gemacht werden kann (wie es leider bei STARTTLS für E-Mail immer noch der Fall ist). HPKP, ebenfalls Trust-on-first-use, teilt dem Browser einen Hash-Prüfwert des Zertifikats mit, somit kein anderes Zertifikat erlaubt ist, selbst wenn es gültig wäre (z.B. von einer Enterprise Firewall ausgestellt inkl. installierter CA auf dem Client).

Diese beiden Erweiterungen haben die praktische Auswirkung, dass der Gast eine Zertifikats-Warnung nicht mehr umgehen kann. Ohne Zweifel eine gute Sache für das Vertrauen in verschlüsselte Verbindungen. Aus diesen Gründen leitet die IACBOX seit längerem keine TLS Verbindungen mehr auf die Landingpage um.

Die Workarounds

Seit einigen Jahren besteht der Großteil der Geräte in einem Gäste-WLAN aus mobilen Geräten – somit wurde eine Lösung gebraucht. Die beiden großen Hersteller – Google und Apple – haben einen ähnlichen Workaround entwickelt. Es wird ein unverschlüsselter HTTP Aufruf einer Hersteller-spezifischen Seite gemacht und bei einer Umleitung (HTTP 302) ein Hotspot-System detektiert und ein minimalistischer Browser geöffnet. Somit wird das Problem mit verschlüsselten Browser-Startseiten umgangen und bietet zudem den Vorteil, dass der Benutzer den Browser nicht manuell öffnen muss, um die Anmeldeseite zu sehen. Allerdings bringt dieses Feature ein Datenschutz-Problem mit sich, was jedoch eine andere Geschichte ist.

Nicht nur mobile Geräte, sondern auch Betriebssysteme wie z.B. Windows ab Version 8 oder Browser wie aktuelle Firefox und Google Chrome Versionen führen diesen sogenannten Connectivity-Check durch.

Der Connectivity-Check war einerseits die Rettung für die schwierige Beziehung von Benutzern und Captive Portals, aber die unterschiedliche Herangehensweise und zum Teil undokumentierte interne Status machen den Prozess dennoch fragil.

WISPr

Dann gäbe es da noch WISPr, das eigentlich dazu gedacht ist, das Roaming zwischen 3/4G und WiFi Netzwerken zu erleichtern. Unter anderem definiert dieses Protokoll eine XML-Schnittstelle über HTTPS, über die das Endgerät die Information bekommt, dass es sich hinter einem Captive Portal befindet und wie die URL für die Landingpage lautet. Für Apple Geräte ist diese Antwort nötig, damit sich der Captive-Browser öffnet. Android und Windows ab Version 8 unterstützen WISPr zwar auch, doch funktioniert deren Connectivity-Check auch so. Aber auch WISPr löst das eigentliche Problem nicht, weil das Endgerät bereits diese Anfrage an das Captive-Portal (seinen Gateway) stellen muss.

Eine echte Lösung muss her

Ein Hoffungsschimmer am Horizont ist die neue IETF-Arbeitsgruppe capport [https://datatracker.ietf.org/wg/capport/about/], welche an neuen Protokollen, Erweiterungen bestehender Protokolle und Schnittstellen arbeitet, die es Endgeräten erlauben, auf eine standardisierte Weise mit einem Captive Portal zu kommunizieren. In dieser Blog-Reihe werden wir uns genauer mit den aktuellen Entwicklungen dieser Arbeitsgruppe beschäftigen.

Ein kleiner aber wichtiger Schritt ist schon gemacht – der Standard RFC-7710 [https://tools.ietf.orf/html/rfc7710], der eine DHCP-Option für Ipv4 und Ipv6 definiert, welche eine URL für eine Landingpage an den Client sendet. Die IACBOX unterstützt diese Option seit Anfang 2016, nur haben wir leider noch keine Geräte entdeckt, die diese Option auch honorieren.

Das offenbart auch das eigentliche Problem – ohne die Implementierung der Standards durch die Betriebssystem-Hersteller wird sich an der derzeitigen Lage nichts ändern.

Lesen Sie hier den zweiten Teil der Reihe Aktueller Status des capport RFCs.