8 ms·

Chrome 19 update breaks secure WebSockets

48 points by mntmn 14y ago

maybird 14y ago
I just tested this under OSX and had no problem, so this is probably Windows-only.
- nbpoole 14y ago
  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 http://code.google.com/p/chromium/issues/detail?id=128339#c3) also claimed to have the issue on OS X specifically.
- obituary_latte 14y ago
  Ditto. Chrome 19.0.1084.46 OSX 10.7 var sock = new window.WebSocket('wss://localhost:3000/echo'); >undefined sock.send('hello'); >false
alanh 14y ago
…for some users, apparently, but not all. Is that right?
dshimy 14y ago
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.
KaoruAoiShiho 14y ago
This should get fixed before it goes to beta right? Can someone confirm whether or not bugs like this are usually fixed?
- azakai 14y ago
  > 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 14y ago
    :(
mntmn 14y ago
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 14y ago
  (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.
gouranga 14y ago
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 14y ago
  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-google-chrome-automatic-updates.htm http://www.chromefans.org/chrome-tutorial/how-to-disable-goo...
  - azakai 14y ago
    No, please do not disable automatic updates. Without automatic updates, you are not receiving security updates so you are running a vulnerable browser.
    - jaredsohn 14y ago
      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.
      - azakai 14y ago
        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.
maybird 14y ago
A quick way to test this is to use: http://websocketstest.com/ http://websocketstest.com/
afimrishi 14y ago
(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.

48 points by mntmn 14y ago

maybird 14y ago

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

nbpoole 14y ago
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 http://code.google.com/p/chromium/issues/detail?id=128339#c3) also claimed to have the issue on OS X specifically.
obituary_latte 14y ago
Ditto. Chrome 19.0.1084.46 OSX 10.7 var sock = new window.WebSocket('wss://localhost:3000/echo'); >undefined sock.send('hello'); >false

alanh 14y ago

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

dshimy 14y ago

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.

KaoruAoiShiho 14y ago

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

azakai 14y ago
> 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 14y ago
  :(

mntmn 14y ago

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 14y ago
(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.

gouranga 14y ago

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 14y ago
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-google-chrome-automatic-updates.htm http://www.chromefans.org/chrome-tutorial/how-to-disable-goo...
- azakai 14y ago
  No, please do not disable automatic updates. Without automatic updates, you are not receiving security updates so you are running a vulnerable browser.
  - jaredsohn 14y ago
    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.
    - azakai 14y ago
      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.

maybird 14y ago

A quick way to test this is to use: http://websocketstest.com/ http://websocketstest.com/

afimrishi 14y ago

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