Direcionar paginas HTTPS para tela do login do hotspot

[jeanpablojp]

Já refez do zero sem usar certificado?

Fiz sim, inclusive com versões diferentes de mikrotik 4x, 5x, 6x , as versões menores não me atenderiam.

[jeanpablojp]

Por que no faz um tutorial de PPOE e deixa no quarto do hotel ou recepção e aew só basta a pessoa pedir a liberação do login e senha ?

Grande parte das pessoas usam celular, tablets, o que torna difícil a autenticação. Se não fosse esse https estaria tudo perfeito.

[Fael]

No caso esse uso é restrito ao quarto ? Porque se for daria pra instalar roteador em cada quarto...
Hoje tem roteador de 40,00.
Um Amigo meu consegue fazer esse certificado seu funciona, se quiser o contato dele me chama por Inbox.

[jeanpablojp]

No caso esse uso é restrito ao quarto ? Porque se for daria pra instalar roteador em cada quarto...
Hoje tem roteador de 40,00.
Um Amigo meu consegue fazer esse certificado seu funciona, se quiser o contato dele me chama por Inbox.

Mas em noteis eles não querem internet apenas nos quartos, mas em todo estabelecimento, tenho hotel aqui que tem sala de eventos, etc. O hotspot ainda é a melhor opção.

[olivionet]

Alguém teve sucesso com a regra ou de alguma outra forma ?

Realmente o problema não tem solução, acredito que só pppoe nos clientes pra resolver ou então adiquirindo um certificado ssl pra conseguir funcionar de acordo com o vídeo , porem no vídeo precisa do cliente (navegador) adicionar uma exceção para aquele certificado, mas se ele for válido talvez funciona sem problema.

Alguém sabe me dizer com exatidão qual desses certificados eu preciso adquirir para ser um certificado válido e ser reconhecido pelos navegadores :

https://www.certisign.com.br/certificado-servidor/ssl

Será que vou precisar de somente 1 certificado ou serão 1 para cada url, se bem que se for por url, pode-se padronizar o dns do hotspot server pra uma única url e ter somente um certificado ???????

[alexsuarezferreira]

por e telefone que não puxa o autenticador.... to sofrendo e pensando em voltar ao velho ip+mac .....

[iburanet]

2017 alguem conseguiu uma solução definitiva?

[marcelorodrigues]

2017 alguem conseguiu uma solução definitiva?

Cara só se tiver chave SSH válida! Para usar no hotspot

[marcelorodrigues]

Errado Marcelo, é SSL. E essa é a solução 2017 até mesmo 2100.

Exato, eu não lembrava o nome rs

[1929]

Caraca, 3 anos e a coisa continua fermentando e sem solução...
Volto a dizer que felizmente aqui não acontece nada disso. Nunca tivemos um cliente reclamando que não conseguia autenticar por chamar uma pagina https.
Não usamos certificado SSL.

[marcelorodrigues]

Caraca, 3 anos e a coisa continua fermentando e sem solução...
Volto a dizer que felizmente aqui não acontece nada disso. Nunca tivemos um cliente reclamando que não conseguia autenticar por chamar uma pagina https.
Não usamos certificado SSL.

Quando ele vai entrar no Google não dá erro? Na primeira vez

[muttley]

Eu abandonei hotspot, por causa disso! kkkkkkkkk
Migrei pra pppoe os meus clientes.
É claro que ainda da erro de ssl, quando tem q aparecer a pagina de aviso ou corte!
Cliente liga dizendo q esta sem net, eu respondo; abre o navegador e digita la em cima, ex: g1 .com . br - e ja aparece o aviso ou corte. hehehehehe. Depois o cliente vem aqui quieto e paga a mensalidade! kkkkkk (coloquei espaços pra nao criar o link).

[1929]

Quando ele vai entrar no Google não dá erro? Na primeira vez

não dá. É redondinho...
Quanto a login no hotspot temos config o cookie para uma semana. Então entra direto.

Já experimentei muito tempo atrás configurar login por MAC. Funcionou pois o usuário entrava direto, mas aconteceu um conflito de vez em quando, (conflito este mais por minha culpa e não me detive para ver o motivo), que não me lembro mais qual era e por isso não usei mais. Faz tempo.

[andrecarlim]

Um pouco de informação não faz mal a ninguém...

https://cryptoid.com.br/ssl/o-que-sao-ssl-ssh-https/

P.S.: por favor prestem a atenção quando se diz "entre dois computadores", não entre o seu computador e a torcida do Flamengo! E por favor não digam que "o problema não foi resolvido", por que não é um problema, é apenas o comportamento esperado do protocolo SSL!

[muttley]

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.

[1929]

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.

[TsouzaR]

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.

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.

[1929]

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

[TsouzaR]

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.

[3lton]

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?