Technische Umsetzung von Captive Portal Erkennung

Mir klar. Aber nur wenn man weiß, wie das umgesetzt wird, kann man auch beweisen, dass es KACKE ist.

1 „Gefällt mir“

Bei iOS Geräten wird nach dem verbinden mit einem WLAN captive.apple.com aufgerufen, wahrscheinlich handhabt Android das ähnlich.

2 „Gefällt mir“

Ah! Wenn das „Success“ liefert, dann wurde die Verbindung nicht entführt, und man kommt auch ohne einen Proxy aus. Jemand Lust mitzuschneiden, was Android macht?

Leere Seite anfordern http://clients3.google.com/generate_204 da gibts ja nen extra HTTP Statuscode für, wenn du entführt wirst, ist die Seite ja nicht mehr leer, ergo es wird mit einem anderen Statuscode geantwortet. Der Vorteil ist, dass man hier sogar mit einem HEAD Request arbeiten kann und sich somit nur den HTTP Header besorgt und auch nur diesen anschauen muss.

Siehe: https://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection

Bin mir nicht zu 100 % sicher, dass das exakt so in Android realisiert ist, aber die Hinweise deuten darauf hin.

Der Grund, warum es Kacke ist, ist einfach, dass es keinen Standard dafür gibt.

1 „Gefällt mir“

Cool! Dann brauch also nur jemand die Inhaber von http://clients3.google.com/generate_204 und http://captive.apple.com/ aufzufordern, da was passendes zu posten um die meisten mobilen Geräte auf dieser Welt glauben zu machen, dass sie offline sind?

Auch schön, bei Websperren via DNS, wie mal vorgeschlagen: den Service-Provider zwingen das DNS so zu manipulieren, das die Anfrage bei einem anderen Server landet, und eben nicht bei Apple oder Google.

Vorschaltseiten sind also der kleine Bruder von Manipulation im Großen. Willkommen in Uganda!

3 „Gefällt mir“