TLSv1.3 + must_staple can make the lock-icon nonclickable
Categories
(Core :: Security: PSM, defect)
Tracking
()
People
(Reporter: pmc, Unassigned)
Details
(Whiteboard: QA-not-reproducible)
User Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0
Steps to reproduce:
- Connect to a site running an application with TLSv1.3 and a cert that is forcing must_staple
- Click Log-in
- enter credentials
The behaviour involves apparently undefined data in the UI, and is therefore erratic. It could be reproduced by a volunteer in the support forum with a test site I provided: https://flag.daemon.contact/flowm/
The full description is here: https://support.mozilla.org/en-US/questions/1350861
The behaviour was reproduced with versions 73.x up to 93.0b8.
Actual results:
Clicking the lock icon in the address-bar has no effect anymore.
(Consequentially, users might think the contacted site had somehow damaged/hacked the firefox!)
Expected results:
The lock icon should open a dropdown showing security information, and also allow to click onwards to display the certificate of the site.
Additional Info - Analysis:
When loading a page with many ressources, firefox opens additional connections to the server, to fetch files in parallel.
These connections do carry the 0x5 TLS extension (OCSP stapling), and they do invoke TLS verification. When verification fails, however, these connections are not necessarily abandoned.
When must_staple is set in the certificate, the TLS verification will also invoke TLSFeaturesSatisfiedInternal().
For TLSv1.2 this works. With TLSv1.3 this results in error ERROR_REQUIRED_TLS_FEATURE_MISSING because the OCSPStapling response appears not to be available.
A perceivable difference is that with TLSv1.3 these additional connections are opened with TLS extension 0x29 (pre_shared_key), which is not the case with TLSv1.2.
The consequence of the failing verification is not an abandonment of that additional connection, neither is it reported to anywhere. Nevertheless, the consequence is that Firefox does not copy the certificate data onwards.
At a subsequent change of the security context, e.g. when a new cookie is received, in the case when the TCP connections did stay open (a new TLS negotiation did NOT happen), this certificate data (that was NOT copied and therefore is probably undefined) is relied on from UI code.
At that point it may appear that the lock icon is rendered nonfunctional, and no certificate data at all is shown.
Additional Info - Compatibility:
The defective behaviour was reproduced with:
- Firefox 73.x (Linux)
- Firefox 78.12.0ESR (FreeBSD)
- Firefox 91.x (FreeBSD)
- Firefox 93.0b8 (Linux)
The defective behaviour, while appearing erratically, seems to appear more likely with a pristine profile.
|
||
Comment 3•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Site Identity' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Additional Info - Debugging
On STDERR we can see this message after the lock icon was clicked unsuccessfully:
JavaScript error: chrome://browser/content/browser-siteIdentity.js, line 642: TypeError: issuerCert is undefined
In the Browser Toolbox we can observe these two variables; they become empty arrays before the defect appears:
gBrowser.securityUI.secInfo.succeededCertChain: (0) []
gIdentityHandler._secInfo.succeededCertChain: (0) []
In MOZ_LOG we can see this message, one pageload BEFORE the defect appears:
D/pipnss HandshakeCallback: couldn't rebuild verified certificate info
(This appears once for each additional socket/connection to the server.)
Hi
i tried to reproduce using Ubuntu 20 64bit. I was able to login with firefox 93.0b9 and the lock button responded.
Can you check with the latest nightly version?
Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/
thanks
Pablo, thank You for looking into this.
With 93.0b9 I CAN reproduce the lock-icon problem (after various tries). More easily I can observe those messages (which seem pre-indicative of the problem):
$ MOZ_LOG=pipnss:4 ./firefox 2>&1 | grep HandshakeCallback
[Parent 2753: SocketThread]: D/pipnss HandshakeCallback: couldn't rebuild verified certificate info
However, with "Nightly" I get a 94.0a1 version, and with that I do NOT see these messages, and I can NOT reproduce the lock-icon problem. In other words, that one seems to work well.
|
|
||
Comment 7•3 years ago
|
||
The severity field is not set for this bug.
:pbz, could you have a look please?
For more information, please visit auto_nag documentation.
|
||
Comment 8•3 years ago
|
||
I can reproduce this on FF release on Ubuntu.
Opening the identity popup fails, because succeededCertChain is the empty array here: https://searchfox.org/mozilla-central/rev/b822a27de3947d3f4898defac6164e52caf1451b/browser/base/content/browser-siteIdentity.js#752
We could handle this more gracefully in the frontend. However the root cause probably lies somewhere in PSM so I'm moving the bug there.
What's the value of network.ssl_tokens_cache_enabled in about:config?
|
Reporter | |
Comment 10•3 years ago
|
||
@Paul Zuehlke:
Thank You for the confirm on the location. I also agree with Your conclusion: this could be caught in the UI, but should also be checked at the place where it originally happens.
Sadly I failed to fully unravel where and how you do the TLS (too big).
@Dana Keeler:
Due to Quarterly Maintenance I now have 78.15.0esr as standard, and I can reproduce the flaw with it, and the 'network.ssl_tokens_cache_enabled' is currently 'false'.
I don't remember touching that one, so it likely was the delivered default everywhere.
Looking closer... it's "false" for 93 and "true" for 94.
So that figures. :) And works for the 78/esr also. :)
So things will now likely just resolve in due time. This could have been solved faster. But then, why did nobody else ever notice it in all the time? Don't people look at the certificates?
|
|
||
Comment 11•3 years ago
|
||
The severity field is not set for this bug.
:keeler, could you have a look please?
For more information, please visit auto_nag documentation.
Description
•