Closed Bug 1376309 Opened 3 years ago Closed 8 months ago
Don't block mixed worker/Web
Sockets content from localhost
47 bytes, text/x-phabricator-request
|Details | Review|
It is unclear if HTTPS origins should be able to use workers and WebSocket connections through a loopback HTTP address. They are not supported in Chrome (whether this is intentional or not is uncertain) so we ignored them in bug 903966. We should investigate and enable them if other browser vendors are on board.
At least WebSockets are supported for HTTPS origins in Chrome already, and has been for a while. I think the same arguments mkwst used for the chromium commit (https://chromium.googlesource.com/chromium/src.git/+/130ee686fa00b617bfc001ceb3bb49782da2cb4e) applies to WebSockets as well.
Dropbox's website uses a WebSocket connection to communicate with the Dropbox desktop application on localhost. This works in Chrome, but Dropbox must use a Flash proxy to bypass Firefox's WebSocket localhost restrictions.
Priority: -- → P3
WebSockets to the literal loopback addresses (as with http in bug 903966) should be fine.
Hey Dan; I don't think the other bug fixes for websockets. See the thread starting at https://bugzilla.mozilla.org/show_bug.cgi?id=903966#c32 Dropbox would still love it if this was fixed and we can kill Flash together :)
Hi, Kirill from Parity Technologies here. Allowing "plaintext" websockets from https origins will be a huge improvement for us — it will allow webpages to communicate with Parity Ethereum clients running locally, over WebSockets RPC. Currently only http websites are able to use our WS endpoint in Firefox, and https ones have to fall back to use local HTTP endpoint, which is by far not that efficient (especially for the "subscribe to the topics" usecase). There are even stories about people _disabling_ HTTPS on their websites to make local websocket connections work — which opens up a whole front of attack for the crypto software we're running.
If interpret comment from :dveditz correctly, expected behavior is to allow WS connections to loopback addresses as from secure contexts which are blocked on current nightly. Would anyone be willing to provide guidance on what changes are required to get this fixed ? I'd be willing to take a stab at it.
Assignee: nobody → birunthan
Status: NEW → ASSIGNED
Attachment #9078627 - Attachment description: Bug 1376309 - Allow localhost ws:// connections from secure origins. r=ckerschb → Bug 1376309 - Allow localhost ws:// connections from secure origins. r=jkt
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/38fbe93d6e28 Allow localhost ws:// connections from secure origins. r=jkt
Priority: P3 → --
Status: ASSIGNED → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.