1678492 - getSecurityInfo() on self-signed/"ToFU" connections lacks .certificates

Status: NEW

(WebExtensions :: Request Handling, defect, P3)

Description

[James E. A. (any) [:codegeek98]]

Attachment: Screenshot from 2020-11-19 18-38-43.png

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:82.0) Gecko/20100101 Firefox/82.0

Steps to reproduce:

1. 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).

2. 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".

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

Comment 1

[James E. A. (any) [:codegeek98]]

(I've made a typo: the first line under “Actual results” should begin “securityInfo.isTrusted will be set to false…”)

Comment 2

[Alex Cornestean]

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 !

Comment 3

[James E. A. (any) [:codegeek98]]

Attachment: certPrint.xpi

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.

Comment 4

[James E. A. (any) [:codegeek98]]

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

[Tom S [:evilpie]]

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

[Alex Cornestean]

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

[Luca Greco [:rpl] [:luca] [:lgreco]]

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.

Comment 8

[Tom S [:evilpie]]

Attachment: Bug 1678492 - Also provide a failed certificate chain in getSecurityInfo. r?rpl

Comment 9

[Luca Greco [:rpl] [:luca] [:lgreco]]

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