Re: HTTP, websockets, and redirects

Adam Barth wrote:
> Generally speaking, browsers have been moving away from triggering
> authentication dialogs for subresource loads because they are more
> often used for phishing than for legitimate purposes.  A WebSocket
> connection is much like a subresource load.

Couldn't we only allow digest-based 401/407 authentication for 
subresource loads so an attacker cannot simply obtain unencrypted 
credentials?

The latest WebSocket protocol spec [1] says:

"This protocol doesn't prescribe any particular way that servers can 
authenticate clients during the WebSocket handshake.  The WebSocket 
server can use any client authentication mechanism available to a 
generic HTTP server, such as Cookies, HTTP Authentication, TLS 
authentication."

Without HTTP Auth and the difficulty/performance issues of doing TLS 
auth in pure JavaScript it seems we are left with a cookie-only 
authentication option.

Disabling support for Basic HTTP Authentication but still ticking the 
box for HTTP auth, with the added benefit that all such HTTP auth will 
be encrypted, seems like a win-win here.

- Rich

[1] 
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-13#page-54

>
>
> On Wed, Aug 10, 2011 at 9:36 PM, Brian Raymor
> <Brian.Raymor@microsoft.com>  wrote:
>> What is the rationale for also failing the websocket connection when a response for authentication is received such as:
>>
>> 401 Unauthorized
>> 407 Proxy Authentication Required
>>

Received on Thursday, 1 September 2011 11:54:21 UTC