Weiterleitungen sind doch ganz einfach, oder?

Nichts scheint problemloser zu funktionieren, als den Aufruf einer Webseite auf eine andere umzuleiten – einfach einen HTTP 302 senden, und schon ist es erledigt. Das klingt simpel, aber wie manches in der Welt der Captive Portals ist es bei näherem Hinsehen aber doch nicht ganz so einfach. Wir wollen daher einen genaueren Blick auf Weiterleitungen werfen.

Warum wollen wir User eigentlich umleiten?

Die Betreiber eines Internetzugangs, insbesondere wenn der Zugang kostenlos möglich ist, möchten Benutzer vor oder nach der Anmeldung auf beliebige Webseiten umleiten. Es gibt eine Menge verschiedener Anwendungsbeispiele, warum das gewünscht wird. Häufig sind die Ziele marketingtechnischer oder organisatorischer Natur, wie folgende:

• Hotels wollen Informationen zu Wetter, speziellen Angeboten, Wellness, Galamenüs etc. zeigen
• Restaurants, Cafés und Pubs wollen ihr Angebot darstellen
• Gästeportale stellen Informationen zu möglichen Aktivitäten in der Umgebung bereit
• Drittanbieter wollen Informationen wie einen Eventkalender anzeigen
• Vor der Anmeldung sollen Werbeinhalte gezeigt werden
• … und noch so manche andere.

Wann ist die Umleitung möglich?

Der Betreiber eines Captive Portals hat zwei Möglichkeiten, einen Benutzer umzuleiten:

1. Der Benutzer geht online und wird danach auf eine externe Seite weitergeleitet
2. oder der Benutzer wird offline auf die externe Seite weitergeleitet und erst danach online genommen.

Beide Methoden haben Schwächen, die man sich bewusst machen sollte.

1. Weiterleitungen nach der Anmeldung

Sehen wir uns zuerst die häufigste Art der Weiterleitung an. Der Gast hat sich, auf welche Art auch immer (Passwort, Facebook Anmeldung,…), im Netzwerk angemeldet und ist nun berechtigt, im Internet zu surfen. Jetzt sendet das Captive Portal eine Weiterleitung (HTTP 302). Die Seite erscheint… aber halt… wo ist der Browser hin? Der Captive Browser schließt auf vielen mobilen Geräten sofort, nachdem ein erfolgreicher Verbindungscheck gemacht wurde. Das trifft auf Millionen von Android-Geräten zu. Geräte von Apple iOS lassen die Captive Browser offen und bieten einen „Schließen“ Button. Da aber über 50 % aller mobilen Geräte auf Android basieren, sind Weiterleitungen nach der Anmeldung somit nicht wirklich sinnvoll.

Lesen Sie mehr über Verbindungschecks in unserem Blog Die Protokoll-Lücke bei Captive Portals.

2. Weiterleitung vor der Anmeldung

Da eine Weiterleitung vor der Anmeldung weit komplizierter ist, wird sie nicht von allen Captive Portals angeboten. Um diese Weiterleitungsmethode zu ermöglichen, muss das System eine so genannte Walled Garden Funktion haben, die es dem Benutzer ermöglicht, eine einzelne bestimmte Seite ohne komplette Online-Berechtigung zu besuchen. Auf der IACBOX nennen wir  diese Funktion Frei verfügbar Seiten. Sie basiert auf dem Whitelisting-Prinzip, man trägt die gewünschte(n) Seite(n) dort ein.

Früher waren Webseiten vollständig und isoliert ohne verlinkte Inhalte von anderen Seiten, somit kamen alle Dateien unverschlüsselt von einem Webserver unter einer Domain. Während es einfach ist, eine Domain auf eine Whitelist zu setzen, ist heutzutage eine typische Website verschlüsselt, hat sehr dynamischen Inhalt und eine Menge Inhalte von Fremd-Servern wie

• Widgets von sozialen Plattformen (z.B.: einen Facebook Like Button, Twitter Feed,…)
• Statische Dateien wie Schriftarten und Bilder
• Analyse/Tracking Dienst wie Google Analytics
• Werbemöglichkeiten
• und vieles mehr

Das führt zu folgenden Problemen:

• Große Plattformen wie Google oder Facebook antworten mit nahezu unendlich vielen Servern auf Anfragen auf ein und dieselbe Domain. Zum Beispiel hat ein DNS Eintrag wie www.google-analytics.com eine sehr kurze Lebensdauer von gerade einmal drei Minuten, bevor eine andere IP-Adresse geliefert wird. Viele Server-Farmen bieten auch mehr als eine IP-Adresse je Domain und das Gerät des Nutzers nimmt sich irgendeine davon (round-robin). Das bedeutet, dass wir Zugang zu einer Menge IP-Adressen ermöglichen müssen, zudem müssen sie regelmäßig aktualisiert werden.
• Aus Performance-Gründen verteilen Webseiten mit viel Datenverkehr ihren Inhalt mit Hilfe von CDNs (content delivery networks) mit dem gleichen Verfahren wie eben beschrieben.
• Eine gute Methode ist Whitelisting von unverschlüsselten Seiten. Da aber immer mehr Seiten verschlüsselt via HTTPS ausgegeben werden, muss mit IPs anstelle von Domains gearbeitet werden. Ein transparenter Proxy für TLS Traffic kann Probleme für Nicht-Web-Traffic bedeuten.
• Gibt man den Zugang zu großen Plattformen (Google, Facebook, Amazon Cloud,…) frei, gewährt man auch Zugang zu großen bzw. häufig genutzten Teilen des Internets.
• Ein zusätzliches Problem stellen dynamische Inhalte von Plattformen von Dritten dar: ein Walled Garden muss eine dynamische Auflösung von externen Links unterstützen, was in Zeiten von dynamisch generierten Javascript Webseiten nicht einfach bis unmöglich ist.