Erros de certificado SSL em portais cativos

10

Situação: os hóspedes do hotel tentam acessar a Internet através do nosso portal cativo. Problema: Google, Yahoo e agora mais e mais sites redirecionam todas as páginas iniciais para HTTPS, para que os hóspedes recebam um erro de certificado quando os redirecionamos para nossa página de logon. O objetivo apreciado do SSL é fazer exatamente isso, mas será que existe outra maneira de gerenciar um processo de confirmação de logon de convidado para confirmar sua identidade, antes de ativar o acesso através do firewall. É assustar os convidados que não entendem. Basicamente, precisa de uma arquitetura diferente para um processo de portal / autenticação cativo e se pergunta o que alguém pensa. Obrigado.

ssl redirect

Solução possível: WPA2-Enterprise com um servidor de autenticação Radius.

— Ajedi32

Esta não é uma solução, mas, por enquanto, os servidores são uma solução alternativa. Permita que os usuários acessem https livremente e, no primeiro acesso ao http, eles serão redirecionados à medida que o setor se move cada vez mais para https, o que será obsoleto.

— Cusco

6

Toda a definição de "portal cativo" gira em torno de "redirecionar o usuário sem seu conhecimento", que é exatamente uma das coisas que o SSL foi criado para evitar.

Se o primeiro URL que o navegador tenta abrir for HTTPS, não há como redirecionar o tráfego sem criar um erro de certificado.

— Massimo
fonte

4

Sim, acho que o OP entende isso. A pergunta era: qual é a alternativa? (Por exemplo, se todos os sites na existência utilizado HTTPS, como você pode "gerir um log convidado em processo de confirmação" sem um portal cativo?)

— Ajedi32

5

O Projeto Chromium tem uma boa página que descreve como sua lógica funciona para detectar portais cativos:

Tentativa de conexão (HTTP simples) a um host conhecido + URI
Espero HTTP 204 No Content
Se uma resposta diferente for recebida, assuma que seja um portal cativo.

Existem outros detalhes no link fornecido sobre como eles lidam com falhas de DNS ao tentar resolver o host conhecido, etc. Este é apenas um exemplo, mas (na minha experiência pessoal) os projetos modernos de sistemas operacionais estão usando processos semelhantes a esse para detectar e avise o usuário, mesmo em alguns casos, antes de abrir um navegador. (Considere: alguém que deseja usar apenas um cliente IMAP ou outro serviço não HTTP.) Nesse caso, a detecção não ocorre através de SSL / TLS, para que sua preocupação seja evitada.

A Seção 6 da RFC 6585 propõe um novo código de status HTTP 511 Network Authentication Requiredque não ajuda no seu caso SSL / TLS, mas é outro padrão que você pode considerar se ainda não o usar.

— William Price
fonte

O Android também tem suporte para detectar portais em cativeiro. Quando detecta um portal cativo, exibe uma mensagem na barra de status. A redação é algo como "Entrar na rede sem fio". Isso acontece mesmo que nenhum aplicativo tenha tentado usar a conexão ainda. Em algum momento, também notei um portal cativo enviando um redirecionamento 30x com um cabeçalho HTTP extra, indicando que era um portal cativo, e o corpo continha alguns dados XML. Não sei se isso é algum comportamento padrão.

— Kasperd

0

De qualquer forma, se os usuários receberem um erro de certificado, é porque o Certificado não corresponde ao nome do host do Site .

No seu caso, isso significa que você está redirecionando usuários para o seu portal sem alterar a URL. Os usuários veem " http://www.google.com " na barra de endereços, mas seu portal na tela. Obviamente, eles não correspondem e o certificado também não.

Você precisa redirecioná-los em HTTP (antes do salto HTTPS) para o endereço de portal (ou nome do servidor), fazer com que eles efetuem login lá e redirecioná-los novamente para o destino pretendido, que corresponderá corretamente.

Consulte https://en.wikipedia.org/wiki/URL_redirection#HTTP_status_codes_3xx para saber como executá-lo com códigos HTTP 3xx, especialmente 303.

— Envite
fonte

A maioria dos usuários provavelmente não digita https:// , mas qualquer marcador armazenado ou outro mecanismo de fixação pode resultar na primeira solicitação de acesso a um serviço baseado em HTTPS e, portanto, falhar porque o handshake TLS falha antes de atingir a camada de protocolo HTTP para redirecionar. Além dos marcadores, exemplos de "fixação" incluem uma barra de pesquisa do navegador com conhecimento prévio de que o provedor de pesquisa prefere consultas via HTTPS; ou um aplicativo móvel conectado a serviços de rede seguros.

— William Price

-1

Uma solução temporária é orientar os usuários a iniciar o URL começando com "http" somente após os sinais de wifi conectados.

mas, infelizmente, os usuários não gostam disso. eles dizem "quão complicado serviço wifi você tinha"

— versi satu
fonte