Errori del certificato SSL nei portali captive

10

Situazione: ospiti dell'hotel che tentano l'accesso a Internet tramite il nostro portale captive. Problema: Google, Yahoo e ora sempre più siti reindirizzano tutte le home page su HTTPS in modo che l'ospite riceva un errore Certificato quando le reindirizziamo alla nostra pagina di accesso. Lo scopo apprezzato di SSL è quello di fare esattamente questo, ma mi chiedo se esiste un altro modo per gestire un processo di conferma dell'accesso guest per confermare la sua identità, prima di abilitare l'accesso attraverso il firewall. È fuori di testa gli ospiti che non capiscono. Fondamentalmente hanno bisogno di un'architettura diversa per un portale prigioniero / processo di autenticazione e mi chiedo quali pensieri ognuno abbia. Grazie.

ssl redirect

Possibile soluzione: WPA2-Enterprise con un server di autenticazione Radius.

— Ajedi32,

Questa non è una soluzione, ma per il momento i server come soluzione alternativa. Consentire agli utenti di accedere gratuitamente a HTTPS e al primo hit http, verranno reindirizzati man mano che l'industria si sposta sempre più su HTTPS, questo sarà obsoleto.

— Cusco,

6

L'intera definizione di "captive portal" ruota attorno a "reindirizzare l'utente a sua insaputa", che è esattamente una delle cose che SSL è stato creato per evitare.

Se il primo URL che il browser tenta di aprire è HTTPS, non è possibile reindirizzare il traffico senza creare un errore del certificato.

— Massimo
fonte

4

Sì, penso che l'OP lo capisca. La domanda era: qual è l'alternativa? (Ad esempio, se tutti i siti esistenti utilizzano HTTPS, come è possibile "gestire un processo di conferma

— dell'accesso

5

Il Chromium Project ha una buona pagina che descrive come funziona la sua logica per rilevare portali in cattività:

Tentativo di connessione (HTTP semplice) a un host + URI ben noto
Aspettarsi HTTP 204 No Content
Se si riceve una risposta diversa, supporre che sia un portale captive.

Ci sono altri dettagli nel link fornito riguardo al modo in cui gestiscono gli errori DNS quando provano a risolvere l'host ben noto, ecc. Questo è solo un esempio, ma (nella mia esperienza personale) i moderni sistemi operativi stanno usando processi simili a questo per rilevare e richiedere all'utente anche, in alcuni casi, prima che l'utente apra un browser. (Considerare: qualcuno che desidera utilizzare solo un client IMAP o un altro servizio non HTTP.) In tal caso, il rilevamento non avviene su SSL / TLS, quindi si evitano le preoccupazioni.

RFC 6585 Sezione 6 propone un nuovo codice di stato HTTP 511 Network Authentication Requiredche non aiuta il tuo caso SSL / TLS ma è un altro standard che potresti prendere in considerazione se non lo usi già.

— William Price
fonte

Android ha anche il supporto per il rilevamento di portali captive. Quando rileva un portale captive, visualizza un messaggio sulla barra di stato. Il testo è simile a "Accedi alla rete wireless". Ciò accade anche se nessuna applicazione ha ancora tentato di utilizzare la connessione. Ad un certo punto ho anche notato un portale captive che inviava un reindirizzamento 30x con un'intestazione HTTP aggiuntiva, indicando che si trattava di un portale captive e che il corpo conteneva alcuni dati XML. Non so se questo è un comportamento standard.

— Kasperd,

0

In ogni caso, se gli utenti ricevono un errore del certificato è perché il certificato non corrisponde al nome host del sito .

Nel tuo caso, ciò significa che stai reindirizzando gli utenti al tuo portale senza modificare l'URL. Gli utenti visualizzano " http://www.google.com " nella barra degli indirizzi ma il tuo portale nella schermata. Questi non corrispondono, ovviamente, e neanche il certificato.

È necessario reindirizzare loro in HTTP (HTTPS prima di saltare) al portale indirizzo (o il nome del server), sono loro il login in là, e quindi reindirizzare di nuovo alla destinazione prevista, che corrisponderà in modo corretto.

Vedi https://en.wikipedia.org/wiki/URL_redirection#HTTP_status_codes_3xx per come eseguirlo con i codici HTTP 3xx, in particolare 303.

— envite
fonte

La maggior parte degli utenti probabilmente non digita https:// , ma qualsiasi segnalibro memorizzato o altri meccanismi di blocco può comportare che la prima richiesta vada a un servizio basato su HTTPS e quindi non riesca perché l'handshaking TLS fallisce prima di raggiungere il livello del protocollo HTTP per un reindirizzamento. Oltre ai segnalibri, esempi di tale "blocco" includono la barra di ricerca di un browser con una conoscenza preliminare che il provider di ricerca preferisce le query tramite HTTPS; o un'app mobile che si connette a servizi di rete sicuri.

— William Price,

-1

soluzione temporanea è guidare gli utenti a iniziare l'URL che inizia con "http" solo dopo i segnali wifi collegati.

ma purtroppo agli utenti non piace. dicono "quanto complicato servizio wifi hai avuto"

— versi satu
fonte