[AusNOG] Interception?

[Lloyd Wood]

It's IF they start a browser. Say they fire up e.g. Skype sans browser. It won't work until they fire up a browser and try a normal web request to get a login. Eventually, users have to learn these necessary steps for networked comms. Https or a local file: url just has the browser running already... Everything fails until you spawn the browser and issue a vanilla http request.

I'd argue that one fix would be a new DHCP option providing a URL, and then the OS spawns the browser to open that page...... The useless dhcp quote server option could be reused for this, but that's an IP address, and since most webservers expect hostname and there's a reverse lookup needed, perhaps a new dhcp option is the way to go. I haven't been following e.g. the autoconf ietf group; surely this must have been proposed by now?


On 5 Jul 2012, at 20:38, Skeeve Stevens <skeeve+ausnog at eintellego.net> wrote:

> Hey all,
> 
> Given the discussions happening on the list at the moment and what happened with Telstra, and a particular project I am working on at the moment, I thought I would seek the community's comments.
> 
> In simple terms, the project is a wireless hotspot for a particular purpose.  The hotspot provides content (all legal) and after a product purchase, internet access for a period of time.  All that is simple and nothing many people aren't already doing.
> 
> The issue that I've recently come up against is HTTPS.  Many sites are moving to HTTPS as default.  Facebook, Google, etc etc are starting to use it more and more.  Now this is not a problem at all, and fully supported as normal web traffic should be.
> 
> The problem we're facing is that as per normal hotspot solutions, when a user connects to the hotspot, they get an IP.  Then they start a browser, and if it goes to a home-page, it gets redirected to a captive portal page where they click some terms and we move on.
> 
> Now that many people are having a HTTPS address as their 'home/startpage/etc', the HTTPS not able to get anywhere and breaking.  So to solve this issue, we now also intercept 443 - HTTPD and redirect it back to the portal.
> 
> Due to the user trying to go to https://blah.com/ being re-directed, the browser is freaking out with an interception or man-in-the-middle attack potential alert and so on.  
> 
> Now, I think its possible to work our way around this, but the question remains - "Is intercepting HTTPS for redirection purposes - an interception issue" ?
> 
> I am sure there are lots of people who have had this problem and may (or may not) have a way around it... but the question is - is there any legal issues here we have to worry about?
> 
> Comments welcome.
> 
> 
> Skeeve Stevens, CEO - eintellego Pty Ltd
> skeeve at eintellego.net ; www.eintellego.net
> Phone: 1300 753 383; Cell +61 (0)414 753 383 ; skype://skeeve
> facebook.com/eintellego ; linkedin.com/in/skeeve 
> twitter.com/networkceoau ; blog: www.network-ceo.net
> 
> The Experts Who The Experts Call
> Juniper - Cisco – IBM
> 
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20120705/a69c07f0/attachment.html>