Eu ainda acho que tem algo que passa desapercebido. Pois uso hotspot desde 2008 e quando começou a aparecer https nós não fizemos nada. Simplesmente continuou abrindo normalmente e fazendo login no hotspot normalmente.
Nunca ativei certificado.
Versão Imprimível
Eu ainda acho que tem algo que passa desapercebido. Pois uso hotspot desde 2008 e quando começou a aparecer https nós não fizemos nada. Simplesmente continuou abrindo normalmente e fazendo login no hotspot normalmente.
Nunca ativei certificado.
Não é um problema do Hotspot. Isso também ocorre com páginas de bloqueio/aviso: tente acessar algum site HTTPS enquanto o cliente está bloqueado, com um DSTNAT redirecionando ele para alguma página de aviso... o resultado vai ser o mesmo com Hotspot, PPPoE ou qualquer outra coisa que você faça.
Entenda:
O cliente tenta acessar https://www.google.com.br, por exemplo, então o navegador inicia uma conexão TCP com o servidor para o qual www.google.com.br aponta e logo começa o handshake TLS/SSL.
1) Se um DSTNAT redireciona o cliente para um servidor HTTP, seja para página de aviso, bloqueio ou login do Hotspot, o handshake vai falhar, porque esse servidor não vai responder à negociação SSL/TLS e receberá um monte de dados desconhecidos, sendo que ele esperava uma requisição HTTP.
2) Se um DSTNAT redireciona o cliente para um servidor HTTPS (ou seja, você configura lá seu certificado válido no Hotspot ou até nas páginas de aviso do seu MK-Auth ou qualquer outro sistema), de cara o SNI, que é basicamente a informação do hostname com o qual o cliente está tentando se comunicar, não vai bater com nenhum certificado que o servidor tem para apresentar e o handshake vai falhar. Mesmo que você gere certificados falsos (para www.google.com.br, por exemplo) para cada SNI apresentando, igual algumas soluções de cache fazem, esse certificado não estará assinado por uma Autoridade Certificadora (CA) reconhecida (porque você nunca vai conseguir comprar um certificado para um hostname que não é seu), então ocorrerá aquele erro de segurança no navegador, onde você até pode ignorar e a página de login/aviso/bloqueio/etc. vai ser apresentada. Ou pode fazer a mesma coisa que servidores de cache que tentam interceptar HTTPS: instale no navegador de cada dispositivo do cliente a sua CA privada, para que eles confiem nos certificados gerados por ela. Já viu que não são soluções interessantes, para não chamar de gambiarras, né?
Esse comportamento não é um problema de fato. SSL/TLS foi projetado assim justamente para impedir interceptações. Não importa se está interceptando apenas para mostrar uma página de login, aviso ou bloqueio, é isso que essas camadas de segurança impedem porque a mesma tática poderia ser usada para fins maliciosos.
Talvez a maioria de seus clientes estejam com navegadores desatualizados, em uma versão que ainda não implementava o HSTS.
Nesses navegadores antigos, se você coloca na barra de endereços apenas "www.google.com.br", por exemplo, o navegador vai tentar primeiro uma requisição HTTP (e somente depois disso os próprios sites redirecionariam para HTTPS), e se houver um DSTNAT no meio do caminho redirecionando a porta 80, a página de login/aviso/bloqueio vai ser exibida normalmente. Se o cliente acessou "https://www.google.com.br" alguma vez, assim que colocar "www.google.com.br" na barra de endereços o navegador já procurará o servidor HTTPS, mas como você deve fazer esse DSTNAT aí há muito tempo, talvez isso nunca tenha ocorrido.
Todas versões não tão antigas dos navegadores implementam HSTS. Um site com HSTS devidamente configurado (já é praticamente padrão) estará dizendo ao navegador que ele nunca deve ser acessado por HTTP puro, então a conexão para ele sempre será iniciada já com SSL/TLS e qualquer interceptação entrará no caso 2 do que expliquei para o muttley.
Inclusive, aquele tal HTTPS Reflector do ThunderCache se baseia no funcionamento desses clientes HTTP sem HSTS implementado, bem como casos em que o site nunca foi acessado por HTTPS (por isso, às vezes, eles pedem para limpar todos dados do navegador: - cache, cookies, histórico, etc. - fazer parecer ser o primeiro acesso, que pode ocorrer em HTTP, e interceptar aí). No caso do Google Chrome, a Google força seus serviços a HTTPS não importando se é o primeiro acesso ou não; só não lembro se isso é em todas versões não tão antigas do Chrome ou se é desde que ela começou a usar HTTPS (o que faz muito tempo).
---
Se fosse possível resolver esse "problema" das páginas de login/aviso/bloqueio/etc. com sites HTTPS, de que o pessoal tanto reclama, teria cache HTTPS funcionando lindamente hoje em dia e com a mesma capacidade de interceptar que na época em que tudo era HTTP puro.
Mas imaginar que todos os assinantes estejam com navegadores desatualizados é algo impossível de ocorrer.
Concordo. E agora que me lembrei de um detalhe sobre HSTS, é ainda mais estranho a ocorrência desse comportamento aí na sua rede: mesmo que o primeiro acesso ao site tenha sido feito em HTTP e interceptado, o site pode passar a informar ao navegador da exclusividade do HTTPS em acessos futuros a ele, então todo mundo aí deveria estar apresentando esse problema de interceptação do HTTPS...
Sei lá o que ocorre aí (já que não é um monte de gente com navegador bem desatualizado - único caso que consigo imaginar), mas gostaria de saber, hehehehe.