New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

https should not be mandatory #658

Closed
lewispham opened this Issue Mar 23, 2015 · 7 comments

Comments

Projects
None yet
4 participants
@lewispham

Why is HTTPS madatory in Service Worker since Man in the Middle attacks can also be prevented by using WSS (WebSocket SSL) connection?

IMHO, HTTPS is never gonna be the future. Service Worker should provide an option for HTTP + WSS approaches instead of forcing developers to use HTTPS.

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Mar 23, 2015

Collaborator

I do not see how websockets solve this issue.

Dupe of #274

Collaborator

jakearchibald commented Mar 23, 2015

I do not see how websockets solve this issue.

Dupe of #274

@lewispham

This comment has been minimized.

Show comment
Hide comment
@lewispham

lewispham Mar 23, 2015

@jakearchibald Just send all sensitive data over wss. Then how can an attacker can steal the data?

@jakearchibald Just send all sensitive data over wss. Then how can an attacker can steal the data?

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Mar 23, 2015

Collaborator

Web security isn't just about data the user sends you, it's also about the data you send to your user.

Specifically, in this case, you'll be sending code that ensures the user's data is sent over a secure channel (this could simply be HTTPS, doesn't need to be wss), but you'll be sending that code over an insecure channel. That means a MITM simply needs to remove/rewrite the code that ensures the user's data is sent securely.

Collaborator

jakearchibald commented Mar 23, 2015

Web security isn't just about data the user sends you, it's also about the data you send to your user.

Specifically, in this case, you'll be sending code that ensures the user's data is sent over a secure channel (this could simply be HTTPS, doesn't need to be wss), but you'll be sending that code over an insecure channel. That means a MITM simply needs to remove/rewrite the code that ensures the user's data is sent securely.

@lewispham

This comment has been minimized.

Show comment
Hide comment
@lewispham

lewispham Mar 23, 2015

@jakearchibald Your point makes a lot of sense. It helps me a lot, indeed. Thank you.

@jakearchibald Your point makes a lot of sense. It helps me a lot, indeed. Thank you.

@flaki

This comment has been minimized.

Show comment
Hide comment
@flaki

flaki Mar 28, 2015

Regarding our twitter exchange - as it turns out Firefox has its own method for easing debugging/development on non-trivial setups - those that require more than a static storage (ie. gh-pages).

Firefox uses the dom.serviceWorkers.testing.enabled setting - which, when set to true it disables the HTTPS-restriction on service workers completely (IIUC). One might argue that is too much of a vulnerability (as leaving that setting open would make it so the browser is completely unprotected on all sites - practically removing all security provided by the feature in the first place).

One could also argue, that I should be filing this at Chromium dev (and that might be also true) however widespreed acceptance among big-league players could very much depend on solving the issue of integrating Service Worker development into current developer practices, so I think it might be useful to have at least guidelines in the spec for UA-s to ease development.

I would suggest, that a configuration setting (that would ship stable & developer versions alike) as the one above used in Firefox would solve the stated use cases (deliberately enabling testing on developer-owned devices), while requiring the configuration value to be set to a domain name (only service workers located on said domain would be able to bypass HTTPS check) would fix the problem of leaving one's device completely open for attacks on other sites.

This would effectively be an expansion on how browsers currently handle localhost as a special case — comments on this would be much welcome.

flaki commented Mar 28, 2015

Regarding our twitter exchange - as it turns out Firefox has its own method for easing debugging/development on non-trivial setups - those that require more than a static storage (ie. gh-pages).

Firefox uses the dom.serviceWorkers.testing.enabled setting - which, when set to true it disables the HTTPS-restriction on service workers completely (IIUC). One might argue that is too much of a vulnerability (as leaving that setting open would make it so the browser is completely unprotected on all sites - practically removing all security provided by the feature in the first place).

One could also argue, that I should be filing this at Chromium dev (and that might be also true) however widespreed acceptance among big-league players could very much depend on solving the issue of integrating Service Worker development into current developer practices, so I think it might be useful to have at least guidelines in the spec for UA-s to ease development.

I would suggest, that a configuration setting (that would ship stable & developer versions alike) as the one above used in Firefox would solve the stated use cases (deliberately enabling testing on developer-owned devices), while requiring the configuration value to be set to a domain name (only service workers located on said domain would be able to bypass HTTPS check) would fix the problem of leaving one's device completely open for attacks on other sites.

This would effectively be an expansion on how browsers currently handle localhost as a special case — comments on this would be much welcome.

@KenjiBaheux

This comment has been minimized.

Show comment
Hide comment
@KenjiBaheux

KenjiBaheux Apr 7, 2015

Collaborator

@flaki we've been discussing about this over at http://crbug.com/441605 We are looking for interest (please star the bug) to prioritize it. Also, feel free to share more details about your use cases and thoughts about the approach via Twitter.

Collaborator

KenjiBaheux commented Apr 7, 2015

@flaki we've been discussing about this over at http://crbug.com/441605 We are looking for interest (please star the bug) to prioritize it. Also, feel free to share more details about your use cases and thoughts about the approach via Twitter.

@flaki

This comment has been minimized.

Show comment
Hide comment
@flaki

flaki Apr 7, 2015

Cool! Thank you @KenjiBaheux, will make sure I chime in later!

flaki commented Apr 7, 2015

Cool! Thank you @KenjiBaheux, will make sure I chime in later!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment