getSecurityInfo() on self-signed/"ToFU" connections lacks .certificates
Categories
(WebExtensions :: Request Handling, defect, P3)
Tracking
(firefox83 affected, firefox84 affected, firefox85 affected)
People
(Reporter: codegeek98, Unassigned)
Details
Attachments
(2 files, 1 obsolete file)
User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:82.0) Gecko/20100101 Firefox/82.0
Steps to reproduce:
-
Start up any non-PKI-validated HTTPS server (such as a free-running ESXi instance, the Web UI of a network router not attached to any management infrastructure, or a .mil website on a system that only recognizes Mozilla-recognised CAs).
-
Visit the site in Firefox; add the certificate in ToFU-validated mode (i.e. Firefox will warn you in the future iff the certificate ever changes) by clicking "Accept the Risk and Continue".
-
Have any Add-On run webRequest.getSecurityInfo() on a request to that server, and attempt to access the resulting securityInfo.certifcates
Actual results:
securityInfo.untrusted will be set to false, indicating that Firefox's built-in PKI-based validation could not verify the server's certificate.
However, securityInfo.certificates will be a zero-length Array, depriving the calling Add-On of any chance to independently inspect or report on the status of the server's certificate or certificate chain.
All of the other important properties (cipherSuite, state, hpkp, etc.) are included; however, certificates is missing.
Expected results:
securityInfo.certificates should, just like all other properties (cipherSuite, state, hpkp, etc.) be present on isUntrusted connections and contain correct information about the connection's security.
Reporter | ||
Comment 1•4 years ago
|
||
(I've made a typo: the first line under “Actual results” should begin “securityInfo.isTrusted will be set to false…”)
Comment 2•3 years ago
|
||
Hello!
I am Alex from QA and I am trying to confirm the validity of this bug.
Unfortunately I am not sure how to set up the prerequisites for this issue and I will need detailed instructions for every step if possible.
Thank you !
Reporter | ||
Comment 3•3 years ago
|
||
To use, go to (about:debugging), (This Firefox), (Load Temporary Add-On), select the file, click (Inspect); then, load various pages, especially https://self-signed.badssl.com/ and return to the logs. Note especially that securityInfo objects printed via "warn" (orange, with an exclamation point) have an empty .certificates array, despite the certificate chain existing.
Reporter | ||
Comment 4•3 years ago
|
||
Alex,
Sorry about the previous comment's terseness—I did not realize the attached text would present as a full-fledged comment—I've attached a quick proof-of-concept that will print out the securityInfo objects to the debugging log on each request.
Use it to observe the results of getSecurityInfo() across a variety of websites, but especially those self-signed or otherwise non-PKI-validated/trust-on-first-use, and you'll see that Add-Ons are denied access to the certificate chains of such connections, despite the fact that these certificate chains are present and viewable via e.g. Page Info > Security > View Certificate
A very good "test website" is https://untrusted-root.badssl.com/ — Firefox will display this site's certificate chain to the user on request, but will not provide it to Add-Ons using webRequest.getSecurityInfo().
Comment 5•3 years ago
|
||
Thanks for the test extension. The problem is in SecurityInfo.jsm
.
When the certificate is untrusted, but allowed, we need to use the failedCertChain
instead of the succeededCertChain
here. Should be a relatively simple change if someone is interested.
Comment 6•3 years ago
|
||
Hello,
Thank you for the detailed steps !
Based on the provided info, I managed to reproduce the issue on the latest Nightly (85.0a1/20201125214909), Beta (84.0b4/20201122152513) and Release (83.0/20201112153044) under Windows 10 Pro 64-bit and Ubuntu 16.04 LTS.
Tested with both provided websites and indeed the certificates
array is empty.
I’ve also attempted to find whether the issue is a regression, so I’ve run a bisection ranging from 2018-01-01 until the present day. However, I have only managed to narrow the window between 2019-10-29 (last good build) and 2019-10-30 (first bad build) as the regression tool kept failing with errors.
This is the pushlog corresponding to the mentioned range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c65ef27b6fc78ec5140068913209bad3b55f1139&tochange=f68c212c8b2a39cb6e26e17477a8d848e19cd6d3 .
Comment 7•3 years ago
|
||
The requests seems reasonable, and evilpie did already mention what may be necessary to fix the issue in comment 5.
Needinfo-ing myself to look if we can also make this a "good first" mentored bug.
Updated•3 years ago
|
Comment 8•3 years ago
|
||
Comment 9•3 years ago
|
||
Clearing needinfo assigned to me (Tom attached a patch which is being reviewer by Shane, and so it can't be marked as a mentored good first bug anymore).
Updated•2 years ago
|
Updated•2 years ago
|
Description
•