Protokoll-Lücke wird geschlossen

Das ist der zweite Artikel in unserer Reihe Die Protokoll-Lücke. Im ersten Beitrag haben wir aufgezeigt, wie schwierig die Kommunikation zwischen den Endgeräten und dem Captive Portal ist, da es kein standardisiertes Verfahren dafür gibt. Falls Sie es noch nicht getan haben, empfehlen wir, zuerst den ersten Blogbeitrag zu diesem Thema zu lesen.

Definition des Problemraums

Bevor die IETF working group ihre Arbeit aufgenommen hat, wurde versucht, eine Problemdefinition zu erstellen, die erklärt, wofür Captive Portals sind, und welche Probleme sie mit sich bringen. Captive Portals werden verwendet, um Benutzer zu authentifizieren, die Allgemeinen Servicebedingungen, die Datenschutzerklärung (DSGVO) oder weitere Informationen bereit zu stellen oder verschiedene Bandbreiten pro Gerät zu erzwingen usw. Auch eine Statistik zum Nutzungsverhalten des WLANs könnte in diesem Zusammenhang für den Anbieter von Interesse sein. Und da es keinen standardisierten Weg gibt, das alles zu tun, müssen viele Workarounds und Manipulationen des Netzwerk-Verkehrs vorgenommen werden, die in unserem ersten Blogbeitrag dieser Serie beschrieben wurden.

Ein neuer Standard

Um dem entgegenzuwirken, möchte die Capport Arbeitsgruppe nun eine Ergänzung zu vorhandenen Protokollen (wie ICMP) und eine neue Schnittstelle (API) vorlegen, um eine standardisierte Art der Kommunikation bereitszustellen.

Dabei muss festgehalten werden, dass es sich dabei um einen unfertigen Entwurf dieses RFC handelt und den Stand von Januar 2019 darstellt.

Das folgende Diagramm zeigt die Interaktion zwischen den involvierten Parteien.

1. Das Gerät des Endbenutzers erhält via DHCP die grundlegenden Netzwerkeinstellungen wie IP, Subnetzmaske, Gateway, DNS Server usw. Es wird im Moment auch eine Variante mit PvD (Provisioning Domains) diskutiert. Das Gerät bekommt zusätzlich die URL des CAPPORT API Servers über eine neue DHCP Option (DHCP6 und RA für IPv6), die in dem bereits veröffentlichten RFC-7710 definiert ist (mit einer kleinen Änderung in RFC-7710bis).

2. Wenn das Gerät diesen neuen Standard nicht unterstützt, weiß es nicht, was es mit diesen DHCP Optionen (160) und dieser URL tun soll und wird beginnen, Verbindungen aufzubauen. Auch wenn das Gerät vom Captive-Portal offline genommen wurde, und dies nicht sofort erkennt, wird es weiterhin versuchen, Verbindungen aufzubauen.

3. Im Falle von Schritt 2 wird das Captive Portal eine ICMP-Nachricht verschicken, um dem Gerät des Endbenutzers mitzuteilen, dass es keinen Traffic senden darf. Geräte, die eine solche ICMP-Nachricht verstehen können, wissen, dass sie den CAPPORT API Server nach dem aktuellen Status fragen müssen. Andere Geräte werden diese Nachricht einfach ignorieren.

4. Das Gerät fragt den CAPPORT API Server nach den aktuellen Einschränkungen und bekommt auch eine optionale URL für eine Anmeldeseite, geeignet für Benutzer. Diese Seite kann ein Anmeldeformular, Zahlungsmodalitäten oder andere Informationen zeigen.

5. Wenn in Schritt 4. eine URL bereitgestellt wurde, öffnet das Gerät nun einen (Captive-) Browser und zeigt dem Benutzer die Anmeldeseite.

6. Sind schlussendlich die Anforderungen des Captive Portals vom Benutzer erfüllt, wird das Gerät online genommen und darf auf das Internet zugreifen.

Rückwärtskompatibilität

Wenn dieser neue Standard fertig entwickelt und auf den neuesten Versionen von Geräten und Betriebssystemen ausgerollt wurde, wird es noch über Jahre alte Geräte geben, mit denen keine Interaktion mit der CAPPORT API möglich sein wird. Das bisherige Verfahren (Umleiten des HTTP-Datenverkehrs von Offline-Usern) muss weiterhin unterstützt werden. Das aktuelle Dokument schlägt vor, die ICMP-Antworten dennoch zu senden, weil einerseits zunächst nicht klar ist, ob der Client in der Lage ist, die neue Schnittstelle zu verstehen, und andererseits ein Gerät / Betriebssystem eventuell sowohl den alten Connection-Check macht als auch versucht, auf die neue API zuzugreifen.

Warum ICMP?

ICMP war für uns die große Überraschung in diesem Entwurf – wir halten es dennoch für die richtige Wahl. Wenn einem Gerät der Netzwerkzugriff (bis jetzt) verwehrt bleibt, muss es darüber in Kenntnis gesetzt werden. Das Gerät öffnet jede Verbindung über IP und wird vom Captive Portal blockiert. Mit ICMP gibt es eine Möglichkeit, den Client zu benachrichtigen, ohne von einem bestimmten Protokoll auf höherer Ebene abhängig zu sein, wie der aktuell proprietäre Verbindungscheck über unverschlüsseltes HTTP. War zum Beispiel die erste Verbindung eines Geräts eine SMTP Verbindung zu einem Mail Server, kann das Captive Portal jetzt mit einer ICMP-Nachricht antworten und dem Gerät die Einschränkungen dadurch mitteilen.
Interessant an der ICMP-Benachrichtigung ist, dass sie keine URL zur Captive API enthält, da dies einfache Angriffe ermöglichen würde. Die URL für die API wird über die DHCP-Option (RFC-7710) übertragen. Natürlich ist auch DHCP nicht sicher und kann gefälscht werden, aber diese neuen Ergänzungen werden die Sicherheitsbarriere zumindest nicht senken.

Die CAPPORT Schnittstelle

Mit der CAPPORT API kann der Client über eine klassische HTTP Schnittstelle mit einem Captive Portal kommunizieren, welche JSON als Datenformat verwendet. Es ist notwendig, HTTPS (HTTP over TLS – ab Version 1.2) zu verwenden. Während das Gerät bereits weiß, dass es sich hinter einem Captive Portal befindet, möchte es jetzt den aktuellen Status und einige Details zur Eingeschränktheit des Netzwerks abrufen. Primär muss die Schnittstelle eine URL für die Anmeldeseite liefern, aber auch optionale andere Informationen.

Eine Beispielanfrage und -antwort könnte so aussehen:

GET/captive-portal/api/X54PD
Host: example.org
Accept: application/captive+json

Der Server antwortet daraufhin mit diesem JSON-Inhalt für diesen Client:

HTTP/1.1 200 OK
Cache-Control: private
Date: Mon, 04 Dec 2018 05:07:35 GMT
Content-Type: application/captive+json
{
     „permitted“: false,
     „user-portal-url“: „https://example.org/portal“
     „expire-date“: „2019-01-01T23:28:56. 782Z“
}

All dies ist natürlich ein Entwurf, aber es zeigt deutlich, was uns diese Schnittstelle bringen kann.

Online oder nicht?

Im Moment gibt es eine Debatte, ob das Captive Portal einem Gerät nur einen binären Zustand signalisieren kann – online oder offline – im Vergleich zu einer differenzierten Version, in der das Gerät erkennen kann, dass es auf bestimmte Ressourcen zugreifen darf (wie in einem Walled Garden), aber keine Verbindung zu anderen Servern im Internet herstellen kann. Wir würden ganz klar Letzteres bevorzugen, da Captive Portals hauptsächlich in Umgebungen mit vielen Einschränkungen verwendet werden.

Ausblick

Der aktuelle Stand sieht für uns als Hersteller vielversprechend aus und wir sind sehr daran interessiert, diese Schnittstelle zu implementieren, sobald es eine erste Version gibt. Die mangelnde Unterstützung von RFC-7710 hat gezeigt, dass es von den beiden großen Anbietern von mobilen Betriebssystemen – Google und Apple – abhängt, ob all dies eines Tages verwendet werden kann. Schaut man sich die Liste der E-Mail-Adressen der Teilnehmer der IETF-Arbeitsgruppe an, sieht es so aus, als ob Leute beider Unternehmen beteiligt wären, also können wir weiter hoffen.

Hier finden Sie das Update zu diesem Artikel.