Re: Secure (https) proxy authentification

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
3. network routes the request through the control equipment
4. the control equipment needs to know who the user is. In case of a visitor
it also probably needs to display some information to tell the user where to
get the required authorization. To get widest possible web client support,
it's usually done with http basic auth on an https portal page
5. the user fills in a valid user id and password
6. browser continues on the actual URL the user typed

In some cases it's even more complex since the authorization is not eternal or
the connection load is shared by several equipments that may be rebooted. In
that case setp 2. becomes:

2. the user is already engaged in some workflow on a web site (may have
started filling forms, have some http session state, etc)
3. network routes the request through the control equipment but the user auth
expired/was forgotten/the user never provided auth to this specific equipment
4. the control equipment needs to know/confirm who the user is (without
breaking the user workflow)
5. the user fills in a valid user id and password
6. browser continues whatever request triggered step 3 (forgetting forms users
may have spent quite a lot of time filling is not nice)

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
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.

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.

-- 
Nicolas Mailhot

Received on Saturday, 18 February 2012 18:56:46 UTC