
WebSocket Protocol Updated - raju
http://blog.chromium.org/2010/06/websocket-protocol-updated.html
======
thamer
Note: this means that with the new version of Chromium, none of the web
applications using Web Sockets will work. The connection will fail with an
error about a protocol mismatch.

~~~
axod
It's pretty poor they couldn't work out how to make things backward
compatible.

Oh well, another job for me to do then...

I just love reading through a billion pages of a spec to find the actual data
I need which could have been written in a single page spec. bah.

Would it be so hard for them to put the 'answer' somewhere? eg "To make your
server work again, change "X" to "Y" in the headers".

I'll say it again, the spec is simply insane.

    
    
      18.  Let /number_1/ be a random integer from 0 to /max_1/ inclusive.
    
            Let /number_2/ be a random integer from 0 to /max_2/ inclusive.
    
            EXAMPLE: For example, 777,007,543 and 114,997,259.
    
       19.  Let /product_1/ be the result of multiplying /number_1/ and
            /spaces_1/ together.
    
            Let /product_2/ be the result of multiplying /number_2/ and
            /spaces_2/ together.
    
            EXAMPLE: Continuing the example, 3,885,037,715 and
            1,034,975,331.

~~~
zokier
Backward compatibility to what? They are in progress of creating the first
version now.

~~~
axod
Websockets have been in Chrome and in use for 6 months+.

<http://news.ycombinator.com/item?id=989680>

We have thousands of users using WebSocket every day. So this is kind of a
pain in the neck.

~~~
mike-cardwell
This is what you get when you use an unfinished protocol which everybody knows
is subject to change. Guess what, it might change again... They're still
researching what is the best way to do this. You should be happy they're
making improvements to the protocol you're using.

If they say, "This is the finished product and there will be no further
incompatible changes," and _then_ make a change which breaks your app. Then
you have a right to complain.

~~~
axod
I'm looking through the spec now. There don't seem to be any improvements.
Just incompatible changes made in bizarre ways.

I'll post a summary of the changes tomorrow.

These sort of things often seem like they're massively over engineered. You
could figure out the best way to do websockets in an afternoon without too
much fuss.

Nothing is ever 'finished'. It's just a pain to break backward compatibility
that's all.

~~~
carussell
_These sort of things often seem like they're massively over engineered._

Until you're the edge case who gets pissed off because they didn't make it
flexible enough, or the boilerplate is arcane and doesn't really make sense
with much of the normal use.

------
Raphael
Mibbit said...

Sorry but the spec for this is just ridiculous. It's insane. It contains the
code to parse HTTP headers, translated into _english_. You could easily
condense this spec down to a couple of pages, and it'd actually be usable.

Once again, sorry, but this is just ridiculous.

June 3, 2010 10:31 AM

------
judofyr
Is it possible to write a server which supports both versions?

~~~
jerf
Based on their description, it sounds like a bad idea even if it is possible.
Why would you want a fundamentally insecure protocol on your website?

This is "draft" for a reason, and note this is not a final protocol, it's
another draft. That's for a reason too. Don't expect your -76 server to last
forever with no changes either.

~~~
axod
You shouldn't rely on any protocol like this being 'secure'. You should have
other security in other places. So I don't think that's a valid reason really.

It's possible to support both, and that's what I'll personally be doing with
my own web server.

The changes I've seen don't add any obvious extra security as such, just make
it a little more difficult.

edit: Please give clear references when you say "Fundamentally insecure
protocol". That's pretty much totally unfounded. What type of security are you
talking about?

~~~
jerf
"Please give clear references when you say "Fundamentally insecure protocol".
That's pretty much totally unfounded. What type of security are you talking
about?"

Directly from the article: "introduces nonce-based challenge-response to
protect from cross protocol attacks." In my experience, when people identify a
possible security attack it's usually correct. (The solution can be another
matter, but I'm not looking at this enough to have even an uninformed
position.) The problem the sort of people working out a protocol like this
have is missing ones that are possible, not pointing out ones that don't
exist.

If you're comfortable with unnecessarily insecure lower layers, more power to
you. Don't expect plaudits from me. Or expect me to be taking security advice
from you after casually disregarding things like "security in depth".

~~~
axod
The original version of the protocol was already pretty strict. It required
exact responses, played in exactly the correct order in order for a connection
to be established.

All the new version does, is send over some obscure challenge data (generate a
random number, then insert random characters into it????). Then it expects a
response from the server with the value md5(challenge).

That does indeed get rid of a class of cross protocol attacks, but it's a
ridiculous edge case as far as I can see.

Previously you may have been able to find some server (non HTTP), that you
could connect to, somehow get it to respond with the correct HTTP headers in
exactly the right order, and continue. Then exploit it - send spam email, etc
etc

That's pretty unlikely.

Now, you'd have to get that server to respond with the md5 response, which is
fairly impossible.

BUT. The security here is in Browser->"Some non HTTP server being tricked" -
eg something I don't care about too much. Make your "non HTTP server" more
secure. For example see the recent exploit against freenode earlier this year,
where they allowed connections from an automated HTTP POST in the Firefox
browser - the ircd just ignored any HTTP stuff and happily connected users to
spam away. The fix wasn't to update the HTTP protocol or firefox, it was to
patch the ircd so it actually checks what protocol the client is speaking (And
also PING/PONG checks etc)

So, your premise that the original spec is somehow insecure to use within a
browser->webserver context, is completely incorrect.

------
Kilimanjaro
This is the beauty of the web, change the server code, then serve the new
client code and done.

Automagically updated. The client will never know what hit them.

~~~
papachito
Actually no, it says you need a new version of chromium, so the client will
know in that case.

