Chrome 19 update breaks secure WebSockets | Hacker News Reader

Chrome 19 update breaks secure WebSockets

code.google.com

48 pointsmntmn20 comments

(I'm the Chromium dev who triaged the bug this morning) This title is misleading. There's a bug when the SSL handshake for a WebSocket encounters an error, such as an invalid server certificate. This obviously sucks for developers, but for production sites which should not have SSL handshake errors, it should not be an issue.

This is one of the reasons corporates still use IE. Its easy to control and QA for stuff like this.

Heads roll when 1500 people can't work.

This is not a legitimate excuse for using IE instead of Chrome.

You can disable automatic updates via setting just a single registry key on Windows (and do similarly simple operations on Linux and Mac.)

http://www.chromefans.org/chrome-tutorial/how-to-disable-goo...

No, please do not disable automatic updates.

Without automatic updates, you are not receiving security updates so you are running a vulnerable browser.

It is a tradeoff. If somebody disabled automatic updates in Chrome, then they wouldn't have their secure websockets randomly broken on them some day. This could be more important for some users.

Enterprises that disable automatic updates should be regularly monitoring when updates occur so they understand the tradeoffs between the risk of using code that hasn't been tested extensively (so things might break) and the value provided in the updates.

This bug will likely not be fixed, since it is in a stable release and is not a security threat. So not updating in order to avoid this bug means not updating for the entire 6-week period. That's a huge amount of time to not be receiving security updates. It's hard for me to see the tradeoff making sense.

I guess delaying the update until the severity of the bug is clear might make sense, for a short amount of time. But if you don't have a good workaround for the problem, you again have the choice between the bug or between an unpatched browser for a whole 6 scary weeks.

It is when you consider WSUS which allows staged deployments of patches. Oh and group policy which allows browsers to be controlled heavily.

I rather like Chrome but as with other browsers, in controlled corporate environments there is no competition with IE. Any technical superiority is 100% irrelevant.

I'm not sure if they are as good as they are for IE, but there are more tools available for deploying Chrome in the enterprise (http://serverfault.com/questions/364150/running-google-chrom...).

Interesting - genuinely didn't know about that. Thanks for the pointer! :)

It's not predictably happening with _all_ websocket server implementations. I tried with node.js using a combination of https and ws modules. That worked. We crashed Chrome using em-websockt and netty, though.

(i'm on the chrome dev relations team, btw)

We have a few people looking at the ticket now.. looks like its within our websocket implementation and not at the SSL layer. Still reducing though..

We could use some crash IDs if you have any. To get those: Assuming crash reporting is enabled, head to about:crashes and grab any crash ID associated with this event. And drop them in a comment on the ticket. Thank you much.

A quick way to test this is to use:

http://websocketstest.com/

I tested this with an em-websocket (Ruby) server using SSL and after I updated to Chrome 19 (OS X 10.7.3) it no longer works.

I just tested this under OSX and had no problem, so this is probably Windows-only.

Not quite. From the original bug report:

"Today I installed Debian google-chrome-unstable and it also exhibits this issue."

One commenter (http://code.google.com/p/chromium/issues/detail?id=128339#c3) also claimed to have the issue on OS X specifically.

Ditto. Chrome 19.0.1084.46 OSX 10.7

    var sock = new window.WebSocket('wss://localhost:3000/echo');
    >undefined
    sock.send('hello');
    >false

This should get fixed before it goes to beta right? Can someone confirm whether or not bugs like this are usually fixed?

> This should get fixed before it goes to beta right?

This is a stable release. It already passed through beta, dev and canary.

> Can someone confirm whether or not bugs like this are usually fixed?

Typically only security bugs are fixed in stable releases, which would imply this will likely not be fixed.

…for some users, apparently, but not all. Is that right?

Reply on news.ycombinator.com