3 ms·

As I already stated, we plan on having an explicit opt-in for these cases. However, what you're describing is an implicit opt-in (external DNS pointing to local

As I already stated, we plan on having an explicit opt-in for these cases. However, what you're describing is an implicit opt-in (external DNS pointing to localhost, etc.), which can be trivially abused by third-parties in exactly the kind of attacks we're trying to prevent.

jorangreef 12y ago
WSS already has explicit opt-in in the Origin header.
- justinschuh 12y ago
  That's not the way the origin header works. The origin header in websockets is provided from the client to the server, and the server must take overt measures to protect itself or scope origins that are allowed. Given that we're worried about unsafe servers, the origin header won't protect against the attacks we're seeing. What we need is a mechanism for the server to authorize the client explicitly, so that we can disallow the resource implicitly when authorization is not present.
  - jorangreef 12y ago
    Have you seen any attacks on WSS servers on localhost with both explicit opt-in (via the Origin header) and implicit opt-in (via public DNS record and TLS certificate for that public DNS record) and additional mutual authentication (as in the case of Dropbox)? I doubt there are even a handful of people who have setup something like that (I used to think that WSS on localhost was not even possible because of the self-signed certificates not validating). And that is a specific scenario for which you can easily create a permanent exception for, without requiring the user to start Chrome with a command-line flag. You can block WS on localhost by all means. But blocking WSS on localhost after someone has gone through all the trouble of setting up a public DNS record, and CA-signed SSL certificate which validates against that FQDN (this is not just about public DNS localhost record services) makes no sense to me, and seems to be outside the intent of the original bug ticket.
    - justinschuh 12y ago
      I'm sorry, but I don't understand the argument you're making here. I've already explained that we plan to provide a portable mechanism for private and localhost opt in. It's just not going to be the mechanism you propose, since that mechanism doesn't address the vulnerabilities that we're concerned about. To reiterate the issues with your proposal: Public DNS pointing to private/localhost is in fact a component of many of the attacks we're concerned about. HTTPS on localhost doesn't do anything because the transport is already secure (which should be simplified in a future change in Chrome's content handling). And given that the major concern is weak/permissive servers, we can't rely on the WS(S) server implicitly protecting itself by enforcing the origin header.
  - obsurveyor 12y ago
    If there's no standard currently in place for this maybe Google's time would be better spent drafting one and going through the RFC process. A single app fix doesn't seem to do a lot of good since the solution for dealing with it is proprietary and not likely to be picked up by other browsers.
  - seba_dos1 12y ago
    Uhm? Unsafe servers? How so? For me it looks like the ticket is about unsafe pages trying to mess up with innocent local services, like router http control panel. WSS origin is exactly what's needed here. With the server being already running and meant to be connected to from a browser (as combination of WSS and proper localhost cert is proving), listening and explicitly allowing the client to connect, what threat is supposed to be there?
- deleted 12y ago
  [deleted]

jorangreef 12y ago

WSS already has explicit opt-in in the Origin header.

justinschuh 12y ago
That's not the way the origin header works. The origin header in websockets is provided from the client to the server, and the server must take overt measures to protect itself or scope origins that are allowed. Given that we're worried about unsafe servers, the origin header won't protect against the attacks we're seeing. What we need is a mechanism for the server to authorize the client explicitly, so that we can disallow the resource implicitly when authorization is not present.
- jorangreef 12y ago
  Have you seen any attacks on WSS servers on localhost with both explicit opt-in (via the Origin header) and implicit opt-in (via public DNS record and TLS certificate for that public DNS record) and additional mutual authentication (as in the case of Dropbox)? I doubt there are even a handful of people who have setup something like that (I used to think that WSS on localhost was not even possible because of the self-signed certificates not validating). And that is a specific scenario for which you can easily create a permanent exception for, without requiring the user to start Chrome with a command-line flag. You can block WS on localhost by all means. But blocking WSS on localhost after someone has gone through all the trouble of setting up a public DNS record, and CA-signed SSL certificate which validates against that FQDN (this is not just about public DNS localhost record services) makes no sense to me, and seems to be outside the intent of the original bug ticket.
  - justinschuh 12y ago
    I'm sorry, but I don't understand the argument you're making here. I've already explained that we plan to provide a portable mechanism for private and localhost opt in. It's just not going to be the mechanism you propose, since that mechanism doesn't address the vulnerabilities that we're concerned about. To reiterate the issues with your proposal: Public DNS pointing to private/localhost is in fact a component of many of the attacks we're concerned about. HTTPS on localhost doesn't do anything because the transport is already secure (which should be simplified in a future change in Chrome's content handling). And given that the major concern is weak/permissive servers, we can't rely on the WS(S) server implicitly protecting itself by enforcing the origin header.
- obsurveyor 12y ago
  If there's no standard currently in place for this maybe Google's time would be better spent drafting one and going through the RFC process. A single app fix doesn't seem to do a lot of good since the solution for dealing with it is proprietary and not likely to be picked up by other browsers.
- seba_dos1 12y ago
  Uhm? Unsafe servers? How so? For me it looks like the ticket is about unsafe pages trying to mess up with innocent local services, like router http control panel. WSS origin is exactly what's needed here. With the server being already running and meant to be connected to from a browser (as combination of WSS and proper localhost cert is proving), listening and explicitly allowing the client to connect, what threat is supposed to be there?
deleted 12y ago
[deleted]