SSL-Zertifikatfehler in Captive-Portalen

10

Situation: Hotelgäste, die über unser Captive-Portal einen Internetzugang versuchen. Problem: Google, Yahoo und jetzt immer mehr Websites, die alle Startseiten zu HTTPS umleiten, sodass der Gast einen Zertifikatfehler erhält, wenn wir sie auf unsere Anmeldeseite umleiten. Der geschätzte Zweck von SSL besteht darin, genau dies zu tun. Fragen Sie sich jedoch, ob es eine andere Möglichkeit gibt, ein Gastprotokoll beim Bestätigungsprozess zu verwalten, um seine Identität zu bestätigen, bevor Sie den Zugriff über die Firewall aktivieren. Es sind verdammte Gäste, die nicht verstehen. Benötigen Sie grundsätzlich eine andere Architektur für einen Captive-Portal- / Authentifizierungsprozess und fragen Sie sich, welche Gedanken jemand hat. Vielen Dank.

ssl redirect

Mögliche Lösung: WPA2-Enterprise mit einem Radius-Authentifizierungsserver.

— Ajedi32

Dies ist keine Lösung, aber im Moment Server als Workaround. Ermöglichen Sie Benutzern den freien Zugriff auf https. Beim ersten http-Treffer werden sie umgeleitet, wenn die Industrie immer mehr zu https wechselt. Dies ist veraltet.

— Cusco

6

Die gesamte Definition von "Captive Portal" dreht sich um "Umleiten des Benutzers ohne sein Wissen". Dies ist genau eines der Dinge, die SSL vermeiden soll.

Wenn die erste URL, die der Browser zu öffnen versucht, eine HTTPS-URL ist, kann der Datenverkehr nicht umgeleitet werden, ohne dass ein Zertifikatfehler erstellt wird.

— Massimo
quelle

4

Ja, ich denke, das OP versteht das. Die Frage war: Was ist die Alternative? (ZB Wenn jede existierende Site HTTPS verwendet, wie könnten Sie "ein

— Gastprotokoll

5

Das Chromium-Projekt hat eine gute Seite, die beschreibt, wie ihre Logik zum Erkennen von Captive-Portalen funktioniert :

Versuchen Sie, eine Verbindung (einfaches HTTP) zu einem bekannten Host + URI herzustellen
Erwarten von HTTP 204 No Content
Wenn eine andere Antwort eingeht, wird davon ausgegangen, dass es sich um ein Captive-Portal handelt.

Der bereitgestellte Link enthält weitere Details zum Umgang mit DNS-Fehlern beim Versuch, den bekannten Host usw. zu beheben. Dies ist nur ein Beispiel, aber (nach meiner persönlichen Erfahrung) verwenden moderne Betriebssystemdesigns ähnliche Prozesse, um diese zu erkennen und fordern Sie den Benutzer in einigen Fällen sogar auf, bevor der Benutzer einen Browser öffnet. (Bedenken Sie: jemanden, der nur einen IMAP-Client oder einen anderen Nicht-HTTP-Dienst verwenden möchte.) In diesem Fall erfolgt die Erkennung nicht über SSL / TLS, sodass Ihre Bedenken vermieden werden.

RFC 6585 In Abschnitt 6 wird ein neuer HTTP-Statuscode vorgeschlagen 511 Network Authentication Required, der Ihrem SSL / TLS-Fall nicht hilft, aber ein weiterer Standard ist, den Sie in Betracht ziehen könnten, wenn Sie ihn nicht bereits verwenden.

— William Price
quelle

Android unterstützt auch die Erkennung von Captive-Portalen. Wenn ein Captive-Portal erkannt wird, wird in der Statusleiste eine Meldung angezeigt. Der Wortlaut ist so etwas wie "Anmelden im drahtlosen Netzwerk". Dies geschieht auch dann, wenn noch keine Anwendung versucht hat, die Verbindung zu verwenden. Irgendwann bemerkte ich auch ein Captive-Portal, das eine 30-fache Weiterleitung mit einem zusätzlichen HTTP-Header sendete, was darauf hinwies, dass es sich um ein Captive-Portal handelte und der Text einige XML-Daten enthielt. Ich weiß nicht, ob das ein Standardverhalten ist.

— Kasperd

0

Wenn die Benutzer einen Zertifikatfehler erhalten, liegt dies in jedem Fall daran, dass das Zertifikat nicht mit dem Hostnamen der Site übereinstimmt .

In Ihrem Fall bedeutet dies, dass Sie Benutzer zu Ihrem Portal umleiten, ohne die URL zu ändern. Die Benutzer sehen " http://www.google.com " in ihrer Adressleiste, aber Ihr Portal auf dem Bildschirm. Diese stimmen offensichtlich nicht überein und das Zertifikat auch nicht.

Sie müssen sie in HTTP (vor dem HTTPS-Sprung) an Ihre Portaladresse (oder Ihren Servernamen) umleiten, sie dort anmelden lassen und sie dann erneut an das beabsichtigte Ziel umleiten, das korrekt übereinstimmt.

Unter https://en.wikipedia.org/wiki/URL_redirection#HTTP_status_codes_3xx finden Sie Informationen zur Ausführung mit HTTP 3xx-Codes, insbesondere 303.

— Einladen
quelle

Die meisten Benutzer wahrscheinlich nicht geben https:// , aber alle gespeicherten Lesezeichen oder andere Pinning Mechanismen führen in die erste Anforderung HTTPS-basierten Dienst zu einem gehen und damit scheitern , weil TLS Handshake fehlschlägt , bevor die HTTP - Protokollschicht für eine Umleitung zu erreichen. Abgesehen von Lesezeichen umfassen Beispiele für ein solches "Fixieren" die Suchleiste eines Browsers mit dem Vorwissen, dass der Suchanbieter Abfragen über HTTPS bevorzugt; oder eine mobile App, die eine Verbindung zu sicheren Netzwerkdiensten herstellt.

— William Price

-1

Die temporäre Lösung besteht darin, Benutzer dazu zu führen, die URL erst nach "verbundenen" WLAN-Signalen mit "http" zu beginnen.

aber leider gefällt es den Benutzern nicht. Sie sagen: "Wie kompliziert war der WLAN-Service?"

— versi satu
quelle