Community discussions

MikroTik App
 
mix359
just joined
Topic Author
Posts: 15
Joined: Fri Jan 04, 2013 8:20 pm

hotspot https captive portal with icap

Mon Nov 30, 2015 7:02 pm

Hi to all,
I use a mikrotik as an hotspot on my network. I'm trying to fix up the problem with the un-auth client calling an https page.
At the moment, the browsers of the client doesn't accept the connection because of the certificate (I've red the discussion about the problem with the certification proposed by the mikrotik for all sites)
But thinking of other public hotspot (like the one in the mac donalds), if I'm not wrong, they redirect the https to the login page without problem... so there's must be a way.
Looking on the net, I've see in the manual of a cisco about the captive portal, on their website, this sentence:
"Note: To monitor HTTPS traffic, the device uses HTTPS proxy and routes the network through ICAP protocol which will: intercept data communications and decrypt the data, validate the data against a policy, and re-encrypt the key with an SSL certificate."

http://sbkb.cisco.com/CiscoSB/GetArticl ... onverted=0

So, if I've understood well, they use a trasparent proxy with the ICAP protocol to intercept the https request, and trought that they can redirect the traffic...
Anyone that know something about this?
Will the internal web proxy support icap?

I see that squid support icap, so, isn't possible that redirecting all the un-auth 443 request to squid, it can do the redirect to the mikrotik login page?

I'm searching on the net some information about how to setup squid and make it redirect, but maybe someone in the forum have just tried something

Thanks to all
 
agnostic
Frequent Visitor
Frequent Visitor
Posts: 61
Joined: Fri Mar 21, 2014 8:23 pm

Re: hotspot https captive portal with icap

Mon Nov 30, 2015 7:50 pm

if i am not wrong if you buy an ssl certificate from a valid ssl authority you no longer have the warning on the browser so you could redirect to your https login ip address without any problems. valid only if your hotspot is on external server with public ip address (ssl works this way) so you could follow some guide on how to setup hotspot on external server.

the idea behind this is:

client types https://www.google.com---->hotspot dns resolves to external login server(eg 172.172.172.172) which has valid ssl certificate but not with domain name only redirect to ip so you see in browser https://www.google.com dissapears and server ip appears without any warnings (havent tried it correct me if i am wrong)------>at last client login and continue to original destination.

cant think of another way to trick browser to show google domain in https but content from a hotspot login page this would be a major security issue.
 
mix359
just joined
Topic Author
Posts: 15
Joined: Fri Jan 04, 2013 8:20 pm

Re: hotspot https captive portal with icap

Mon Nov 30, 2015 9:40 pm

Uhm... I don't think that this could be done only with mikrotik (at the moment).
If someone call google.com, and the mikrotik answer, the certificate from mikrotik couldn't be valid for google, so te browser drop the connection before receving web data from the mikrotik (and a redirect to an other ip).

The icap, if I understood well, can do a sort of man in the middle, decrypting the packet, checking it and re crypting it.. And maybe it can alter/change the packet (but I'm still researching documetation about that)
Only thing that I know is that there's a method that other hotspot use... So there must be a way :D
 
Sob
Forum Guru
Forum Guru
Posts: 9188
Joined: Mon Apr 20, 2009 9:11 pm

Re: hotspot https captive portal with icap

Mon Nov 30, 2015 11:24 pm

Think about it, if anything easily available to anyone could do successful MITM and decrypt https used by random hotspot clients, whole encryption would be useless. It is not possible.

Hotspot must be detected by browser or OS. Supposedly Chrome does that (I didn't verify it myself):
In the event that Chrome detects SSL connection timeouts, certificate errors, or other network issues that might be caused by a captive portal (a hotel's WiFi network, for instance), Chrome will make a cookieless request to http://www.gstatic.com/generate_204 and check the response code. If that request is redirected, Chrome will open the redirect target in a new tab on the assumption that it's a login page.
And Windows should do it too (I've actually seen that work in the past):
http://blog.superuser.com/2011/05/16/wi ... awareness/

This is the way to go. Hotspot itself can't do anything. Once the browser wants to connect to https://google.com, it won't accept anything else, no redirect to login page, nothing.