Re: multiplexing -- don't do it

Le Lun 9 avril 2012 17:12, Jamie Lokier a écrit :
> Nicolas Mailhot wrote:

>> That means yes you do need to handle ajax updates,
>> mid-of-tls-interruptions, and all the difficult use cases. The user
>> is not going to oblige you by restricting himself to the simple use
>> cases when auth needs reacquiring Because if web clients don't
>> handle those, the gateway will always have the option to block the
>> access. And make no mistake it will and does exercise it.
>
> Right.  But the web client _can't_ handle those cases, because the
> gateway is injecting a fake redirect, the gateway doesn't know what
> it's interrupting, and the result is just like a normal page, not an
> error page or special signal to the browser asking for authorization.

Then it needs to be handled at the protocol level here.

>> The refusal to handle those cases so far has resulted in :
>> 1. broken hotel/conference captive portals
[…]

> Here's what happens in the old style: I connect to
> corporate/hotel/cafe network.  Then I dread starting Firefox because
> my last 50 open tabs will start up and _all_ redirect to the portal's
> Wifi login page.  I get 50 stupid login pages, and lose the original
> state.

That's your browser being intentionally stupid (especially in all the cases it
knows it's behind a proxy since it already had a pac to read), hoping that by
being stupid enough captive portals will go away. That didn't work too well so
far.

> So my objection to the classical approach to authorization by
> redirecting everything has nothing to do with security, or even HTTPS,
> and everything to do with the user experience.

The user experience is bad because browser people broke the old ways of doing
things, forcing equipment people to resort to more and more dangerous hacks

> What would work much is if the browser got a response meaning "you
> will need to authorize before the original request can proceed - open
> [URL] to present an authorization page", and do not consider the
> original request to have completed yet.

Which is exactly what proxy people have been demanding for years.

> Intercepting proxies could do that with HTTP or HTTPS or HTTP/2.0 if
> there's a standard signal for it, *without* having to break the
> security model or mislead any users.  It would be a nicer experience
> for everyone.

So let's put this in HTTP/2, ok ?

-- 
Nicolas Mailhot

Received on Tuesday, 10 April 2012 06:48:22 UTC