Re: [hybi] WebSocket, TLS and intermediaries

[Greg Wilkins <[e-mail]>]

On 22 July 2010 09:42, Mike Belshe <[e-mail]> wrote:

> On the TLS issue, we're going in circles.  Both sides are correct on the
> facts about the pros and cons of TLS (more or less).  I don't think the spec
> should require TLS.  But, would it be possible to define alternate
> handshakes based on whether TLS is used?
>
> If we use the currently defined handshake, TLS will be at a performance
> disadvantage to insecure WebSockets, because TLS will require more
> round-trips.
>
> Could we define, as part of the WebSocket protocol, that when WebSocket is
> negotiated over TLS it uses the TLS/NPN extension to effectively fold the
> WebSocket Upgrade handshake into the TLS handshake?  This removes a round
> trip from the WebSocket startup time.  The next-protocol-negotiation
> extension is defined here:
> http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00
>

+1

there has been on opinion expressed that we can only ever have 1 websocket
handshake.  Thus because we are starting with port 80, the handshake is
currently some mutant child of HTTP that must be sent even if another port
is used and no HTTP is involved.

This approach is  stuck trying to fixate on the exact syntax of the
handshake, literally down to counting spaces!

Instead we need to establish the semantic context in which a websocket
connection can be established, and then allow multiple ways to establish
that context.   HTTP upgrade is one such way, TLS/NPN is another.  I'm sure
there will eventually be more (maybe SPDY will support a DOWNGRADE method :)

If the semantic context is secure (eg contains random token generated after
any URL was formed by application), then does it really matter what syntax
was used to establish the context?

regards