Re: [hybi] Extensibility mechanisms?

[Adam Barth <[e-mail]>]

On Tue, Jul 27, 2010 at 12:32 AM, Jamie Lokier <[e-mail]> wrote:
> Maciej Stachowiak wrote:
>> I believe the TLS-based handshake (as proposed by Adam) is more
>> robust than solutions involving nonces and challenge/response built
>> into an HTTP-like handshake. The reason for this is that it's hard
>> for the attacker to control the bytes sent, other than to cause the
>> initiation of a TLS handshake, which is something that all network
>> services are already exposed to by browsers. The attacker cannot get
>> to the next-level protocol running over TLS unless the server
>> explicitly opts in. With HTTP-based schemes, it takes much more care
>> to avoid sending information as the "wrong" protocol.
>
> Isn't the TLS handshake rather fragile and vulnerable, by virtue of
> lots of services sitting behind TLS and using it only to get an
> encrypted channel?  If you can open a connection and start TLS, say on
> the ftps/imaps or even https port then it's basically unprotected
> bytes again after the TLS stage, wrapped *inside* TLS, giving a false
> sense of security.
>
> Or is there some extra magic sent in the TLS setup which will be
> consistently rejected by non-WebSocket TLS servers?

Indeed.  That's the problem that the using the "next protocol" TLS
extension solves.  During the TLS handshake, the client and server
negotiate that they'd both like to start talking WebSockets after
they're done with the handshake.

Adam