[AusNOG] Interception?

[Eric Pinkerton]

This is a great question Skeeve, esp given that the reason you are seeing more and more HTTPS is due to the proliferation and publicity of Firesheep et al.  I would personally be happy for all public hotspots to disallow all cleartext traffic by default anyway, as in this day and age checking your POP3 mail from an airport lounge should be a sackable offence!

Users need to be very weary of certificate warnings whilst on hotspots, so to cause them or teach people to ignore them or work around them in the name of ‘enhancing the user experience’ is problematic on many levels.

As Lloyd says, if they use anything other than a browser, then it simply won’t work, so why should Https be treated differently? – Captive portals are pretty commonplace now, and I believe it’s fair to expect people to understand that they need to fire up http in a browser in order to get started, you can augment this with patronising printed instructions in primary colours for ‘C’ level execs and the like.

On 5 Jul 2012, at 20:38, Skeeve Stevens <skeeve+ausnog at eintellego.net<mailto: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<mailto:skeeve at eintellego.net> ; www.eintellego.net<http://www.eintellego.net/>

Phone: 1300 753 383; Cell +61 (0)414 753 383 ; skype://skeeve

facebook.com/eintellego<http://facebook.com/eintellego> ; linkedin.com/in/skeeve<http://linkedin.com/in/skeeve>

twitter.com/networkceoau<http://twitter.com/networkceoau> ; blog: www.network-ceo.net<http://www.network-ceo.net/>
[http://eintellego.net/sig/logo.png]
The Experts Who The Experts Call
Juniper - Cisco – IBM

_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net<mailto:AusNOG at lists.ausnog.net>
http://lists.ausnog.net/mailman/listinfo/ausnog


Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.
http://www.mailguard.com.au/mg

Report this message as spam<https://login.mailguard.com.au/report/1F4X40VsQu/5YBFmmql2bDiTZyD7jzVzu/1.726>

-- 
Message  protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20120706/bf20f5e5/attachment.html>