1658183 - "RPMSendQuery is not defined" error on about:certificate

Status: UNCONFIRMED

(Firefox :: Security, defect, P3)

Description

[edward.a.cheney.mil]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0

Steps to reproduce:

1. Using HTTPS and web sockets with a self-signed certificate. The site comes up as untrusted, which is expected behavior.
2. Click the lock icon for the site.
3. Click the arrow next to the lock to view more information.
4. There is a button for "More Information" which launches a new tab to "about:certificate". Click this button.

Actual results:

In the "about:certificate" page nothing displays due to a JavaScript error, stack trace:

render chrome://global/content/certviewer/components/about-certificate-section.js:37
connectedCallback chrome://global/content/certviewer/components/about-certificate-section.js:33
render chrome://global/content/certviewer/certviewer.js:419
AsyncFunctionNext self-hosted:684

Expected results:

No JavaScript error on about:certificate

I believe this certificate error is breaking secure web sockets. Web sockets fail to connect as protocol WSS to a second web service using the same certificate. The site loads from HTTPS correctly but the handshake to WSS fails.

I will mark this defect as a security defect. This is immediately attributable to a self-signed certificate, but I don't know what the second order consequences are or if it limited in scope to self-signed certificates.

Comment 1

[Daniel Veditz [:dveditz]]

Where do web sockets come into this? This is what I tried to reproduce (note extra step):

1. Go to https://self-signed.badssl.com/ which, as advertised, has a self-signed cert
2. without adding an exception (because you didn't mention it), on the error page click the lock icon with the warning triangle in the URL bar
3. Click the ">" arrow on the line with the lock and the words "Connection not secure"
4. Click the "More Information" button at the bottom of the panel
5. the Page Info dialog comes up. click the "View Certificate" button

result: about:certificate tab opens up just fine

I got a different result, but I also had to take an extra step than you described so maybe I didn't do quite what you did? Could be a parsing error with that particular certificate -- is the site available in public?

An error in about:certificates sounds very different from an error connecting to a web socket. There could be two completely different bugs here.

You say the site loads from HTTPS correctly, but also that it's self-signed. So somewhere along the way you did grant the exception? Exceptions are tied between a certificate and a hostname. Granting the exception on one site won't make a second site magically work with the same certificate. If we did that people could convince people to grant an exception to a throw-away site with cute cats/porn/conspiracies/get-rich-schemes or whatever, and then once granted use that certificate to MITM the sites you did care about.

We ought to treat https://foo.example.com as the same site as wss://foo.example.com and carry that exception over, because there's no affordance to grant an exception to a websocket connection. But maybe we don't and that's one of the bugs? But we definitely won't carry the exception over if it's https://foo.example.com and wss://bar.example.com, even if it's a wildcard *.example.com cert. We don't care what's in the cert -- we've determined it's invalid and don't trust any of it.

Comment 2

[:Gijs (he/him)]

So the bizarre thing here is it works for me, but I don't understand why.

about:certificate takes a query param that contains the cert data.

In bug 1650468, we had to update some of the matching criteria for about:protections (different about: page) so that some of our internal APIs continued to be available when such a page was opened with query parameters (see also https://mozilla.slack.com/archives/C4CCU4WPK/p1595843290033400 and try manually opening about:protections?entryPoint=snippets in 80 beta or earlier).

But AFAICT the listings at https://searchfox.org/mozilla-central/rev/e07d5eb5646b40b10df3164e315d4a3108cf9101/toolkit/modules/ActorManagerParent.jsm#81 and https://searchfox.org/mozilla-central/rev/e07d5eb5646b40b10df3164e315d4a3108cf9101/toolkit/modules/RemotePageAccessManager.jsm#71-73 also do not allow for a query param. So why does about:certificate work for me (but not the reporter) ?

Neil, you've looked at the conversions to window actors here, can you take a look?

(FWIW, I don't think this is needs to be security-sensitive, but happy to keep it like this until we understand the web sockets side better.)

Comment 3

[Neil Deakin]

The 'AboutCertificateSection' type only get used when one goes to the main about:certificate page (no query string). A different object 'CertificateSection' gets used when viewing a specific certificate (with a query string). The RPMSendQuery call only applies to the former.

This is done at https://searchfox.org/mozilla-central/rev/e07d5eb5646b40b10df3164e315d4a3108cf9101/toolkit/components/certviewer/content/certviewer.js#411

So, somehow, this code is being invoked as 'about:certificate?' with the question mark but without the cert query parameter. I can reproduce the exact error message described by typing this into the url bar, but not with any other format.

The code that generates the url I think is at https://searchfox.org/mozilla-central/rev/e07d5eb5646b40b10df3164e315d4a3108cf9101/browser/actors/NetErrorParent.jsm#351, which could generate this state as long as the certificate wasn't available. This information ultimately comes from docShell.failedChannel.securityInfo. I would suspect that the reporter is using a url form that translates into a channel that doesn't provide the needed security info.

Maybe this situation should be handled more gracefully by at least showing the generic certificate error failure message.

Comment 4

[edward.a.cheney.mil]

All,

You are following the same steps. The step you indicated in bold text I had failed to mention. And yes, I did get the warning page about an untrusted certificate and agreed to load the page anyways.

There is only one site, but there are two HTTP services because the second HTTP service provides the web socket support. For example I load the page with HTTPS on default port 443 and once the page loads I activate web sockets using protocol 444 on my second HTTP service. Both HTTP services make use of the same certificate set, which shouldn't be a problem, both are limited to hostname: localhost, example:

• https://localhost
• wss://localhost:444

The wss handshake fails every time. I suspect, though there is no evidence supporting this, the WSS fails because actions on the certificate are broken and thus no additional connections that make use of that certificate will work. Strangely though I can XHR to https://localhost and receive the intended response.

As for the site that is producing this error it is publicly available, but not on the web. Its part of an open source peer-to-peer serverless NAS/privacy application I am writing. If you want to reproduce it from the application you would have to go through the headache of installing TypeScript and building out the application.

https://github.com/prettydiff/share-file-systems/tree/5f63968815f90cd87e05b027e45d9c8dea15968e

Repo: https://github.com/prettydiff/share-file-systems/
Branch: browser
Commit: 5f63968815f90cd87e05b027e45d9c8dea15968e

Comment 5

[:Gijs (he/him)]

(In reply to Neil Deakin from comment #3)

Thanks for clarifying!

The code that generates the url I think is at https://searchfox.org/mozilla-central/rev/e07d5eb5646b40b10df3164e315d4a3108cf9101/browser/actors/NetErrorParent.jsm#351, which could generate this state as long as the certificate wasn't available. This information ultimately comes from docShell.failedChannel.securityInfo. I would suspect that the reporter is using a url form that translates into a channel that doesn't provide the needed security info.

Hm. But if securityInfo is null, the code in question throws and doesn't manage to load about:certificate at all. So presumably we get a valid object that implements nsITransportSecurityInfo but without any cert info? Dana, any idea why that'd happen?

Maybe this situation should be handled more gracefully by at least showing the generic certificate error failure message.

Yeah... though I'm also still confused how we get to this point.

Comment 6

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

From my reading of that code, this can only happen if securityInfo.failedCertChain is an empty array. This field gets set here: https://searchfox.org/mozilla-central/rev/ab81b8552f4aa9696a2524f97fdfeb59d4dc31c1/security/manager/ssl/SSLServerCertVerification.cpp#1067 when certificate verification fails. These certificates come from NSS and there will always be at least one: https://searchfox.org/mozilla-central/rev/ab81b8552f4aa9696a2524f97fdfeb59d4dc31c1/security/manager/ssl/SSLServerCertVerification.cpp#1446
I suppose this could happen if this page somehow gets loaded for a successful connection, in which case securityInfo.failedCertChain will be empty. But I don't know how that could happen either.

Comment 7

[edward.a.cheney.mil]

Today my computer restarted, perhaps due to a Windows patch update. Upon trying the application again I cannot reproduce this certificate error, such that about:certificate page now loads without error.

However, WSS handshake still fails. The HTTPS and WSS connections use the same certificates. Both are services spawned from the same application on hostname "localhost". WSS works from this application on other browsers.

Comment 8

[Daniel Veditz [:dveditz]]

These seem like normal bugs, not an indication of a security problem that can be used to harm other users.