Página 8 de 10 PrimeiroPrimeiro ... 345678910 ÚltimoÚltimo
+ Responder ao Tópico



  1. 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.

  2. Citação Postado originalmente por muttley Ver Post
    Eu abandonei hotspot, por causa desse probleminha. Não resolve colocar o google, como pagina inicial, la no arquivo alogin do hotspot. hehehehe....
    Usei hotspot por um tempo, acho q no máximo 1 ano. E depois migrei para pppoe.
    Com o uso do Mk-Auth.
    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.

    Citação Postado originalmente por 1929 Ver Post
    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.
    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.



  3. Mas imaginar que todos os assinantes estejam com navegadores desatualizados é algo impossível de ocorrer.

  4. 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.



  5. Citação Postado originalmente por jeanpablojp Ver Post
    Quando o usuário acessa uma pagina HTTP:// o mesmo é direcionado para a pagina de login do hotspot, até ai tudo OK, agora quando ele acessa uma pagina HTTPS:// ele retorna um erro de SSL não encontrado, e não abre a pagina de login do hotspot, já tentei vários direcionamentos e nada, alguém já passou por isso, e tem alguma solução ou ao menos alguma sugestão ???

    Versão do Mikrotik 5.20

    Já tentei esse comando aqui mas não resolveu:
    /ip firewall nat add action=redirect chain=hotspot comment=“redirecionamento https antes do login no hotspot” dst-port=443 hotspot=local-dst protocol=tcp to-ports=80


    Obrigado.

    ola amigo! estou com o mesmo problema de redirecionamento.
    o que vc fez para resolver este problema?






Tópicos Similares

  1. Suporte on-line na tela de login do hotspot
    Por Maurobranquinho no fórum Redes
    Respostas: 8
    Último Post: 17-09-2011, 18:46
  2. Tela de login do Proxy não guarda senha
    Por pssgyn no fórum Servidores de Rede
    Respostas: 2
    Último Post: 30-03-2010, 10:50
  3. liberar um ip o mac sem passar por a tela do login do nocat
    Por gsilvei no fórum Sistemas Operacionais
    Respostas: 5
    Último Post: 08-10-2009, 21:43
  4. Respostas: 0
    Último Post: 08-05-2008, 07:26
  5. Tela de Login do Hotspot ..help
    Por marcus1aleks no fórum Redes
    Respostas: 7
    Último Post: 19-07-2007, 22:39

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L