Captive Portal

Ein Captive Portal, deutsch etwa „unausweichliches Portal“ von englisch captive ‚gefangen‘, ist eine Einrichtung, die üblicherweise in öffentlichen drahtlosen Netzwerken eingesetzt wird, um den Zugriff von Endgeräten wie Laptops oder Smartphones auf das dahinter liegende Netzwerk oder das Internet an die Zustimmung des Nutzers an bestimmte Nutzungsregeln zu knüpfen. Zudem kann der Anbieter des Netzwerks den Zugang mit einem bestimmten Benutzerkonto verbinden, um so Verbindungskosten abzurechnen.

Eingesetzt werden Captive Portale vor allem in Bereichen mit häufig wechselnden Teilnehmern; dies können Gast-WLANs in Hotels sein, öffentliche WLAN-Hot-Spots in Städten oder WLANs in Transportmitteln wie Zug, Bus oder Flugzeug.

Bei einem Captive Portal kann ein Endgerät sich zunächst mit dem meist unverschlüsselten und ohne Zugangsdaten erreichbaren WLAN verbinden. In diesem Zustand wird vom Captive Portal allerdings jeder weitere Zugriff auf das dahinter liegende Netzwerk oder Internet blockiert, das Gerät ist quasi in diesem Bereich gefangen, wovon sich die Bezeichnung ableitet.

Üblicherweise werden in diesem Zustand Anfragen vom Webbrowser über HTTP zu einer Web-Seite des Captive Portals umgeleitet, wo der Benutzer seine Zustimmung zu bestimmten Regeln geben muss und weitere Angaben wie beispielsweise Benutzerkennung und Passwort für die Abrechnung eingibt. Erst nach erfolgter Zustimmung und ggf. positiver Authentifizierung erfolgt über das Captive Portal die Freigabe für den Netzwerk- oder Internetzugriff für dieses Endgerät. Je nach Konfiguration des Netzwerkes ist der Zugriff dann nicht nur auf HTTP beschränkt, sondern umfasst beispielsweise auch verschiedene andere Protokolle wie IMAP für die Abfrage von E-Mail oder auch VPN-Verbindungen.

Da die Freischaltung auf IP-Ebene basiert und oft verschiedene Protokolle zugelassen werden, werden freigeschaltete Endgeräte anhand ihrer jeweiligen MAC-Adresse zugeordnet. Je nach Konfiguration des Netzwerks können dabei die Freigaben zeitlich befristet erfolgen oder bestimmte MAC-Adressen können auch permanenten freien Zugang bekommen.

Obwohl Captive Portale in der Funktion seit ca. Anfang der 2000er Jahre bestehen, gab es bis Mitte 2015 keinen Standard für sie. Die Lösungen sind daher meist proprietäre Verfahren, welche im Prinzip auf Umleitungen und einem Man-in-the-Middle-Angriff basieren und zudem oft das Niveau eines Workarounds aufweisen. Durch den zunehmenden Einsatz von Verfahren, welche Man-in-the-Middle-Angriffe erschweren, sind diese Lösungen inzwischen mit verschiedenen praktischen Problemen behaftet.

Seit Ende 2015 steht mit RFC 7710^[1] ein RFC-Standard zur Verfügung (Stand 2022: Ersetzt durch RFC 8910^[2]), welcher herstellerübergreifend die Realisierung und Grundlage von Captive Portalen beschreibt. Dabei wird das zur Netzwerkkonfiguration des Endgeräts eingesetzte Protokoll DHCP um einen Eintrag (DHCP Option 114 (vormals 160)) erweitert, der ihm die URL des Captive Portals übergibt, die sodann per IPv4 oder IPv6 aufgerufen werden kann. Damit entfällt die bisher problematische Umleitung von Netzwerkzugriffen.

In den Jahren vor diesem RFC 7710^[1] sind verschiedene Verfahren genutzt worden, den beginnenden Netzwerkverkehr eines neuen Clients zunächst auf das Captive Portal umzuleiten, ohne dass dem Endgerät dies angezeigt wurde oder es Kenntnis darüber hatte. Diese griffen an verschiedenen im Folgenden beschriebenen Stellen ein.

Wenn ein nicht autorisiertes Endgerät eine beliebige Webseite anfordert, wird das DNS abgefragt und die IP-Adresse wie üblich aufgelöst. Der Browser schickt dann eine HTTP-Anfrage an diese IP-Adresse. Diese Anfrage wird durch eine Firewall abgefangen und an einen eigenen Umleitungsserver geschickt. Dieser beantwortet die Anfrage mit einer HTTP-Antwort, welche den Statuscode 302: Found enthält, um so auf die Captive-Portalseite umzuleiten. Für das Endgerät ist dieser Vorgang transparent, es muss davon ausgehen, dass die ursprünglich angefragte Webseite diese Umleitung gesendet hat, was hier nicht der Fall ist. Eine abgewandelte Methode besteht darin, den Statuscode 511: Network Authentication Required zu verwenden, welcher aber nicht von allen Webbrowsern verstanden wird.

Diese Art der Umleitung funktioniert nur bei nicht verschlüsseltem HTTP. Dazu kommt der Umstand, dass die Verwendung von HTTP zugunsten von HTTPS stetig abnimmt.

Bei dem mittels Transport Layer Security (TLS) verschlüsselten HTTPS kommt es bei dieser Umleitung zu einer Fehlermeldung, da das vom Captive Portal verwendete Zertifikat nicht für die vom Endgerät ursprünglich aufgerufene HTTPS-Adresse gültig ist. Im Prinzip entspricht die bei Captive Portalen eingesetzte Methode der Umleitung einem Man-in-the-Middle-Angriff. Durch die Signierung der eingesetzten TLS-Zertifikate durch eine vertrauenswürdige Stelle kann das Endgerät diese Manipulation der Umleitung erkennen und dem Anwender eine entsprechende Warnung anzeigen oder den Zugriff auf die Portalseite gänzlich unterbinden.

Aber auch wenn der Anwender eine HTTP-URL manuell eingibt, kann es bei zusätzlichen Schutzverfahren wie HTTP Strict Transport Security (HSTS) zu Problemen kommen: Bei HSTS erklärt ein Web-Server auf eine bestimmte Zeit von beispielsweise einem Jahr, keinen Zugriff mit unverschlüsselten HTTP auf diese Domain zu erlauben. Wurde die entsprechende Domain, welche HSTS verwendet, von dem Endgerät zuvor schon einmal aufgerufen, wird die Verwendung von HTTP für diese Adresse am Endgerät verhindert und das Captive Portal kann nicht angezeigt werden.^[3] Eine weitere Hürde für Captive Portale mit Umleitung ergibt sich bei Einsatz von HTTP Public Key Pinning (HPKP).

Wenn ein nicht-autorisiertes Endgerät eine Webseite anfordert, wird das DNS abgefragt. Die Firewall stellt sicher, dass nur ein DNS-Server erreichbar ist, der via DHCP vom Hot-Spot-Betreiber vorgegeben wird oder alternativ alle DNS-Anfragen auf einen solchen DNS-Server umleitet. Der DNS-Server wird auf jede Anfrage die IP-Adresse der Portalseite als Ergebnis zurückmelden. Diese Methode wird allerdings durch die Domain Name System Security Extensions (DNSSEC) unterbunden, da das Zertifikat nicht gültig ist und diese Umleitung als ein Man-in-the-Middle-Angriff erkannt wird.^[3]

Der Datenstrom kann auch durch IP-Umleitung auf der OSI-Schicht 3, mittels einer Redirect Message nach RFC 792,^[4] realisiert werden. Da der dargestellte Inhalt dann nicht mehr der URL entspricht, wird diese Methode durch TLS und DNSSEC als Man-in-the-Middle-Angriff erkannt.

Ohne Verwendung des in RFC 7710^[1] standardisierten Verfahrens besteht für das Endgerät keine Möglichkeit, die Anwesenheit eines Captive Portals zu erkennen. Betriebssystem-Hersteller etablierten daher eigene Server unter ihrer Kontrolle, auf die sie Endgeräte zugreifen lassen, sobald diese sich neu in einem Netz angemeldet haben. Der Erfolg dieses Zugriffs bescheinigt dem Betriebssystem die Abwesenheit eines Captive Portals im Netz des Endgerätes. Diese Routinezugriffe stellen ein Datenschutzproblem dar, der Hersteller kann IP-Adressen der Anwender speichern und ggf. auswerten.

Im Folgenden sind einige dieser zur Portalerkennung eingesetzten externen Serveradressen angeführt:

In Microsoft Windows gibt es den Network Connectivity Status Indicator (NCSI), welcher die Internetverbindung prüft und Captive Portale erkennt. Die entsprechenden Einstellungen sind in der Windows Registry unter HKLM:\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet hinterlegt.

In Windows 10 und 11 wird die DNS-Domäne dns.msftncsi.com abgefragt und die IPv4-Adresse 131.107.255.255 und die IPv6-Adresse fd3e:4f5a:5b81::1 erwartet. Anschließend wird eine DNS-Abfrage auf www.msftconnecttest.com durchgeführt und die Ressource http://www.msftconnecttest.com:80/connecttest.txt (zum Test der IPv4-Verbindung) und http://ipv6.msftconnecttest.com:80/connecttest.txt (zum Test der IPv6-Verbindung) abgefragt. Diese Ressourcen müssen aus der Zeichenfolge Microsoft Connect Test bestehen.

In älteren Windows-Versionen wird die Ressource http://www.msftncsi.com:80/ncsi.txt abgefragt, die aus der Zeichenfolge Microsoft NCSI bestehen muss.

Im Fall von Android gibt es den Captive Portal Check.

• Ab Android 4.4 (KitKat) wird die URL http://clients3.google.com/generate_204 abgerufen.
• Ab Android 6.0 (Marshmallow) wird die URL http://connectivitycheck.gstatic.com/generate_204 abgerufen.

Webbrowser wie Mozilla Firefox, Mozilla Thunderbird und SeaMonkey verwenden die URL http://detectportal.firefox.com/canonical.html^[5]. Die Erkennung von Captive Portalen kann in der about:config durch das Setzen des Schlüssels network.captive-portal-service.enabled auf false abgeschaltet werden.

Apple betreibt im gleichen Schema einen Server unter der URL http://captive.apple.com/, den Endgeräte beim Betreten von Netzwerken abzurufen versuchen; wenn dieser Abruf ein einfaches HTML-Dokument mit dem Wort Success (englisch für „Erfolg“) als einzigen Text enthält, dann schließt das Endgerät daraus, dass es Internet-Zugang hat, ansonsten wird ein Browser-Fenster geöffnet, damit der Nutzer die Webseite vom Captive Portal angezeigt bekommen.^[6] Eine Möglichkeit zur Deaktivierung dieser Funktion ist nicht bekannt und unter iOS nicht vorgesehen.

Auf der Filterung nach IP- oder MAC-Adresse basierende Implementierungen können auf WLAN-Seite relativ leicht umgangen werden, indem das Netzwerk mit einem Packet Sniffer belauscht und die dadurch ermittelten bereits freigeschalteten IP- und/oder MAC-Adressen anderer Teilnehmer nachfolgend mit dem Rechner des Angreifers imitiert werden.

Da der Zugang bei Captive Portalen im Regelfall über unverschlüsseltes WLAN erfolgt, können diese WLAN-Verbindungen in der Umgebung leicht abgehört werden. Verbindungen in einem unverschlüsselten WLAN sollten daher nur über sichere, verschlüsselte Verbindungen wie HTTPS oder unter Verwendung von VPN zu einem externen VPN-Server erfolgen.

1. ↑ ^{a b c} RFC 7710 – Captive-Portal Identification Using DHCP or Router Advertisements (RAs). Dezember 2015 (englisch).
2. ↑ RFC 8910 – Captive-Portal Identification in DHCP and Router Advertisements (RAs). September 2020 (englisch).
3. ↑ ^{a b} Hanno Böck: Captive Portale: Ein Workaround, der bald nicht mehr funktionieren wird. In: Golem.de. 8. Februar 2016, abgerufen am 26. Mai 2017. 
4. ↑ Jon Postel: RFC 792 – Internet Control Message Protocol. September 1981 (englisch).
5. ↑ „Captive Portal“-Erkennung. In: Hilfe zu Firefox. Abgerufen am 15. Oktober 2021. 
6. ↑ Ross Butler: Solving the Captive Portal Problem on iOS. In: medium.com. 16. November 2018, abgerufen am 18. Juli 2019 (englisch).