1376309 - Don't block mixed worker/WebSockets content from localhost

Status: RESOLVED FIXED

(Core :: DOM: Security, enhancement)

Description

[Biru Mohanathas [:poiru]]

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.

Comment 1

[Henrik Karlsson]

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.

Comment 2

[Chris Peterson [:cpeterson]]

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.

Comment 3

[Daniel Veditz [:dveditz]]

WebSockets to the literal loopback addresses (as with http in bug 903966) should be fine.

Comment 4

[Devdatta Akhawe [:devd]]

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 :)

Comment 5

[kirill]

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.

Comment 6

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

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.

Comment 7

[Pawel Badenski]

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?

Comment 8

[Boris Zbarsky [:bzbarsky]]

Dan, see comment 7?

Comment 9

[Daniel Veditz [: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.

Comment 10

[Pawel Badenski]

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

Comment 11

[Pawel Badenski]

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.

Comment 12

[Biru Mohanathas [:poiru]]

Attachment: Bug 1376309 - Allow localhost ws:// connections from secure origins. r=jkt

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.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/38fbe93d6e28
Allow localhost ws:// connections from secure origins. r=jkt

Comment 14

[Biru Mohanathas [:poiru]]

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

Comment 15

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/38fbe93d6e28

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

The leave-open keyword is there and there is no activity for 6 months.
:ckerschb, maybe it's time to close this bug?

Comment 17

[Christoph Kerschbaumer [:ckerschb]]

Removing priority so it shows up in our triage meeting tonight. I'll discuss with folks but I guess we can simply mark it as fixed. Question is just for what version for Firefox :-)

Comment 18

[Daniel Veditz [:dveditz]]

in-testsuite? flag to cover landing tests for comment 14, but the bug itself appears fixed.