imported>Curtis Newton: Die letzte Textänderung von 2A02:3033:605:CE27:C51B:9B88:133C:A8D wurde verworfen und die Version 249814960 von Xenein wiederhergestellt.

2025-05-08T08:48:40Z

Die letzte Textänderung von 2A02:3033:605:CE27:C51B:9B88:133C:A8D wurde verworfen und die Version 249814960 von Xenein wiederhergestellt.

Neue Seite

Ein '''Captive Portal''', deutsch etwa „unausweichliches Portal“ von {{enS|captive|Audio=|IPA=|de=gefangen}}, ist eine Einrichtung, die üblicherweise in öffentlichen [[Wireless Local Area Network|drahtlosen]] Netzwerken eingesetzt wird, um den Zugriff von Endgeräten wie [[Notebook|Laptops]] oder [[Smartphone]]s 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 [[Hot Spot (WLAN)|WLAN-Hot-Spots]] in Städten oder WLANs in Transportmitteln wie Zug, Bus oder Flugzeug.

[[Datei:Captive Portal.png|mini|hochkant=2|Beispielseite eines Captive Portals]]

== Funktion ==
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 [[Hypertext Transfer Protocol|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 [[Internet Message Access Protocol|IMAP]] für die Abfrage von E-Mail oder auch [[Virtual Private Network|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.

== Implementierung ==
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 [[Workaround]]s 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 <nowiki>RFC 7710</nowiki><ref name="RFC7710" /> ein [[Request for Comments|RFC-Standard]] zur Verfügung (Stand 2022: Ersetzt durch <nowiki>RFC 8910</nowiki><ref>{{RFC-Internet |RFC=8910 |Titel=Captive-Portal Identification in DHCP and Router Advertisements (RAs) |Datum=2020-09}}</ref>), welcher herstellerübergreifend die Realisierung und Grundlage von Captive Portalen beschreibt. Dabei wird das zur Netzwerkkonfiguration des Endgeräts eingesetzte Protokoll [[Dynamic Host Configuration Protocol|DHCP]] um einen Eintrag (DHCP Option 114 (vormals 160)) erweitert, der ihm die [[Uniform Resource Locator|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 <nowiki>RFC 7710</nowiki><ref name="RFC7710" /> 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.

=== Umleitung via HTTP ===
Wenn ein nicht autorisiertes Endgerät eine beliebige Webseite anfordert, wird das [[Domain Name System|DNS]] abgefragt und die [[IP-Adresse]] wie üblich aufgelöst. Der Browser schickt dann eine [[Hypertext Transfer Protocol|HTTP]]-[[Client-Server-Modell|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-[[Client-Server-Modell|Antwort]], welche den Statuscode [[HTTP-Statuscode#code302|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 [[HTTP-Statuscode#code511|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 [[Hypertext Transfer Protocol Secure|HTTPS]] stetig abnimmt.

==== Probleme mit HTTPS ====
Bei dem mittels [[Transport Layer Security]] (TLS) verschlüsselten HTTPS kommt es bei dieser Umleitung zu einer Fehlermeldung, da das vom Captive Portal verwendete [[Digitales Zertifikat|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.<ref name="workaround" /> Eine weitere Hürde für Captive Portale mit Umleitung ergibt sich bei Einsatz von [[HTTP Public Key Pinning]] (HPKP).

=== Umleitung via DNS ===
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 [[Dynamic Host Configuration Protocol|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.<ref name="workaround" />

=== IP-Umleitung ===
Der Datenstrom kann auch durch IP-Umleitung auf der [[OSI-Modell#Schicht 3 – Vermittlungsschicht|OSI-Schicht 3]], mittels einer {{lang|en|Redirect Message}} nach <nowiki>RFC 792</nowiki>,<ref>{{RFC-Internet |RFC=792 |Titel=Internet Control Message Protocol |Datum=1981-09 |Autor=[[Jon Postel]]}}</ref> 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.

== Erkennung ==
Ohne Verwendung des in <nowiki>RFC 7710</nowiki><ref name="RFC7710" /> 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:

=== Windows ===
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 [[Registrierungsdatenbank|Windows Registry]] unter <code>HKLM:\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet</code> hinterlegt.

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

In älteren Windows-Versionen wird die Ressource <code style="white-space:nowrap"><nowiki>http://www.msftncsi.com:80/ncsi.txt</nowiki></code> abgefragt, die aus der Zeichenfolge <code style="white-space:nowrap">Microsoft NCSI</code> bestehen muss.

=== Android ===
Im Fall von [[Android (Betriebssystem)|Android]] gibt es den '''Captive Portal Check'''.

* Ab Android 4.4 (KitKat) wird die URL <code style="white-space:nowrap"><nowiki>http://clients3.google.com/generate_204</nowiki></code> abgerufen.
* Ab Android 6.0 (Marshmallow) wird die URL <code style="white-space:nowrap"><nowiki>http://connectivitycheck.gstatic.com/generate_204</nowiki></code> abgerufen.

=== Webbrowser und Mailclients ===
Webbrowser wie [[Mozilla Firefox]], [[Mozilla Thunderbird]] und [[SeaMonkey]] verwenden die URL <code style="white-space:nowrap"><nowiki>http://detectportal.firefox.com/canonical.html</nowiki></code><ref>{{Internetquelle |url=https://support.mozilla.org/de/kb/captive-portal-erkennung |titel=„Captive Portal“-Erkennung |werk=Hilfe zu Firefox |abruf=2021-10-15}}</ref>. Die Erkennung von Captive Portalen kann in der <code>about:config</code> durch das Setzen des Schlüssels <code>network.captive-portal-service.enabled</code> auf <code>false</code> abgeschaltet werden.

=== macOS und iOS ===
Apple betreibt im gleichen Schema einen Server unter der URL <code style="white-space:nowrap"><nowiki>http://captive.apple.com/</nowiki></code>, den Endgeräte beim Betreten von Netzwerken abzurufen versuchen; wenn dieser Abruf ein einfaches [[Hypertext Markup Language|HTML]]-Dokument mit dem Wort <code>Success</code> ({{enS}} 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.<ref>{{Internetquelle |autor=Ross Butler |url=https://medium.com/@rwbutler/solving-the-captive-portal-problem-on-ios-9a53ba2b381e |titel=Solving the Captive Portal Problem on iOS |werk=medium.com |datum=2018-11-16 |sprache=en |abruf=2019-07-18}}</ref> Eine Möglichkeit zur Deaktivierung dieser Funktion ist nicht bekannt und unter [[IOS (Betriebssystem)|iOS]] nicht vorgesehen.

== Einschränkungen ==
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.

== Einzelnachweise ==
<references>
<ref name="RFC7710">
{{RFC-Internet |RFC=7710 |Titel=Captive-Portal Identification Using DHCP or Router Advertisements (RAs)
|Datum=2015-12}}
</ref>
<ref name="workaround">
{{Internetquelle
|autor=Hanno Böck
|url=https://www.golem.de/news/captive-portals-ein-workaround-der-bald-nicht-mehr-funktionieren-wird-1602-118963.html
|titel=Captive Portale: Ein Workaround, der bald nicht mehr funktionieren wird
|werk=Golem.de
|datum=2016-02-08
|abruf=2017-05-26}}
</ref>
</references>

[[Kategorie:Authentifizierungstechnik]]
[[Kategorie:Internetzugang]]

Captive Portal - Versionsgeschichte

imported>Curtis Newton: Die letzte Textänderung von 2A02:3033:605:CE27:C51B:9B88:133C:A8D wurde verworfen und die Version 249814960 von Xenein wiederhergestellt.