Don't block mixed worker/WebSockets content from localhost

ASSIGNED
Assigned to

Status

()

enhancement
P3
normal
ASSIGNED
2 years ago
12 days ago

People

(Reporter: poiru, Assigned: poiru, NeedInfo)

Tracking

({leave-open})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [domsecurity-backlog1])

Attachments

(1 attachment)

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
Whiteboard: [domsecurity-backlog1]
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.

We recently noticed that Firefox started blocking connectivity to WS on 127.0.0.1. This definitely works on Chrome - "localhost" is blocked, "127.0.0.1" but is working. Is this related and a deliberate change?

Dan, see comment 7?

Flags: needinfo?(dveditz)

(In reply to pawel from comment #7)

We recently noticed that Firefox started blocking connectivity to WS on 127.0.0.1. This definitely works on Chrome - "localhost" is blocked, "127.0.0.1" but is working. Is this related and a deliberate change?

started blocking? I thought this bug (and bug 1488740) was requesting that we fix it, from the assumption that it was already not working in mid-2017. If something blocked it further it definitely wasn't an intentional change. Can you say which releases or builds worked and when it stopped working? Even better if you have a clear testcase/example.

bug 1402530 made changes to the mixed content blocker that would have been released as Firefox 68 this week. If anything it was intended to make this work better, not break it. Although I see tests added for "http://localhost" there may not have been ws: mixed-content tests.

Flags: needinfo?(streich.mobile)
Flags: needinfo?(pawel)
Flags: needinfo?(dveditz)

(In reply to Daniel Veditz [:dveditz] OOO until 7/15 from comment #9)

Can you say which releases or builds worked and when it stopped working? Even better if you have a clear testcase/example. bug 1402530 made changes to the mixed content blocker that would have been released as Firefox 68 this week. If anything it was intended to make this work better, not break it. Although I see tests added for "http://localhost" there may not have been ws: mixed-content tests.

I just tested this on Firefox 68.0. Here's a test to reproduce I used:

  1. Fiddle to verify connectivity via WebSocket (it talks to 127.0.0.1:8080) - https://jsfiddle.net/47ny0xoa/
  2. Simple WebSocket echo server to run on 127.0.0.1:8080 - I used this one: https://github.com/pbadenski/simple-websocket-echo-server

Once a WebSocket server is running on your machine, jsfiddle should be able to connect to it. This works on Chrome (75.0.3770.100), but doesn't on Firefox. On firefox I get "SecurityError: The operation is insecure."

BTW Chrome also allows communication on "localhost" - which I wouldn't necessarily expect... but just mentioning for the sake of completeness.

Hope it helps...

Flags: needinfo?(pawel)

I just used my test to verify Firefox 50 and Firefox 52 (random old versions I have) and this also doesn't seem to be working.

For clarification we did not do very thorough testing on Firefox beforehand for our WebSocket service, so it is likely that this was not working before as well.

Apologies for confusion.

We already allow HTTPS origins to use to plain HTTP active content when using
loopback URLs such as http://127.0.0.1. Lets extend this to WebSocket
connections as well to match Chrome.

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 birunthan@mohanathas.com:
https://hg.mozilla.org/integration/autoland/rev/38fbe93d6e28
Allow localhost ws:// connections from secure origins. r=jkt

Marking leave-open because I didn't check if this is fixed for workers yet.

Keywords: leave-open
You need to log in before you can comment on or make changes to this bug.