1373791 - Cannot connect to wss websocket server

Status: RESOLVED WONTFIX

(Core :: Security: PSM, defect)

Description

[Gabriel Pessoa]

Attachment: Firefox54Websocket.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.104 Safari/537.36

Steps to reproduce:

Up until version 53.0.3 we could connect to a Java Jetty local Websocket server application through a self-signed certificate created with keytool, after the update to version 54, it stopped working. It still works on Chrome 59.0.3071.104 and Edge 40.15063.0.0.

The problem occurred on a updated version of Firefox 54 from 53.0.3 and also 52.0, and also on a clean install of Firefox 54 and 55.0 Beta2 (clean as complete removal of the Mozilla folder in Program Files and in the Appdata subfolders).

The Javascript for establishing the connection:
var ws = new WebSocket('wss://localhost:57201/');

The Keytool command:
keytool -genkey -noprompt -alias brysignerwebroot -keyalg RSA -keysize 2048 -dname "CN=localhost, EMAILADDRESS=[e-mail], OU=Gerado por BRy Signer Web para websocket seguro, O=BRy Tecnologia S.A., L=Florianopolis, S=BR, C=SC" -validity 7305 -keystore "brysignerwebroot.jks" -storepass 123456 -keypass 123456 -ext san=dns:localhost -ext KeyUsage:critical="digitalSignature,keyEncipherment" -ext EKU="serverAuth"

The export command:
keytool -exportcert -alias brysignerwebroot -keystore "brysignerwebroot.jks" -storepass 123456 -keypass 123456-file "brysignerwebroot.crt" -rfc

Then we used the "general.config.filename" property to point to a configuration file that installed the certificate generated from the exportcert and parsed to Base64 into the Firefox keystore.

The installing command in the config file:
certdb.addCertFromBase64("BASE64", "C,C,C", "localhost - BRy Tecnologia S.A.");

Attached are some print screens, the configuration files, and the log generated from according to https://developer.mozilla.org/pt-BR/docs/Mozilla/Debugging/HTTP_logging setting the flag for logging WebSockets.


Actual results:

Cannot connect with the Jetty Websocket server. Firefox console prints:

"Firefox could not establish a connection with the server wss://localhost:57201/."

The information panel about the certificate says: "Could not verify this certificate because the issue is unknown."


Expected results:

It should connect with the Jetty Websocket server.

The information panel about the certificate should be the same as it was on 53.0.3 and previous versions: "This certificate has been verified for the following uses: SSL Server Certificate".

Comment 1

[Kohei Yoshino [:kohei]]

It sounds like a regression from Bug 1294580 as referenced from https://stackoverflow.com/q/44550970/5693076

Comment 2

[Loic]

David, is it the expected behaviour?

Comment 3

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

(In reply to Loic from comment #2)
> David, is it the expected behaviour?

Essentially, yes. This was never an intended feature and so we removed this particular capability in bug 1294580.

Gabriel, how do you configure Chrome and Edge to connect to your Jetty server? Does setting the about:config preference "security.enterprise_roots.enabled" to true in Firefox fix it? Does the documentation at http://www.eclipse.org/jetty/documentation/9.4.6.v20170531/configuring-ssl.html help?

Comment 4

[Gabriel Pessoa]

Attachment: bank.zip

Certificate and configuration file for brazilian banks securitu module.

Comment 5

[Gabriel Pessoa]

(In reply to David Keeler [:keeler] (use needinfo?) from comment #3)
> (In reply to Loic from comment #2)
> > David, is it the expected behaviour?
> 
> Essentially, yes. This was never an intended feature and so we removed this
> particular capability in bug 1294580.
> 
> Gabriel, how do you configure Chrome and Edge to connect to your Jetty server?

We use Windows certutil: certutil.exe -addstore -f "Root" brysignerwebroot.crt.

> Does setting the about:config preference "security.enterprise_roots.enabled" to true in Firefox fix it?

No.

> Does the documentation at http://www.eclipse.org/jetty/documentation/9.4.6.v20170531/configuring-ssl. html help?

No, but I think because we cannot even create a connection with the Jetty server.

***
On a side note: brazilian banks use a "security module" that is basically a Websocket to allow clients to use their digital certificates on the bank website.

Their certificate is installed in windows and firefox root and still shows as valid and working after the update to version 54. I attached the files generated during their install.

I uninstalled our application first because there is a conflict in both trying to use the "general.config.filename" preference at the same time.

Comment 6

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

Thank you for the information. Looking at that autoconfig, it *is* attempting to install a root certificate, so this isn't due to the changes in bug 1294580. I'll keep investigating (given that the installer is using certutil, "security.enterprise_roots.enabled" should work, but it looks like it doesn't for some reason). Can you attach a log with the pipnss and certverifier logs enabled? (rather than the nsHttp* logs)

Comment 7

[Gabriel Pessoa]

Attachment: log.txt-main.2216

Parameters: timestamp,sync,pipnss:5,certverifier:5

Comment 8

[tres.finocchiaro]

> how do you configure Chrome and Edge to connect to your Jetty server? Does setting the about:config preference "security.enterprise_roots.enabled" to true in Firefox fix it? Does the documentation at http://www.eclipse.org/jetty/documentation/9.4.6.v20170531/configuring-ssl.html help?

This is not a cross-platform solution though right?

> Looking at that autoconfig, it *is* attempting to install a root certificate, so this isn't due to the changes in bug 1294580.

I've reviewed the source of the attachment in this bug report and the code which inserts the certificate is an exact duplicate of what inspired https://stackoverflow.com/questions/44550970.  The OP's company copied our source code as can be found here: https://github.com/qzind/tray/blob/2.0/ant/firefox/firefox-config.cfg.in so I suppose it depends how you look at this problem.  The trouble I'm having (as well as the OP) is that there doesn't seem to be a non-CA chained way of inserting a trusted certificate.  This is why the issue was originally asked about in bug 1324096 to see if this was a matter of non-CA self-signed certificates being "grandfathered" into the Mozilla-CA-Policy.

Speaking on behalf of an ISV that needs to trust a certificate, either solution (Root-CA style cert or simply self-signed non-CA cert) are acceptable but adding in an intermediate would be a considerable effort.  I hope this information helps the discussion.

Comment 9

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

(In reply to Gabriel Pessoa from comment #7)
> Created attachment 8879265 [details]
> log.txt-main.2216
> 
> Parameters: timestamp,sync,pipnss:5,certverifier:5

Thank you. Unfortunately, that doesn't seem to include logging during startup or when verifying a certificate for "localhost", which is what I'm looking for. Also, perhaps try with "pipnss:4", since that won't include some unnecessary extra output.

(In reply to tres.finocchiaro from comment #8)
> > how do you configure Chrome and Edge to connect to your Jetty server? Does setting the about:config preference "security.enterprise_roots.enabled" to true in Firefox fix it? Does the documentation at http://www.eclipse.org/jetty/documentation/9.4.6.v20170531/configuring-ssl.html help?
> 
> This is not a cross-platform solution though right?

Correct - this is only available on Windows at the moment.

> > Looking at that autoconfig, it *is* attempting to install a root certificate, so this isn't due to the changes in bug 1294580.
> 
> I've reviewed the source of the attachment in this bug report and the code
> which inserts the certificate is an exact duplicate of what inspired
> https://stackoverflow.com/questions/44550970.  The OP's company copied our
> source code as can be found here:
> https://github.com/qzind/tray/blob/2.0/ant/firefox/firefox-config.cfg.in so
> I suppose it depends how you look at this problem.  The trouble I'm having
> (as well as the OP) is that there doesn't seem to be a non-CA chained way of
> inserting a trusted certificate.

This is intentional. Currently the two supported methods of modifying trust for TLS connections are a). install a new root certificate or b). add an exception override on a per-host/per-certificate basis. Depending on the needs of the community, we may explore other options (it would be best to have this discussion on the enterprise mailing list, however: https://mail.mozilla.org/listinfo/enterprise ).

> This is why the issue was originally asked
> about in bug 1324096 to see if this was a matter of non-CA self-signed
> certificates being "grandfathered" into the Mozilla-CA-Policy.

I don't understand what you mean by this.

> Speaking on behalf of an ISV that needs to trust a certificate, either
> solution (Root-CA style cert or simply self-signed non-CA cert) are
> acceptable but adding in an intermediate would be a considerable effort.  I
> hope this information helps the discussion.

Installing a new root CA should work. Adding an intermediate shouldn't be necessary. Perhaps if you opened up a new bug and explained the details of your setup we could figure out what's going on and maybe get your system working again: https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Security%3A%20PSM

Comment 10

[Gabriel Pessoa]

Attachment: log.txt-main.4664.zip

Parameters: timestamp,sync,nsSocketTransport:5,nsStreamPump:5,nsHostResolver:5,pipnss:4,certverifier:5

Comment 11

[tres.finocchiaro]

> Installing a new root CA should work. Adding an intermediate shouldn't be necessary.

Can you please explain?  Bug 1294580 says a CA can't be it's own end-entity, so how then would one trust a cert without making a separate, intermediate certificate to ensure the end-entity differs from the CA cert?  I attempted to use a Root CA without intermediate per my response to David here: https://stackoverflow.com/a/44577475/3196753

> add an exception override on a per-host/per-certificate basis.

Understood, but the use-case of this is problematic.  It requires an XHR to happen to the endpoint which requires the endpoint to be alive and listening at exact point of whitelisting.  It also requires a separate XHR for each request.

> may explore other options (it would be best to have this discussion on the enterprise mailing list, however: https://mail.mozilla.org/listinfo/enterprise ).

Duly noted.

> Correct - this is only available on Windows at the moment.

Unfortunately that makes it a non-starter.

> Perhaps if you opened up a new bug and explained the details of your setup we could figure out what's going on 

I'm sorry if my previous reply wasn't clear, but the source code in this bug report was written by myself and myself only, so this is the correct place for discussion.  The OP's company must have found our technique on the internet, but the use-case, impact and resolution will be identical.

Comment 12

[tres.finocchiaro]

> the source code in this bug report was written by myself and myself only

Correction... credit where credit is due, it also borrows from the Mozilla wiki as well as Mike Kaply's examples.  Sorry if that statement was misleading.

Comment 13

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

Tres, I was working on a response here when I looked back at the stackoverflow post, and it looks like you've got your setup working. Is there anything else I can make more clear?

Comment 14

[tres.finocchiaro]

The OP and I are joining forces to move our products away from self-signed certificates in general, since Firefox has made no indication of supporting this configuration.

Comment 15

[Liz Henry (:lizzard) (relman/hg->git project)]

David, should we wontfix this bug? Thanks.

Comment 16

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

I think we can wontfix this for now. There's potentially still an open question of if we have sufficient platform support for the relevant use-cases in the enterprise community, but we can have that discussion on the mailing list.

Tres - I appreciate your patience here. Let me know if there's anything further I can do to help.

Comment 17

[kirill]

We use self-signed certificate on Windows (including Windows 10), Mac OSX (including Sierra) with Chrome, Internet Explorer, MS Edge and Firefox and it works for all these configurations excepting Firefox beginning from version 54. Our product needs this functionality and we have to notify our customers that beginning from FF 54 we don't support Firefox. Hope you will decide to fix this issue in the future versions and make it work similar to all other web browsers

Comment 18

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

Did you try the steps outlined in https://stackoverflow.com/questions/44550970/firefox-54-stopped-trusting-self-signed-certs ?