- From: Adam Barth <w3c@adambarth.com>
- Date: Thu, 1 Sep 2011 10:38:59 -0700
- To: Rich Tibbett <richt@opera.com>
- Cc: Brian Raymor <Brian.Raymor@microsoft.com>, "public-ietf-w3c@w3.org" <public-ietf-w3c@w3.org>, WebApps WG <public-webapps@w3.org>
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:09 UTC