Re: HTTP, websockets, and redirects

On Thu, Sep 1, 2011 at 4:53 AM, Rich Tibbett <richt@opera.com> wrote:
> 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?

Unfortunately, digest isn't robust against phishing.

Adam


> 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 17:40:08 UTC