Re: Secure (https) proxy authentification

On 19/02/2012 7:56 a.m., Nicolas Mailhot wrote:
> Le Sam 18 février 2012 18:29, Henry Story a écrit :
>> On 16 Feb 2012, at 15:36, Nicolas Mailhot wrote:
>>> Hi,
>>> Now that browsers have started refusing redirection of https sessions, there
>>> is no clean way for a proxy to point browsers to an https authentication
>>> portal when they need to be authenticated or re-authenticated.
>> Hi Nicolas. I am working on WebID - an https protocol (
>> http://webid.info/spec ) -
>> so this sounds like it could be important to us. Do you have a pointer to
>> explain the situation here in more detail? I am not sure what kind of redirects
>> get refused, for what reason, etc....
> Hi Henry,
>
> The problem as I understand it is pretty simple.
>
> When you're managing an hotspot or corporate proxy you want to make sure only
> authorized persons pass through. It's pretty easy to set up the network so
> browsers have to pass through some control equipment to reach the internet.
> However it's much more difficult to convince them to display some
> authorization page so users can actually provide their credentials.
>
> In both cases you need to handle generic browsers without any special
> configuration, otherwise you can not support visitors (and they can use a wide
> range of devices, from desktops to laptops, netbooks, tablets, the range
> always increases).
>
> So the usual workflow would be:
>
> 1. user with some browser-capable equipment arrives on the network (usually
> you can not control physical access well enough to be sure every connecting
> user is authorized to)
> 2. he types some address in his browser
<snip>
>
> At step 2., the user is not typing the captive portal address (he might not
> know it). To point the browser the right way, such equipments used to issue a
> redirect. However that was never ideal (it's basically a man in the middle
> attack) and browsers will not honour such redirects when the user is accessing
> an https site since 2010 IIRC (I don't remember the CVE numbers, but every
> major browser stopped honoring those redirects at about the same time) . So

Ah, that restricted to 302, 300 and unknown 3xx redirects AFAIK, which 
are unsafe or difficult to allow safe auto-redirect for.

> now users get an empty page or a 'proxy does not like you' error page in the
> middle of their https browsing
>
> See also: https://en.wikipedia.org/wiki/Captive_portal
>
> But the control equipments do not want to attack the user session. All they
> want is to get the browser to display the captive portal auth page. All the
> hacks detailed on the wikipedia page would never have been necessary if the
> http protocol actually provided a standard way to get the browser to display
> this page.

Most of the hacks on the wikipedia page are involved with getting the 
packets to the portals proxy software without making the browser aware 
that it exists. Simple proxy auto-configuration avoids all of these 
hacks. They all happen long before HTTP gets a byte in edgewise.

How do you propose HTTP spec updates to solve "users who first use an 
email client or other will find the connection not working without 
explanation"? This being the problem which covers intercepted port 443 
packets for HTTPS portal.

>
> I'd really like the working group to define such a standard method. It
> wouldn't be complex or difficult to implement in browsers, and it would solve
> many actual problems now.

Do you mean a mechanism like the status 303 (See Other), 305 (Use Proxy) 
and 511 (Network Authentication Required)?

Notice how 302 is not in that list despite Wikipedia noting that most 
portals use 302. That would seem to be one part of the underlying 
problem. The other part being browsers defaulting to disable WPAD 
support (needed for 303 to work) or treating 303 as 302 including those 
security protections.


The "correct" workflow for a captive portal depends on whether the 
packets are intercepted:
  511 with login "splash" page doing some form of side-band 
authentication, or
  305 whereon the browser uses the portal proxy and hopefully sends 
credentials

... or not intercepted:
  303 redirecting to a resource which emits 407 then on success 303 
redirects back to the original URI, whereon the browse sends credentials.


Note that only the 511 NAT intercept case involves changes to the spec, 
and that is being done as 
http://tools.ietf.org/id/draft-nottingham-http-new-status-04.txt.

AYJ

Received on Sunday, 19 February 2012 02:46:48 UTC