This patch sets the preference order for `TLS_CHACHA20_POLY1305_SHA256` over `TLS_AES_128_GCM_SHA256` for ARM builds.
As noted in the bug, this is far from an ideal way to do this. The implementation is purposefully simplistic so as to minimize any performance hit. If we want to accept doing this configuration for every new TLS connection, `SSL_CipherSuiteOrderGet` **will** return the pref-filtered (i.e. only the enabled) ciphers, but in the default NSS order. We would have to build a new list by referencing this output with another ordered list defined in PSM. If we want to leave NSS as-is (instead of offering a global reconfiguration API), we should do this.
Differential Revision: https://phabricator.services.mozilla.com/D47485
--HG--
extra : rebase_source : 0252cf321225cd644a463fd94561fd6af38b3837
extra : source : 4836c05dd2eee11bf9d836fb0505e77450b0651b
This patch sets the preference order for `TLS_CHACHA20_POLY1305_SHA256` over `TLS_AES_128_GCM_SHA256` for ARM builds.
As noted in the bug, this is far from an ideal way to do this. The implementation is purposefully simplistic so as to minimize any performance hit. If we want to accept doing this configuration for every new TLS connection, `SSL_CipherSuiteOrderGet` **will** return the pref-filtered (i.e. only the enabled) ciphers, but in the default NSS order. We would have to build a new list by referencing this output with another ordered list defined in PSM. If we want to leave NSS as-is (instead of offering a global reconfiguration API), we should do this.
Differential Revision: https://phabricator.services.mozilla.com/D47485
--HG--
extra : moz-landing-system : lando
The intent of adding this pref is to allow us to change defaults for
security.tls.version.min for a progressive rollout of a TLS 1.0 and 1.1
deprecation. During that process, we'd like to offer the option to enable these
old TLS versions, without adding a pref override that would cause those versions
to remain enabled once we finish the rollout.
Those people who have triggered the override will be able to access TLS 1.0 and
1.1 sites until we eventually remove the code that respects this pref. What is
likely to happen is that this pref will remain in code past the end of our
rollout for part of a release cycle, plus maybe the next cycle depending on
how timing works out.
This pref is a simple boolean that we'll remove in March 2020.
Differential Revision: https://phabricator.services.mozilla.com/D45798
--HG--
extra : moz-landing-system : lando
The intent of adding this pref is to allow us to change defaults for
security.tls.version.min for a progressive rollout of a TLS 1.0 and 1.1
deprecation. During that process, we'd like to offer the option to enable these
old TLS versions, without adding a pref override that would cause those versions
to remain enabled once we finish the rollout.
Those people who have triggered the override will be able to access TLS 1.0 and
1.1 sites until we eventually remove the code that respects this pref. What is
likely to happen is that this pref will remain in code past the end of our
rollout for part of a release cycle, plus maybe the next cycle depending on
how timing works out.
This pref is a simple boolean that we'll remove in March 2020.
Differential Revision: https://phabricator.services.mozilla.com/D45798
--HG--
extra : moz-landing-system : lando
This patch makes the certificate authentication work with TransportSecurityInfo, so that it can be used for nsNSSSocketInfo and a quic's version of the security info class.
Also it adds a new AuthCertificateHookWithInfo function that will be called by Http3Session to authenticate certificates.
Differential Revision: https://phabricator.services.mozilla.com/D44064
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
Differential Revision: https://phabricator.services.mozilla.com/D46642
--HG--
extra : moz-landing-system : lando
Using left shift on a uint8_t promotes it to a signed integer. If the shift is
large enough that the sign bit gets affected, we have undefined behavior. This
patch fixes this by first casting to uint32_t.
Differential Revision: https://phabricator.services.mozilla.com/D46820
--HG--
extra : moz-landing-system : lando
CERT_FindUserCertsByUsage is inefficient when the corpus of known certificates
consists mostly of certificates that don't have corresponding private keys,
which is expected to be the case for most Firefox users. This change updates
the "does the user have any client certificates" functionality to use the more
efficient "FindNonCACertificatesWithPrivateKeys" function added in bug 1573542.
Differential Revision: https://phabricator.services.mozilla.com/D46499
--HG--
extra : moz-landing-system : lando
Before this patch, Firefox would call CERT_FindUserCertsByUsage to gather all
known client certificates. This function enumerates all known certificates and
filters some of them out. When there are many certificates that are not client
certificates (e.g. roots and intermediates), this is inefficient. Since this is
likely to be the case for most users, this patch optimizes this task by instead
first searching for private keys and then gathering all certificates that have
corresponding public keys.
Differential Revision: https://phabricator.services.mozilla.com/D46187
--HG--
extra : moz-landing-system : lando
If code acquires a handle on the certificate verifier before the loadable roots
background task completes, that instance of the verifier may not know about any
enterprise certificates loaded, and so early certificate verifications relying
on those certificates may fail. To prevent this, this patch ensures that the
background task has completed before returning the handle. Note that there
should be no effect on performance since CertVerifier already ensures that the
background task has completed internally before looking for potential issuer
certificates.
Differential Revision: https://phabricator.services.mozilla.com/D46224
--HG--
extra : moz-landing-system : lando
Calling CERT_NewTempCertificate on an enterprise certificate is inefficient
because NSS tries (and fails) to find a copy of that certificate in its internal
data structures (which includes querying softoken, which involves hitting the
disk). We can avoid doing so for these certificates in
NSSCertDBTrustDomain::GetCertTrust because we already know what trust values
they should have (after checking the relevant blocklists).
Differential Revision: https://phabricator.services.mozilla.com/D45588
--HG--
extra : moz-landing-system : lando
about:certificate is always trusted and we don't have to use the content principal in browser.js
Differential Revision: https://phabricator.services.mozilla.com/D45939
--HG--
extra : moz-landing-system : lando
This patch adds a new `mIsDelegatedCredential` parameter to nsITransportSecurityInfo, indicating whether or not a delegated credential keypair was used in the TLS handshake (see: https://tools.ietf.org/html/draft-ietf-tls-subcerts-03) .
This functionality is only available if _security.tls.enable_delegated_credentials_ is set to true.
Differential Revision: https://phabricator.services.mozilla.com/D39807
--HG--
extra : moz-landing-system : lando
Anny Gakhokidze
Kershaw Chang
Gabriele Svelto
Kevin Jacobs
Ciure Andrei
ffxbld
Aaron Klotz
dleblanccyr
Martin Thomson
Coroiu Cristina
Tim Nguyen
Carolina
Victor Porof
Dragana Damjanovic
Brian Grinstead
Daniel Varga
Mihai Alexandru Michis
Kris Maglione
Geoff Brown
Dana Keeler
Cosmin Sabou
Zibi Braniecki
Henri Sivonen
Johann Hofmann
Sean Feng