Closed Bug 1328326 Opened 3 years ago Closed 3 years ago

Can't establish WSS connection behind CloudFlare proxy


(NSS :: Libraries, defect)

Not set


(Not tracked)



(Reporter: seocam, Unassigned)



(Keywords: regression)

Group: firefox-core-security
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 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) {

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

Would it be possible for you to do this?
Group: firefox-core-security
Flags: needinfo?(seocam)
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)

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

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:
Flags: needinfo?(seocam)
Component: Untriaged → Security: PSM
Product: Firefox → Core
According to comment 4, this might have been caused by bug 1317947.
Blocks: 1317947
Ever confirmed: true
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)
Flags: needinfo?(seocam)
It works fine when I set "security.tls.version.max" to 3.
Just tried in Chrome Version 57.0.2979.0 canary (64-bit) and it also works fine.
Flags: needinfo?(seocam)
Interesting - so it doesn't seem to be quite the same problem. In any case, this is an NSS issue.
Assignee: nobody → nobody
Component: Security: PSM → Libraries
Product: Core → NSS
Version: 53 Branch → trunk
This is the same issue as bug 1328101 (a TLS 1.3 incompatibility caused by something Cloudflare does).
Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1328101
You need to log in before you can comment on or make changes to this bug.