Subject: Re: [hybi] Authentication headers

From: Ian Hickson <[email-masked]>
Date: Wed, 21 Jul 2010 07:01:31 +0000 (UTC)

On Mon, 7 Jun 2010, Wellington Fernando de Macedo wrote:
> 
> I'm updating the Mozilla's implementation of the WS protocol to its 
> latest version (v.76). I know that handling the 401 http response was 
> already removed in the v75. But now I've noted that even the http 
> Authorization header has been removed.
> 
> Well, I think that the 401 http status was removed in order to prevent 
> the browser to open unexpected auth dialogs to the user. Actually, I 
> know there is the cookie information, but I think it isn't always 
> enough. So, I would like to ask, why can't a "normal" request include 
> the Authorization header from its page origin?

There's some commented-out text to that effect, but frankly it's not clear 
to me that it would be particularly useful in practice. For example, the 
only authentication scheme that would work and be secure is Basic auth 
over TLS to the same host as served the HTML page. In practice, only very 
few sites use that combination of technologies; the cost of supporting it 
seems higher than the benefit gained from it. It also seems unreliable; it 
relies on the browser remembering the credentials used when loading the 
Web page, for instance. There are also a number of situations where it 
would seem that it should work but where it won't, for example if a page 
on one path uses pushState() to go to another path and then opens a 
WebSocket connection to the same host with the second path, the UA would 
not know the realm of the second path and thus wouldn't know to include 
the authentication information.

Basically, it seemed hacky. I couldn't really find a compelling argument 
to support this rather than having it at the application layer. (You can 
still leverage the basic auth feature that way, just have the server send 
back a unique token that identifies the user's session and then pass that 
back on the WebSocket connection.) Cookies are supported because they are 
_very_ widely used, so there's something to reuse. HTTP auth is used so 
rarely that I'd seriously consider dropping it from HTTP at this point; I 
really don't think it's worth adding to WebSockets.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 21 Jul 2010 20:38:51 +0200 (CEST)

On Wed, 21 Jul 2010, Ian Hickson wrote:

> HTTP auth is used so rarely that I'd seriously consider dropping it from 
> HTTP at this point; I really don't think it's worth adding to WebSockets.

Sorry, but this is just a guess from you and I don't see how you have any 
numbers to back this up.

In my view as a non-browser client author, HTTP auth is very frequently used. 
It might not be as common as cookies for web based authentication, but HTTP is 
way larger than just browser based operations.

(I realize this is only on the border of being on-topic for this list, but I 
couldn't resist responding to such a bold claim.)

-- 

  / daniel.haxx.se

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 22 Jul 2010 09:46:52 +1000

On 21 July 2010 17:01, Ian Hickson <[email-masked]> wrote:

>  Cookies are supported because they are

HTTP headers are frequently used for authentication mechanisms that are
neither the standard HTTP ones, nor plain simple cookies. For example many
OAUTH implementations allow tokens to be negotiated using HTTP headers.

Sure there are other ways than using headers, but the fact remains that many
implementations do use headers and I see no reason to break those
implementation nor prevent their usage with websocket.

---

From: Wellington Fernando de Macedo <[email-masked]>
Date: Wed, 21 Jul 2010 20:56:11 -0300

*> For example, the only authentication scheme that would work and be secure
is Basic auth
> seems higher than the benefit gained from it.*

Well, where I last worked it used TLS+Basic Auth (using PAM). This is very
useful, sure :)
*
> There are also a number of situations where it
> would seem that it should work but where it won't*

If it is true, then http auth should be removed at all. The Mozilla's
implementation shares the ws
credentials with the http ones (using the origin). So it isn't a problem. I
think that removing
http auth should be horribly bad. Similarly I think denying websockets from
using it isn't a good
thing either.

*> Sure there are other ways than using headers, but the fact remains that
many implementations do use headers
> and I see no reason to break those implementation nor prevent their usage
with websocket.*

Actually I don't see any reasons to prevent these headers.

Regards,

Wellington.

2010/7/21 Greg Wilkins <[email-masked]>

> Sure there are other ways than using headers, but the fact remains that
> many implementations do use headers and I see no reason to break those

---

From: Wellington Fernando de Macedo <[email-masked]>
Date: Wed, 21 Jul 2010 21:05:33 -0300

> For example, the only authentication scheme that would work and be secure
is Basic auth
> over TLS to the same host as served the HTML page.

Also, it isn't true. Again, all available Mozilla's http authentication
(like digest) work with websocket.

2010/7/21 Ian Hickson <[email-masked]>

---

From: Wellington Fernando de Macedo <[email-masked]>
Date: Wed, 21 Jul 2010 21:07:48 -0300

Well, I said something wrong... Actually digest with websockets just works
when connecting to the proxy.
Sorry.

2010/7/21 Wellington Fernando de Macedo <[email-masked]>

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 22 Jul 2010 11:04:13 +1000

> when connecting to the proxy.

It might happen to work, but according to the current specification it
should not work because:

 a) the additional headers required are not allowed
 b) the response challenge with the nonce is not allowed

of course browsers already have all this machinery implemented, so I would
not be surprised if it inadvertently worked .

cheers