WebSocket Protocol Updated | Hacker News Reader

WebSocket Protocol Updated

blog.chromium.org

41 pointsraju19 comments

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.

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.

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

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.

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.

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.

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.

It looks like someone wrote an AI to convert code into English, and threw in one of their units tests too.

When you do figure it out post it on HN ;)

Sure :) I'll try and implement the changes in the next day or 2 and write up a summary of the differences. So far looking over the spec, it's just bizarre incompatible silly changes that don't really improve much.

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

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

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.

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?

"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".

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.

It's not easy balancing on the bleeding edge.

Right now I've already made http://beaconpush.com support two different versions of Web Sockets implemented by different versions of Google Chrome. (There were differences in the handshake origin URL).

Don't get me wrong though, I'm not complaining. I knew what could happen. It's just that the hype surrounding Web Sockets rarely mention these more cumbersome details of the protocol still being a draft.

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.

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

Reply on news.ycombinator.com