1328326 - Can't establish WSS connection behind CloudFlare proxy

Status: RESOLVED DUPLICATE of bug 1328101

(NSS :: Libraries, defect)

Comment 1

[Sergio Oliveira Campos]

This is not a security issue. I've clicked on "restrict access to this bug" because it contains a link to internal stuff of my company I work for.

Comment 2

[:Gijs (he/him)]

comment 0 with sensitive links elided:


User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20161230030205

Steps to reproduce:

I'm trying to connect to my Websocket using the following code:

var socket = new WebSocket("wss://someserver.something/somepath/");
socket.onmessage = function(e) {
    console.log(JSON.parse(e.data));
}


Actual results:

This error shows up: 
"Firefox can’t establish a connection to the server at wss://someserver.something/somepath/."


Expected results:

The connection should be established. 

The problem happens in Firefox 53 (build id 20161230030205).
It works just fine with Firefox 50.0.1.0 and Chrome.

If I disable CloudFlare proxy and access my server directly it also works.

Basically WSS in Nightly is not playing nice with CloudFlare for some reason.

Comment 3

[:Gijs (he/him)]

I've marked comment #0 private so only people with security bug access (and maybe the poster?) can see it. I'll mark this bug as no longer security-sensitive so more people can help.

If you're running Nightly and it works on release, and you don't have a URL you can share so we can test this ourselves, the quickest way to figure out more here might be if you find a regression window with mozregression:

http://mozilla.github.io/mozregression/

Would it be possible for you to do this?

Comment 4

[Sergio Oliveira Campos]

11:18.24 INFO: Got as far as we can go bisecting nightlies...
11:18.24 INFO: Last good revision: 79feeed4293336089590320a9f30a813fade8e3c (2016-11-16)
11:18.24 INFO: First bad revision: 13f49da109ea460665ad27c8497cb1489548450c (2016-11-17)

Repo https://hg.mozilla.org/mozilla-central
13:45.98 INFO: Oh noes, no (more) inbound revisions :(
13:45.98 INFO: Last good revision: 830ce59e0a13e1e0544a1d36bff5f053ac315c21
13:45.98 INFO: First bad revision: c27117f67fa3ff30bbd34bcd6c7536c0d10bd4ad

Repo https://hg.mozilla.org/integration/mozilla-inbound
20:46.08 INFO: Oh noes, no (more) inbound revisions :(
20:46.08 INFO: Last good revision: 3cbb93f5768e0e5ac470d3bb29cea58fe2f45df3
20:46.08 INFO: First bad revision: f296d03423848da45f1839b946b103047834b459

20:48.32 INFO: Looks like the following bug has the changes which introduced the regression:
https://bugzilla.mozilla.org/show_bug.cgi?id=1317947

Comment 5

[:Felipe Gomes (needinfo for replies!)]

According to comment 4, this might have been caused by bug 1317947.

Comment 6

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Does it work if you set the pref "security.tls.version.max" to 3? How about in Chrome Canary? (This sounds a bit like bug 1328101)

Comment 7

[Sergio Oliveira Campos]

It works fine when I set "security.tls.version.max" to 3.

Comment 8

[Sergio Oliveira Campos]

Just tried in Chrome Version 57.0.2979.0 canary (64-bit) and it also works fine.

Comment 9

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Interesting - so it doesn't seem to be quite the same problem. In any case, this is an NSS issue.

Comment 10

[Franziskus Kiefer [:franziskus]]

This is the same issue as bug 1328101 (a TLS 1.3 incompatibility caused by something Cloudflare does).