Intent to Implement: WebSocket: permit connection reuse for auth

[Adam Rice]

Contact emails
ri...@chromium.org

Spec
https://tools.ietf.org/html/rfc6455 (the WebSocket protocol)

https://tools.ietf.org/html/rfc4559 (HTTP "Negotiate" authentication)


Summary
This is a network-only change. I am using the Blink process because it is exposed to servers via changed behaviour.

When receiving a 401 or 407 HTTP response during the WebSocket handshake, Chrome will attempt to continue authentication on the same socket.

Windows HTTP authentication usually requires a single connection be reused in order for authentication to succeed. Up until now, Chrome has always closed the connection on a 401 status response, so Windows authentication has not worked.

Windows HTTP authentication is documented in RFC 4559. Its connection-level authentication is controversial, but widely supported by browsers, including Chrome for ordinary HTTP.

Windows authentication support is mostly useful in enterprise environments where single-sign-on is used.


Motivation
Lack of support for Windows single-sign-on causes interoperability problems. Implementers are forced to either provide a degraded user experience for Chrome users, or not support Chrome at all.

Interoperability risk
Firefox: Shipped
Edge: Shipped
Safari: No public signals
Web developers: Strongly positive

This change will improve interoperability by bringing Chrome's behaviour in line with Firefox and Edge.

Safari does not support HTTP authentication at all, so naturally it doesn't support Windows HTTP authentication.

Compatibility risk
There is a risk that servers will be confused by connection reuse where previously there was none. For this reason, we only perform connection reuse after responses with 401 and 407 HTTP status codes.

A series of increasingly large Finch trials is being used to validate web compatibility.

Standard-compliance of this change is debatable. The most obviously relevant paragraph in the WebSocket RFC is in section 4.1:

  1. If the status code received from the server is not 101, the
      client handles the response per HTTP [RFC2616] procedures.  In
      particular, the client might perform authentication if it
      receives a 401 status code; the server might redirect the client
      using a 3xx status code (but clients are not required to follow
      them), etc.  Otherwise, proceed as follows.

This appears to support this behaviour. On the other hand, the earlier paragraph

  To _Establish a WebSocket Connection_, a client opens a connection
  and sends a handshake as defined in this section.  A connection is
  defined to initially be in a CONNECTING state.

superficially appears to disallow another HTTP transaction happening between opening the connection and sending a handshake. However, in combination with the other paragraph it can be read as simply omitting mention of the additional transaction(s).

Ongoing technical constraints
None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,
Chrome OS, Android, and Android WebView)?
Yes.

OWP launch tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=423609 is the issue for supporting Windows auth for WebSockets. There isn't a specific launch bug.


Link to entry on the Chrome Platform Status
https://www.chromestatus.com/features/4885239100866560


Requesting approval to ship?
No. The decision to ship will be made once web compatibility has been verified by experiment.

[Peter Saint-Andre]

On 7/26/18 5:35 AM, Adam Rice wrote:

> Standard-compliance of this change is debatable. The most obviously
> relevant paragraph in the WebSocket RFC is in section 4.1:
>
>   1. If the status code received from the server is not 101, the
>       client handles the response per HTTP [RFC2616

> <https://tools.ietf.org/html/rfc2616>] procedures.  In

>       particular, the client might perform authentication if it
>       receives a 401 status code; the server might redirect the client
>       using a 3xx status code (but clients are not required to follow
>       them), etc.  Otherwise, proceed as follows.
>
>
> This appears to support this behaviour. On the other hand, the earlier
> paragraph
>
>   To _Establish a WebSocket Connection_, a client opens a connection
>   and sends a handshake as defined in this section.  A connection is
>   defined to initially be in a CONNECTING state.
>
> superficially appears to disallow another HTTP transaction happening
> between opening the connection and sending a handshake. However, in
> combination with the other paragraph it can be read as simply omitting
> mention of the additional transaction(s).

I asked Alexey Melnikov, co-author of RFC 6455, about this and he
replied as follows (quoted with permission):

"I think this is fine. I would expect that authentication can be
completed before WebSocket is invoked, even if a particular HTTP
authentication method requires multiple round trips (like some Windows
auth). So I think this is consistent with the spirit of the WebSocket
specifications."

Peter

[Adam Rice]

Peter Saint-Andre wrote:

I asked Alexey Melnikov, co-author of RFC 6455, about this and he
replied as follows (quoted with permission):
"I think this is fine. I would expect that authentication can be
completed before WebSocket is invoked, even if a particular HTTP
authentication method requires multiple round trips (like some Windows
auth). So I think this is consistent with the spirit of the WebSocket
specifications."

Brilliant, thanks! I've spent far too much time worrying about this particular point.