| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
tlsfuzzer/test-tls13-signature-algorithms.py r=nss-reviewers,bbeurdouche
We recently updated tlsfuzzer so that we could enable a test for Bug 1662515.
Since that update we've been seeing intermittent failures for
tlsfuzzer/test-tls13-signature-algorithms.py, which is a bit surprising as
our config labels this test as "exp_pass: false". This patch aligns our
selfserv configuration for the tls13-sig-algs test with the requirements of
the test, and should fix the issue, but there are clearly some other
underlying problems here.
Differential Revision: https://phabricator.services.mozilla.com/D124825
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug 1707130 Fixed the base issue with Camellia, but now it has the same issue
as AES did which was fixed in Bug 1268141.
The fix is to generalize the AES patch, recognizing the issue isn't AES
specific but an issue for any case where we encode the keysize into the
oid, but the oid maps to the same PKCS #11 mechanism.
This patch condenses a lot of the original AES fix, collecting several blocks
of common code into single functions, and putting one place where the key
sizes of pkcs5v2 algorithms with different oids with keys size specific
to those oids, but their mechanism maps to a single PKCS #11 mechanism
live. This means future algorithms can be handled easily.
bob
|
|
|
|
|
|
| |
Depends on D124568
Differential Revision: https://phabricator.services.mozilla.com/D124569
|
|
|
|
|
|
| |
Depends on D124567
Differential Revision: https://phabricator.services.mozilla.com/D124568
|
|
|
|
|
|
| |
Depends on D124566
Differential Revision: https://phabricator.services.mozilla.com/D124567
|
|
|
|
|
|
| |
Depends on D124565
Differential Revision: https://phabricator.services.mozilla.com/D124566
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D124565
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
r=bbeurdouche,djackson
Differential Revision: https://phabricator.services.mozilla.com/D123652
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D90107
|
|
|
|
|
|
|
| |
Updated test cases to verify pbe caching fix.
NOTE: putting passwords on databases are key to reproducing the original issue.
Differential Revision: https://phabricator.services.mozilla.com/D123504
|
|
|
|
|
|
|
|
| |
TlsConnectStreamTls13.EchOuterWith12Max r=nss-reviewers,bbeurdouche
Depends on D123535
Differential Revision: https://phabricator.services.mozilla.com/D123536
|
|
|
|
|
|
|
|
| |
TlsConnectTest.DisableFalseStartOnFallback r=nss-reviewers,bbeurdouche
Depends on D122988
Differential Revision: https://phabricator.services.mozilla.com/D123535
|
| |
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D122743
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D122356
|
|
|
|
|
|
| |
Firefox sets enableHelloDowngradeCheck to true by default, as of [1576790](https://bugzilla.mozilla.org/show_bug.cgi?id=1576790). We have a two year old open issue noting some issues with that [1590870](https://bugzilla.mozilla.org/show_bug.cgi?id=1590870), but I see no reason not to update the default in NSS.
Differential Revision: https://phabricator.services.mozilla.com/D122988
|
|
|
|
|
|
|
| |
The clang-format target was failing.
https://treeherder.mozilla.org/logviewer?job_id=348100377&repo=nss-try
Differential Revision: https://phabricator.services.mozilla.com/D122369
|
|
|
|
|
|
|
|
|
|
| |
Firefox password manager is slow to load (22s for 361 passwords on an i7), using 100% CPU and causing laptop fans to spin up
Possible solution based on increasing the number of cache entries used by the PKCS5v2 values as the current code thrashes the cache as we use 2 pbe's per read operation.
This patch is tested for correctness, but not fixing the issue. New test cases are needed.
Differential Revision: https://phabricator.services.mozilla.com/D122917
|
|
|
|
|
|
| |
Added check for required fields
Differential Revision: https://phabricator.services.mozilla.com/D119046
|
| |
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D121161
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with AES_CBC
When we added support for AES, we also added support for integrity checks on the encrypted components.
It turns out the code that verifies the integrity checks was broken in 2 ways:
1. it wasn't accurately operating when AES was being used (the if statement wasn't actually triggering for AES_CBC because we were looking for AES in the wrong field).
2. password update did not update the integrity checks in the correct location, meaning any database which AES encrypted keys, and which had their password updated will not be able to validate their keys.
While we found this in a previous rebase, the patch had not been pushed upstream.
The attached patch needs sqlite3 to run the tests.
Differential Revision: https://phabricator.services.mozilla.com/D120011
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
invalid algorithms.
Our QA is quite extensive on handling of alert corner cases. Our code that checks if a signature algorithm is supported ignores the role of policy. If SHA1 is turned off by policy, for instance, we only detect that late in the game. This shows up in our test cases as decrypt_alerts rather than illegal_parameter or handshake_error alerts. It also shows up in us apparently accepting a client auth request which only has invalid alerts.
We also don't handle filtering out signature algorithms that are illegal in tls 13 mode.
This patch not only fixes these issues, but also issues where we proposing signature algorithms in server mode that we don't support by policy.
This patch includes:
In gtests:
1) adding support for policy in ssl_gtests. Currently both the server an client will run with the same policy. The patch allows us to set policy on one and keeping the old policy on the other.
2) Update extension tests which failed in tls 1.3 because the patch now correctly rejects illegal tls 1.3 auth values. The test was updated to use a legal auth value in tls 1.3 (so we are correctly testing the format issue.
3) Update extension tests to handle the case where we try to use an illegal value for tls 1.3.
4) add tests to ssl_auth_unittests.cc to make sure we can properly connect even when several auth methods are turned off by policy (make sure we don't advertize them on the client side, and that the server doesn't select them when the client doesn't advertize them).
5) add tests to ssl_auth_unittests.cc to make sure we don't send empty client auth requests when the requester only sends invalid auth requests.
patch itself:
1) The handling of policy checks for ssl schemes were scattered in various locations. I've consolidated them into a single function. That function now checks for NSS_ALG_USE_IN_ANY_SIGNATURE as if this is off by policy, we will fail if we try to use the algorithm in a signature in any case. NSS now supports policy on all signature algorithms, not just DSA, so we need to check the policy of all the algorithms.
2) to support the policy check on the signature algorithms, I added a new ssl_AuthTypeToOID, which also replaces our switch in checking if the SPKI matches our auth type.
3) ssl_SignatureSchemeValid now accepts an spkiOid of SEC_OID_UNKNOWN. To allow us to filter signature schemes based on version and policy restrictions before we try to select a certificate. This prevents us from sending empty client auth messages when we are presented with only invalid signature schemes.
4) We filter supported algorithms against policy early, preventing us from sending, or even setting invalid algorithms if they are turned off by policy.
5) ssl ConsumeSignatureScheme was handling alerts inconsistently. The Consume could send an allert in it's failure case, but the check of scheme validity wouldn't sent an alert. The collers were inconstent as well. Now ssl_ConsumeSignatureScheme always sends and alert on failure, and the callers do not.
Differential Revision: https://phabricator.services.mozilla.com/D120392
|
| |
|
|
|
|
|
|
|
|
|
|
| |
https://sqlite.org/forum/info/42cf8e985bb051a2
sqlite is now permissive on opening a readonly file even if you ask for the file to be opened R/W.
normally sqlite is very conservative in changing it's underlying semantics, but evidently they chose convience over compatibility. NSS now needs to check the file permissions itself to preserve nss semantics.
Differential Revision: https://phabricator.services.mozilla.com/D120406
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
all.sh reports.
This patch includes the updated .sed script, and an experiment using bash instead to see how hard it would be to make a more robust parser.
The robust parser generates identical output as sed, but takes about 30x longer, so instead of subsecond operations, it takes almost half a minute. With that result, I think we can stay with sed and continue to update when we get new versions of gtests. (sigh).
time cat report.xml.0 | sed -f parsegtestreport.sed > r1
real 0m0.710s
user 0m0.705s
sys 0m0.008s
time cat report.xml.0 | sh parsegtestreport.sh > r2
real 0m25.066s
user 0m17.759s
sys 0m9.506s
[rrelyea@localhost common]$ diff r1 r2
updated: with review comments from Martin and move the report parsing to the common code so it can be shared with both ssl_gtests and gtests shell scripts.
Differential Revision: https://phabricator.services.mozilla.com/D120028
|
|
|
|
|
|
| |
When NSS is in FIPS mode, it should reject all primes smaller than 2048. The ike 1536 prime is in the accepted primes table. In FIPS mode it should be rejected.
Differential Revision: https://phabricator.services.mozilla.com/D119895
|
|
|
|
|
|
|
|
| |
Some of our servers could cause random failures when trying to generate many key pairs from multiple threads. This is caused because some threads would starve long enough for them to give up on getting a begin transaction on sqlite. sqlite only allows one transaction at a time.
Also, there were some bugs in error handling of the broken transaction case where NSS would try to cancel a transation after the begin failed (most cases were correct, but one case in particular was problematic).
Differential Revision: https://phabricator.services.mozilla.com/D120032
|
|
|
|
|
|
| |
A number of coverity/scanner issues were found in the kdf code which was added in nss 3.44 and the fixes never upstreamed, as well as coverity/scanner errors in nss 3.66. Not all errors were fixed, those errors which were determined to be false positives were just recorded. No attempt has been made to fix coverity/scanner errors in gtests.
Differential Revision: https://phabricator.services.mozilla.com/D119829
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D119912
|
|
|
|
| |
Last rebase we submitted a patch that used a subdirectory to measure the performance for the SQLite patch. This code wasn't active by default on linux, however, because of a typo in the build system. This is a low priority issue since NSS does not default to measure, so the patch only affects older versions of RHEL or users that have explicitly asked for 'measure' semantics.
|
|
|
|
| |
The "gtar" command doesn't usually exist on Linux.
|
| |
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D119045
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D118368
|
|
|
|
|
| |
patch by Christoph Walcher
r=rrelyea, bbeurdouche
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D115969
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r=bbeurdouche
Before applying (on Ryzen 9 3900X)
```
# mode in opreps cxreps context op time(sec) thrgput
sha256_e 1Gb 208Mb 23M 0 0.000 10000.000 10.000 123Mb 301Kb
```
After applying
```
# mode in opreps cxreps context op time(sec) thrgput
sha256_e 5Gb 797Mb 110M 0 0.000 10000.000 10.000 591Mb 769Kb
```
Differential Revision: https://phabricator.services.mozilla.com/D116962
|
|
|
|
|
|
|
|
|
| |
This validates that they are LDH (with underscore because we don't hate
freedom), but that they are not IP addresses. This invokes the horrible WhatWG
IP parsing routines, so that it recognizes a vast array of crazy address formats
(thanks 1980s design).
Differential Revision: https://phabricator.services.mozilla.com/D116343
|
|
|
|
|
|
|
|
| |
r=bbeurdouche,keeler
We need this function for the rewrite of CertVerifier::VerifyCertificateTransparencyPolicy in order to calculate a certificate's lifetime in months.
Differential Revision: https://phabricator.services.mozilla.com/D118525
|
| |
|