[AusNOG] Interception?

[Skeeve Stevens]

These kinds of solutions are always a pain in the ass. With So many
platforms (Windows, Mac, Blackberry, iDevices, Android, etc) then Browsers
(Chrome, IE, Firefox, Safari) and the way each of them does things
differently is really a killer for developers.

We 'need' to send users to the hotspots portal, and they need to go there
via a webpage.  The product is one that the users know where they are going
and why they are going there.  There will also be local content on the
solution meaning that the user may not even bother going to the web
(reasonable probability).

Everything works fine, except where users are using a https:// as their
'home page'.  We need to get them back to the hotspots main page somehow.
 Redirecting 443 in the firewall rules works just fine, but the browser
yelling about it isn't.

The other approach is perhaps using squid as a proxy, which has options
with such plugins as 'Squid SSLBump' -
http://wiki.squid-cache.org/Features/SslBump.

But I am trying to avoid the browser warning.  I don't really want to
intercept the HTTPS, I just want to make sure the users get to the HTTP
main portal page.
*

*
*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 ;  <http://twitter.com/networkceoau>
linkedin.com/in/skeeve

twitter.com/networkceoau ; blog: www.network-ceo.net

The Experts Who The Experts Call
Juniper - Cisco – IBM



On Thu, Jul 5, 2012 at 10:11 PM, Lloyd Wood <lloyd.wood at yahoo.co.uk> wrote:

> 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 ;  <http://twitter.com/networkceoau>
> 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/20120706/cd6a82da/attachment.html>