

Chrome 19 update breaks secure WebSockets - mntmn
http://code.google.com/p/chromium/issues/detail?id=128339

======
afimrishi
(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.

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

~~~
jaredsohn
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...](http://www.chromefans.org/chrome-tutorial/how-to-disable-google-
chrome-automatic-updates.htm)

~~~
gouranga
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.

~~~
jaredsohn
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...](http://serverfault.com/questions/364150/running-google-chrome-
updates-from-a-centralized-location)).

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

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

~~~
paulirish
(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.

------
maybird
A quick way to test this is to use:

<http://websocketstest.com/>

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

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

~~~
nbpoole
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.

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

~~~
azakai
> 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.

~~~
KaoruAoiShiho
:(

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

