Configurei o WebAuth em nosso Wi-Fi público. Temos um Cisco WLC 5508 e ao usar dispositivos iOS, Apple, Windows ou alguns dispositivos Android, a página carrega corretamente, porém quando estou usando um dispositivo com Chrome 53.0.2785.124 como navegador padrão no Marshmallow 6.0.1, recebo um página de erro indicando um possível ataque MTM. Ele lê "Sua conexão não é privada" seguido por algum outro texto e NET::ERR_CERT_COMMON_NAME_INVALID. Aqui está uma captura de tela do erro.
Pelo que entendi, isso ocorre porque o navegador está tentando acessar um URL e está esperando um resultado específico. No entanto, o certificado na página inicial google.com solicitada não corresponde ao certificado do host no wlc.mydomain.com retornado Certificado SSL.
Uma seção de www.google.com/chrome/browser/privacy/whitepaper.html diz:
Caso o Chrome detecte tempos limite de conexão SSL, erros de certificado ou outros problemas de rede que possam ser causados por um portal cativo (a rede Wi-Fi de um hotel, por exemplo), o Chrome fará uma solicitação sem cookie para http://www.gstatic. com/generate_204 e verifique o código de resposta. Se essa solicitação for redirecionada, o Chrome abrirá o destino de redirecionamento em uma nova guia, supondo que seja uma página de login. As solicitações para a página de detecção do portal cativo não são registradas.
Na verdade, está enviando uma solicitação para http://connectivitycheck.android.com/generate_204. O problema que vejo está na resposta do WLC, o código de status é HTTP 1.1 200 OK. Eu esperaria ver um erro devido ao bloqueio da página ou uma resposta 300 para indicar um redirecionamento. Com base no texto acima do Google, parece que o navegador entrará no modo Captive Portal (e abrirá uma nova guia para autenticação) QUANDO receber um redirecionamento.
Estou pensando que isso pode ser um problema com a configuração do WLC, mas talvez seja um problema com o Chrome 53 no Android.
Se alguém tiver uma solução recomendada, agradeço.
Atenciosamente, D.
Acontece que isso é um bug no Chrome.
Consulte o problema 662150
https://bugs.chromium.org/p/chromium/issues/detail?id=662150&can=2&start=0&num=100&q=&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS% 20Modificado&groupby=&sort=
O problema do guarda-chuva é 335933.
****Atualizar:
Nós realmente precisávamos disso para funcionar. O Google não está indo a lugar nenhum rapidamente para encontrar uma solução. Meu novo S7E possui um aplicativo de portal cativo integrado.
Eu estou supondo que outros fabricantes ainda terão problemas. Eu vi um paciente chegar com um tablet Lenovo que experimentou isso. Uma funcionária teve o mesmo com seu dispositivo Samsung mais antigo.
Eu vejo um grande número de pessoas sofrendo de dor portal cativa. Eu finalmente consegui resolver isso afundando o tráfego DNS para os FQDNs de teste do portal cativo.
Eu tentei primeiro no meu ASA deixar cair o tráfego com base no FQDN, mas como o tráfego é originado do WLC, não pude negar com base no VLAN.
Então, um hack de DNS.
No WLC, configurei 3 interfaces virtuais. 1 é interno. 2 é fornecedor e 3 é público. Cada um tem seu próprio escopo DHCP para que eu possa definir todas as suas opções específicas para sua situação única. 3 possui uma WLAN com o portal cativo associado a ela.
Eu configurei minha WLAN de fornecedor para usar servidores DNS públicos - não muito uso nessa WLAN.
Eu tenho dois servidores DNS de cache públicos executando CentOS com BIND 9; Eu os tranquei para minimizar a superfície de ataque. Eles são VMs em hosts ESXi com um NIC de cobre instalado em cada um que se conecta a um comutador virtual isolado e à minha rede DMZ. Não me custou um centavo.
Fiz isso porque alguns usuários (médicos visitantes) usam seus dispositivos pessoais e os conectamos ao fornecedor sem o portal cativo (eles se conectam uma vez e permanecem conectados - o convidado tem um limite de tempo e precisa aceitar a política de uso aceitável).
Adicionado a /etc/named.conf
zone "connectivitycheck.android.com" IN { type master; file "sinkhole.db"; };zone "clients3.google.com" IN { type master; file "sinkhole.db"; };/var/named/sinkhole.db
$TTL 600 @ IN SOA localhost root ( 5 ; serial 3h ; refresh 1h ; retry 1w ; expire 1h ) ; min TTL ; IN NS ns. * IN A 127.0.0.1 connectivitycheck.android.com. IN A 127.0.0.1 clients3.google.com. IN A 127.0.0.1Não é bonito, mas funciona muito bem. Espero que isto ajude alguém.