Re: [hybi] Extensibility mechanisms?

[Scott Ferguson <[e-mail]>]

Maciej Stachowiak wrote:
> On Jul 21, 2010, at 5:30 PM, Scott Ferguson wrote:
>
>   
>> The counterproposal at
>>
>> http://hessian.caucho.com/websockets/draft-ferg-hybi-websockets-latest.html
>>
>> not complicated at all: it's a trivial protocol, and yet it solves the HyBi requirements, including requirements that the current draft ignores, as well as being extensible to muxing requirements.
>>     
>
> Can you explain how this proposal provides an HTTP-compatible upgrade in the non-TLS case? Or how it provides protection against cross-protocol attacks? I think those are two pretty important requirements, and it is not obvious to me how they are met.
>   
Actually, let me explain how the non-HTTP version was designed to handle 
cross-protocol attacks, because I didn't explain the reasoning behind 
the design in the draft.

I) Initial HELLO line

The initial line for both server and client responses is:

  %x80.x02.NN.NN WebSocket/1.0 LF

Deliberately designed properties of that line:

  1. Since it's a fixed-length line, there's no opportunity for URL or 
METHOD-style attacks.

  2. Since it's a line, terminated by LF, it validates against 
text-based protocols, even though this is a binary protocol. (Potential 
NN.NN attacks can be enumerated and checked.)

  3. Since the only variation is the two bytes NN.NN, 65536 values, all 
possible initial HELLO lines can be enumerated and tested against other 
protocols.

  4. Since it's not a legal HTTP line, HTTP servers and clients will 
reject it.

  5. Browser HTTP clients cannot generate that line.

  6. Since the initial byte is neither valid ASCII nor is it valid 
UTF-8, no validating ASCII/UTF-8 server will accept that line, and no 
ASCII/UTF-8 client can generate that line.

  7. The fixed "WebSocket/1.0" validates the protocol itself. Boring, 
but necessary.

I'll maintain the following properties are true of that initial line:

  1. No HTTP client can spoof that line (unless it has full binary 
control over the HTTP method, but that security hole could spoof any 
protocol).

  2. That line will be rejected by any HTTP server (all 64k variations 
of it).

  3. Clients of other protocols cannot spoof that line (again, unless 
they have full binary control over their initial bytes, and obviously 
TCP can "spoof" the line).

  4. binary and text servers which validate their initial line cannot be 
spoofed by it.

That covers validating binary and text protocols, but there's still the 
case of protocols like SMTP that discard invalid lines.

II) Handling recovery-based text protocols like SMTP

The next required lines from the request looks like:

  url: <restricted utf-8> LF

where the restrictions include forbidding LF itself.

This is a HTTP header without the line-folding.  If a SMTP 
implementation protects against HTTP headers (I checked against 
postfix), it protects against this WebSocket header. If the SMTP 
implementation accepts all invalid lines, there's really nothing you can 
do, except for the WebSocket client to wait for the server response.

III) header/url/origin issues

The "url:", "origin:", "protocol:" headers and their semantics are 
copied from the official WebSocket draft. If there's a problem with 
them, there's a problem with the official draft. (If there's an error in 
transcription, that's easily fixed.)

IV) nonce/digest

In practice, these cover validating protocols. However, it's also 
possible to force the server to prove that it's an active WebSocket 
server.  Adding a "nonce:" header to the client, and requiring the 
server to calculate a "digest:" header is proof that the server is a 
valid WebSocket server. (I personally don't think this is necessary, but 
the group may disagree.)

V) pipelining/multiple packet handshake

Pipelining data means the client is sending data before looking at the 
server's response. If this is unacceptable, the client must wait for the 
response.  There's no protocol design around this issue. You need to 
choose one behavior or the other. My draft choose pipelining. The group 
could choose the reverse.

VI) Does this cover everything?

Since the HELLO line is a fixed-length sequence (with finite 64k 
variations), it's possible to prove if it can spoof any specific 
protocol or if a specific protocol can be spoofed by it.

For example, it's possible to prove that this initial line is invalid 
HTTP and that no valid HTTP can match this line. In this case the proof 
is trivial because the initial byte is an invalid first byte of HTTP.

It's also possible to exhaustively test any specific 
non-WebSocket-protocol implementation against all possible HELLO 
attacks, because all possible HELLO lines are enumerable. You don't have 
to guess if an IRC server will reject a WebSocket HELLO; you can test it.

In a similar way, it's possible to reason about non-validating or 
partially validating servers. For example, if the HTTP server does not 
validate ASCII/UTF-8, but merely scans for SP and CR/LF, the WebSocket 
request line interpreted as HTTP is still an invalid request. And even 
if one of the NN is a SP and you have a truly brain-dead HTTP server, 
the HTTP method for the hypothetical broken server isn't a valid method. 
And if the server doesn't even validate that case, it's just plain broken.

So, even though the handshake wasn't my main focus of that draft, I do 
believe it covers cross-protocol scripting issues better than HTTP 
itself does. Obviously, my HTTP handshake version has identical security 
behavior with the official draft.

-- Scott