[AusNOG] Interception?

[Chris Simonis]

The 511 doesn't solve the https problem though. There's a tiny little
footnote down the bottom

Also, note that captive portals using this status code on a Secure
   Socket Layer (SSL) or Transport Layer Security (TLS) connection
   (commonly, port 443) will generate a certificate error on the client.

Regards,
Chris

On Fri, Jul 6, 2012 at 9:37 AM, Wade Roberts <ausnog at acquired-taste.net>wrote:

> While this won't help short term, RFC 6585 (
> http://tools.ietf.org/html/rfc6585) introduced the HTTP 511 status code:
> Network Authentication Required.
>
> You're in a bit of a v6-esque chicken and egg for implementation, but
> maybe you can short circuit it somewhat by having it implemented in this
> environment so it just works when clients catch up.
>
> --
> Wade
>
>
>
> On 2012-07-05, at 20:38, Skeeve Stevens 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
>
>
>
> _______________________________________________
> 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/9c9d39ca/attachment.html>