| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
in a database that is slow to access.
This patch solves the problems in 3 ways:
1) The initial underlying issue is solved by not generating a trust record for user certs if they have default trust values (lib/softoken/legacydb/pcertdb.c).
This will cause new databases created from old dbm databases to function normally.
2) Skip the integrity check if the record we are reading is already the default trust value (lib/softoken/sftkdb.c). This will increase the performance of reading sqlite databases created from the old dbm databases before patch 1 to perform reasonably.
3) Increase the cashe count. (lib/softoken/lowpbe.c). This affects applications which do multiple private key operations on the same private keys. Usually high speed operations would copy the keys to a session key for better performance, but sometimes that's not possible. This allows up to 20 RSA keys to be references by the application without a performance hit from the PBE checking integrity and/or decrypting the key entry.
Differential Revision: https://phabricator.services.mozilla.com/D165221
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r=nss-reviewers
There are three changes in the patch which are related to key length processing:
Change RSA_MIN_MODULUS_BITS in blalpit.h from 128 to 1023. This necessitated changes to the following tests: testcrmf.c: up the generated key for the test from 512 to 1024. pk11_rsapkcs1_unittest.cc (in pk11_gtest): skip the min padding test if the MIN_RSA_MODULUS_BITS is more than 736 (The largest hash we support is 512, which fits in an RSA key less then 736. If we can't generate a key less than 736, we can't test minimum padding, but we can never get into that situation anyway now). tls_subcerts_unittest.cc: set our key size to at least RSA_MIN_MODULUS_BITS, and then make sure the policy had a higher minimum key length so we still trigger the 'weakKey' event. pk11kea.c: use 1024 bits for the transfer key now that smaller keysizes aren't supported by softoken.
Expand the add a new flag to meaning of NSS_XXX_MIN_KEY_SIZE beyond it's use in SSL (add the ability to limit signing and verification to this as well). This allows us to set strict FIPS 140-3 policies, where we can only sign with 2048, but can still verify 1024. This part includes: New utility functions in seckey.c: SECKEY_PrivateKeyStrengthInBits(): The private key equivalent to SECKEY_PublicKeyStrengthInBits(). This function could be exported globally, but isn't in this patch. seckey_EnforceKeySize(). Takes a key type and a length and makes sure that length falls into the range set by policy. secsign.c and secvfy.c: add policy length check where we check the other policy flags. nss.h, nssoptions.c: add NSS_KEY_SIZE_POLICY_FLAGS and define flags for SSL, VERIFY, and SIGN. SSL is set by default (to maintain the current behavior). pk11parse.c: add keywords for the new NSS_KEY_SIZE_POLICY_FLAGS. ssl3con.c: use the flags to decide if the policy lengths are active for SSL. policy.txt: Test that the new policy flags are parsed correctly sslpolicy.txt: Add tests to make sure the policy flags are functioning.
Update fips_algorithms.h to make sure the FIPS indicators are exactly compliant with FIPS 140-3 current guidance (RSA 2028 and above, any key size, Legacy verification allowed for 1024, 1280, 1536, and 1792 [1024-1792, step 256]).
The previous attempt to push failed because the pk11_rsapkcs1_unittest.cc
change was eaten in the merge.
Differential Revision: https://phabricator.services.mozilla.com/D146341
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
There are three changes in the patch which are related to key length processing:
Change RSA_MIN_MODULUS_BITS in blalpit.h from 128 to 1023. This necessitated changes to the following tests: testcrmf.c: up the generated key for the test from 512 to 1024. pk11_rsapkcs1_unittest.cc (in pk11_gtest): skip the min padding test if the MIN_RSA_MODULUS_BITS is more than 736 (The largest hash we support is 512, which fits in an RSA key less then 736. If we can't generate a key less than 736, we can't test minimum padding, but we can never get into that situation anyway now). tls_subcerts_unittest.cc: set our key size to at least RSA_MIN_MODULUS_BITS, and then make sure the policy had a higher minimum key length so we still trigger the 'weakKey' event. pk11kea.c: use 1024 bits for the transfer key now that smaller keysizes aren't supported by softoken.
Expand the add a new flag to meaning of NSS_XXX_MIN_KEY_SIZE beyond it's use in SSL (add the ability to limit signing and verification to this as well). This allows us to set strict FIPS 140-3 policies, where we can only sign with 2048, but can still verify 1024. This part includes: New utility functions in seckey.c: SECKEY_PrivateKeyStrengthInBits(): The private key equivalent to SECKEY_PublicKeyStrengthInBits(). This function could be exported globally, but isn't in this patch. seckey_EnforceKeySize(). Takes a key type and a length and makes sure that length falls into the range set by policy. secsign.c and secvfy.c: add policy length check where we check the other policy flags. nss.h, nssoptions.c: add NSS_KEY_SIZE_POLICY_FLAGS and define flags for SSL, VERIFY, and SIGN. SSL is set by default (to maintain the current behavior). pk11parse.c: add keywords for the new NSS_KEY_SIZE_POLICY_FLAGS. ssl3con.c: use the flags to decide if the policy lengths are active for SSL. policy.txt: Test that the new policy flags are parsed correctly sslpolicy.txt: Add tests to make sure the policy flags are functioning.
Update fips_algorithms.h to make sure the FIPS indicators are exactly compliant with FIPS 140-3 current guidance (RSA 2028 and above, any key size, Legacy verification allowed for 1024, 1280, 1536, and 1792 [1024-1792, step 256]).
Differential Revision: https://phabricator.services.mozilla.com/D146341
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r=nss-reviewers,jschanck
When we first added integrity checks to NSS for FIPS compliance, the only signature method allowed was DSA. NIST will be sunsetting DSA in 2023, so we need to update our integrity checks again. Since the time we added these checks, NIST has started accepting HMAC as a valid signature algorithm for integrity checks. HMAC is easier, faster and requires smaller .chk files and openssl and gnutls has been using hmac now for years for this purpose.
Since we need to move off of DSA anyway it's time to move to HMAC.
This patch does this move. shlibsign now produces HMAC_256 by default. It moves the version number up because even though nss includes a type field, previous versions of NSS did not look at the type field when checking integrity. Bumping the version number will cause previous versions of NSS to fail early if presented with a newly generated integrity check file (even though it should fail later anyway). shlibsign now has the ability to generate 'legacy' check files so it can be used to generate check files for older versions of NSS.
NSS can still accept older check files unless NSS_STRICT_INTEGRITY is set at compile time. This means tools which may be using old shlibsign to resign nss shared libraries will continue to work. At some point we can remove all DSA support (maybe after one enterprise release cycle).
While completing this work, we also complete some integrity code cleanup. There are lots of magic numbers defining where things fall in the integrity check header. These are now moved to a structure and defined in the shsign.h header. Both shlibsign and shvfy have been updated to use this header.
New test cases are not needed since fips.sh adequately tests our integrity code (both normal case and against mangled libraries which should fail). Though the lowhash test was updated to catch a particular issue we can run into when we use the LOWHASH code. On RHEL-7, we use the NSSLOWHASH_ interface in freebl in libc, which needs to run independently of nspr and nssutil. This requirement puts a pretty heavy burned on freebl to be self-contained when used for NSSLOWHASH_, including running integrity checks. The previous test program linked with nssutil and nspr (just like all of the rest of the nss tests) and weren't detecting issues when unimplemented stub functions where called. This patch includes fixing those lowhash tests and also implementing the stubs needed by the current integrity check code.
cmd/lowhashtest/Makefile
remove linking lowhashtest with all the libraries except freebl.
cmd/lowhashtest/lowhashtest.c
remove any dependency NSPR or NSSUTIL in the code.
cmd/lowhashtest/manifest.mn
remove spurious requires statements.
cmd/shlibsign/shlibsign.c
add hmac code.
add ability to select the hash type from the command line.
separate signature processing into their own functions for DSA and HMAC
General cleanups.
Use PR_ARRAY_SIZE rather then a custom define.
move error printing outside utility functions (so we don't have to pass around filenames everywhere)
Use NSSSignChkHeader instead of a Buf with magic offsets for the Check file Header.
Add ability to make old style .chk files for old versions of NSS.
Add option to revert to DSA
Add option to use old version numbers: only valid if DSA is set.
lib/freebl/Makefile
All NSS_STRICT_INTEGRITY to be set at build time. Setting NSS_STRICT_INTEGRITY only accepts hmac256, hmac384, hmac512. If it's not set, NSS will accept older .chk file formats (like DSA-2).
lib/freebl/nsslowhash.c
lowhashtest files expect to set NSS_FIPS to force fips mode when testing the lowhash interface, but NSS_FIPS was not being looked at in the nsslow_GetFIPSEnabled. NOTE: setting NSS_FIPS to true will force FIPS mode if the system isn't already in FIPS mode. Setting it to FALSE will not turn it off if the system is already in FIPS mode.
lib/freebl/shsign.h
Update version.
Add new defines for HMAC
add new Header structure to remove magic offsets into a raw buffer in the code.
lib/freebl/shvfy.c
Add HMAC processing.
Turn off DSA processing if NSS_STRICT_INTEGERITY is set.
Refactor the signature processing.
lib/freebl/stubs.c
Add SECITEM_ItemsAreEqual for HMAC shvfy
Add implementations for SECITEM_ItemsAreEqual, SECITEM_ZfreeItem, and PR_GetEnvSecure. The first is new. The second solves and existing bug which is only seen on RHEL7, and the last is needed for the fix to nsslowhash.c above.
PR_GetEnvSecure() calls secure_getenv if _USE_GNU is set, otherwise it falls back to the normal getenv. This should be safe since it's only used in LOWHASH to get the NSS_FIPS environment variable, which only has the effect of making LOWHASH run in fips mode when it otherwise wouldn't.
lib/freebl/stubs.c
Add SECITEM_ItemsAreEqual for HMAC shvfy
tests/lowhash/lowhash.sh
Make the test executable so it can be run on it's own.
Differential Revision: https://phabricator.services.mozilla.com/D164137
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D165677
|
| |
|
|
|
|
| |
r=bbeurdouche,nss-reviewers
Differential Revision: https://phabricator.services.mozilla.com/D165019
|
| |
|
|
|
|
|
| |
Clean up problemantic terms are master, slave, whitelist, blacklist.
These are usually easily changes to main/server, client, allowlist, and blocklist (or other similiar terms, which are often more descriptive anyway). Things related to the tls/ssl master key, which part of the tls spec and needs to first be handled by the tls ietf working group.
Differential Revision: https://phabricator.services.mozilla.com/D163522
|
| |
|
|
|
|
|
|
| |
r=nss-reviewers,djackson
Depends on D36756
Differential Revision: https://phabricator.services.mozilla.com/D36757
|
| |
|
|
|
|
| |
r=nss-reviewers,djackson
Differential Revision: https://phabricator.services.mozilla.com/D36755
|
| |
|
|
|
|
|
|
|
|
| |
It was required to update docker-interop image to ubuntu 20.04 since a newer Go release was required for the BoGo tests to run.
See nss/gtests/nss_bogo_shim/config.json for a list of disabled BoGo test, including short descriptions/bug links.
A -loose-local-errors falg was added to Bogo (runner.go) to allow usage of more tests by ignoring differences in local errors on the Go side of test connections, similar to the remote error 'suppression' used. The code is patched to the BoGo runner after cloning in nss/tests/bogo/bogo.sh and can be found in nss/gtests/nss_bogo_shim/nss_loose_local_errors.patch.
Differential Revision: https://phabricator.services.mozilla.com/D147675
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D8088
|
| |
|
|
|
|
|
|
| |
passwords and pkcs5v2 encoding.
Don't use NULL when encoding UTF8 with pkcs5v2. Fix a bug here when converting from UCS2 to UTF8 we would add a double NULL when adding a NULL.
Differential Revision: https://phabricator.services.mozilla.com/D141538
|
| |
|
|
|
|
| |
zero-length record/fragment handling tests. Enabled tls fuzzer empty alert test. r=djackson
Differential Revision: https://phabricator.services.mozilla.com/D141841
|
| |
|
|
|
|
| |
r=nss-reviewers,jschanck
Differential Revision: https://phabricator.services.mozilla.com/D139790
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TLS 1.3
We need to be able to select Client certificates based on the schemes sent to us from the server. Rather than changing the callback function, this patch adds those schemes to the ssl socket info as suggested by Dana. In addition, two helpful functions have been added to aid User applications in properly selecting the Certificate:
PRBool SSL_CertIsUsable(PRFileDesc *fd, CERTCertificate *cert) - returns true if the given cert matches the schemes of the server, the schemes configured on the socket, capability of the token the private key resides on, and the current policy. For future SSL protocol, additional restrictions may be parsed.
SSL_FilterCertListBySocket(PRFileDesc *fd, CERTCertList *certlist) - removes the certs from the cert list that doesn't pass the SSL_CertIsUsable() call.
In addition the built in cert selection function (NSS_GetClientAuthData) uses the above functions to filter the list. In order to support the NSS_GetClientAuthData three new functions have been added:
SECStatus CERT_FilterCertListByNickname(CERTCertList *certList, char *nickname, void *pwarg) -- removes the certs that don't match the 'nickname'.
SECStatus CERT_FilterCertListByCertList(CERTCertlist *certList, const CERTCertlist *filterList ) -- removes all the certs on the first cert list that isn't on the second.
PRBool CERT_IsInList(CERTCertificate *, const CERTCertList *certList) -- returns true if cert is on certList.
In addition
* PK11_FindObjectForCert() is exported so the token the cert lives on can be accessed.
* the ssle ssl_PickClientSignatureScheme() function (along with several supporing functions) have been modified so it can be used by SSL_CertIsUsable()
Differential Revision: https://phabricator.services.mozilla.com/D135715
|
| |
|
|
|
|
| |
r=nss-reviewers,bbeurdouche,rrelyea
Differential Revision: https://phabricator.services.mozilla.com/D136289
|
| |
|
|
|
|
| |
r=nkulatova
Differential Revision: https://phabricator.services.mozilla.com/D134866
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
r=bbeurdouche,djackson
Differential Revision: https://phabricator.services.mozilla.com/D123652
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Added check for required fields
Differential Revision: https://phabricator.services.mozilla.com/D119046
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changes from the review:
The while loop was taken out of it's subshell pipe, which prevented the selfserv PID from being passed on to the final selfserv-kill. This eventally lead to a freeze on windows.
The last paragraph of ISO 19790:2012 section 7.2.4.2 states:
All services shall [02.24] provide an indicator when the service utilises an approved cryptographic algorithm, security function or process in an approved manner and those services or processes specified in 7.4.3
This means our libraries need to grow an API or provide some additional information via contexts or similar in order for an application to be able to query this indicator. This can't be just a Security Policy description because ISO 24759:2017 section 6.2.4.2 states:
TE02.24.02: The tester shall execute all services and verify that the indicator provides an unambiguous indication of whether the service utilizes an approved cryptographic algorithm, security function or process in an approved manner or not.
The indicator can't be just a marker over an algorithm either, because it needs to show different values based on whether the algorithm parameters causes the algorithm to run in approved or non-approved mode (ie keys outside of valid range for RSA means RSA is being used in non-approved mode ...)
For NSS, there is a PKCS #11 design:
https://docs.google.com/document/d/1Me9YksPE7K1Suvk9Ls5PqJXPpDmpAboLsrq0z54m_tA/edit?usp=sharing
This patch implments the above design as well as:
1) NSS proper functions to access these indicators from either the pk11wrap layer or the ssl layer.
2) Updates to the ssl tests which will output the value of the
Changes decription by file:
cmd/selfserv/selfserv.c
Add a FIPS indicator if the connection was excuted in FIPS mode on a FIPS token.
cmd/strsclnt/strsclnt.c
Add a FIPS indicator if the connection was excuted in FIPS mode on a FIPS token.
cmd/tstclnt/tstclnt.c
Add a FIPS indicator if the connection was excuted in FIPS mode on a FIPS token.
lib/nss/nss.def
Add the new pk11 functions to access the fips indicator.
lib/pk11wrap/pk11cxt.c
Implement a function to get the FIPS indicator for the current PK11Context.
lib/pk11wrap/pk11load.c
Get the fips indicator function from the PKCS #11 module using the vendor function interface from PKCS #11 v3.0
lib/pk11wrap/pk11obj.c
Implement a function to get the FIPS indicator for a specific PKCS #11 object.
lib/pk11wrap/pk11priv.h
Add a generalized helper function to get the FIPS indicator used by all the other exported functions to get FIPS indicator.
lib/pk11wrap/pk11pub.h
Add function to get the FIPS indicator for the current PK11Context.
lib/pk11wrap/pk11slot.c
Implement a generalized helper function to get the FIPS indicator.
Implement a function to get the FIPS indicator for the latest single shot operation on the slot.
lib/pk11wrap/secmodt.h
Add a new field to hold the fipsIndicator function.
lib/softoken/fips_algorithms.h
New sample header which vendors can replace with their own table. In the default NSS case, the table in this header will be empty.
lib/softoken/fipstokn.c
Add Vendor specific interface for the FIPS indicator to the FIPS token.
lib/softoken/pkcs11.c
Add Vendor specific interface for the FIPS indicator to the non-FIPS token.
Factor out the code tha maps an attribute value to a mechanism flag to it's own file so it can
be used by other parts of softoken. (new function is in pkcs11u.c
Implement the function that returns the FIPS indicator. This function fetches the indicator from either the session or the object or both. The session indicator is in the crypto context (except the last operation indicator, which is in the session itself. The object indicator is in the base object.
lib/softoken/pkcs11c.c
Record the FIPS indicator in the various helper function.
- sftk_TerminateOp is called when a crypto operation had been finalized, so we can store that fips indicator in the lastOpWasFIPS field.
- sftk_InitGeneric is called when a crypto operation has been initialized, so we can make a preliminary determination if the operation is within the FIPS policy (could later change bases on other operations. For this to work, we need the actual mechanism, so pMechanism is now a parameter to sftk_InitGeneric.
- sftk_HKDF - HKDF when used in TLS has the unusual characteristic that the salt could actually be a key. In this case, usually the base key is some known public value which would not be FIPS generated, but the security is based on whether the salt is really a FIPS generated key. In this case we redo the calculation based on the salt key.
lib/softoken/pkcs11i.h
- add the FIPS indicators to the various structures (crypto contexts, sessions, objects).
- add the FIPS indicators function list
- add pMechanism the the sftkInitGeneric function.
- add the helper function to map Attribute Types to Mechanism Flags.
- add the function that will look up the current operation in the FIPS table to determine that it is allowed by policy.
lib/softoken/pkcs11u.c
- include the new fips_algorithms.h (if NSS_FIPS_DISABLED is not on)
- handle the FIPS status for objects and session on creation an copy.
- implement the helper function to map Attribute Types to Mechanism Flags.
- get the key length of a key. This involves getting the key type and then using the key type to determin the appropriate attribute to fetch. Most keys it's simply the CKA_VALUE. ECC is special, we get the key length from the curve. Since only a subset of curves can be FIPS Curves, we use key length to return false for other curves.
- the handle special function handles any unusal semantics for various mechanism types. This function precodes possible mechanism semantics we may need to check. The special handling can be selected by the mechanism table in fips_algorithms.h
- sftk_operationIsFIPS - the actual function to determine if the givelib/n operation is in the FIPS table.
lib/softoken/sftkmessage.c
- just need to update the sftk_InitGeneric function to pass the mechanism.
lib/ssl/ssl3con.c
- and functions to query the underlying crypto contexts to see if the current ssl session is running in FIPS approved mode based on the security policy. It does so by checking the CipherSpecIsFIPS function to verify that both the mac and the encryption algorithm FIPS conforms to the ciphers in the security profile (using PK11_GetFIPSStatus). We check both the cipher specs for read and write. These underlying specs depends on the keys used in these specs being generated with FIPS approved algorithms as well, so this verifies the kea and kdf functions as well.
lib/ssl/sslimpl.h
- ass ssl_isFIPS() so it can be used by other files here in the ssl directory.
lib/ssl/sslinfo.c
- set the new isFIPS field in the existing sslinfo structure. SSL_GetChannelInfo knows how to handle sslinfo structures that are smaller then expected and larger than expected. unknown fields will be set to '0' (so new applications running against old versions will always get zero for new fields). sslinfo that are smaller will only return a the subset the calling application expects (so old applications will not get the new fields).
lib/ssl/sslt.h
- Add the new isFIPS field (must be at the end of the ChannelInfo structure).
lib/util/pkcs11n.h
- add the new FIPS indicator defines.
tests/ssl/ssl.h
- The main changes was to turn on verbose for the coverage tests so we can test the FIPS indicators on various cipher suites. NOTE: this only works with either NSS_TEST_FIPS_ALGORIHTMS set, or a vendor fips_algorthims.h, so vendors will need to do their own test interpretation. While working in ssl.sh I fixed an number of other issues:
- many tests that were skipped in FIPS mode were skipped not because they didn't work in FIPS mode, but because tstclnt requires a password when running in FIPS mode. I've now added the password if the function is running in fips mode and removed the fips restrictions.
- dtls had a race condition. the server side needed to come up before the client, but couldn't end before the client ran. We already had a sleep to guarrentee the former, I added a sleep before sending the server it's data to handle the latter.
- CURVE25519 is the default ECC curve, but it's not a fiPS curve, so I disable it in FIPS mode so we will actually get FIPS indicators when using ECDHE.
- I added TLS 1.3 to the coverage tests.
Differential Revision: https://phabricator.services.mozilla.com/D115034
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also fixes:
Bug 452464 pk12util -o fails when -C option specifies AES or Camellia ciphers
Related:
Bug 1694689 Firefox should use modern algorithms in PKCS#12 files by default
Bug 452471 pk12util -o fails when -c option specifies pkcs12v2 PBE ciphers
The base of this fix is was a simple 3 line fix in pkcs12.c, changing the initial setting of cipher and cert cipher.
Overview for why this patch is larger than just 3 lines:
1. First issue was found in trying to change the mac hashing value.
a. While the decrypt side knew how to handle SHA2 hashes, the equivalent code was not updated on the encrypt side. I refactored that code and placed the common function in p12local.c. Now p12e.c and p12d.c share common code to find the required function to produce the mac key.
b. The prf hmac was hard coded to SHA1. I changed the code to pass the hmac matching the hashing algorithm for the mac. This required changes to p12e.c to calculate and pass the new hmac as well and adding new PK11_ExportEncryptedPrivateKey and PK11_ExportEncryptedPrivKey to take the PKCS #5 v2 parameters. I also corrected an error which prevented pkcs12 encoding of ciphers other than AES.
2. Once I've made my changes, I realized we didn't have a way of testing them. While we had code that verified that particular sets of parameters for pkcs12 worked together and could be listed and imported, we didn't have a way to verify what algorithms were actually generated by our tools.
a. pk12util -l doesn't list the encryption used for the certs, so I updated pp to take a pkcs12 option. In doing so I had to update pp to handle indefinite encoding when decoding blocks. I also factored that decoding out in it's own function so the change only needed to be placed once. Finally I renabled a function which prints the output of an EncryptedPrivate key. This function was disabled long ago when the Encrypted Private key info was made private for NSS. It has since been exported, so these functions could easily be enabled (archeological note: I verified that this disabling was not a recent think I found I had done it back when I still have a netscape email address;).
b. I updated tools.sh to us the new pp -t pkcs12 feature to verify that the key encryption, cert encryption, and hash functions matched what we expected when we exported a new key. I also updated tools.sh to handle the new hash variable option to pk12util.
c. I discovered several tests commented out with comments that the don't work. I enabled those tests and discovered that they can now encrypt, but the can't decrypt because of pkcs12 policy. I updated the policy code, but I updated it to use the new NSS system wide policy mechanism. This enabled all the ciphers to work. There is still policy work to do. The pk12 policy currently only prevents ciphers from use in decrypting the certificates, not decrypting the keys and not encrypting. I left that for future work.
3. New options for pp and pk12util were added to the man pages for these tools.
---------------------------------------------------------------------------
With that in mind, here's a file by file description of the patch:
automation/abi-check/expected-report-libnss3.so.txt
-Add new exported functions. (see lib/nss/nss.def)
cmd/lib/basicutil.h:
-Removed the HAVE_EPV_TEMPLATE ifdefs (NSS has exported the Encrypted Private Key data structure for a while now.
cmd/lib/secutil.c:
global: Updated several functions to take a const char * m (message) rather than a char * m
global: Made the various PrintPKCS7 return an error code.
global: Added a state variable to be passed around the various PKCS7 Print functions. It gives the proper context to interpret PKCS7 Data Content. PKCS 12 used PKCS7 to package the various PKCS12 Safes and Bags.
-Updated SECU_StripTagAndLength to handle indefinite encoding, and to set the Error code.
-Added SECU_ExtractDERAndStep to grab the next DER Tag, Length, and Data.
-Updated secu_PrintRawStringQuotesOptional to remove the inline DER parsing and use SECU_ExtractDERAndStep().
-Updated SECU_PrintEncodedObjectID to return the SECOidTag just like SECU_PrintObjectID.
-Renable SECU_PrintPrivateKey
-Added secu_PrintPKCS12Attributes to print out the Attributes tied to a PKCS #12 Bag
-Added secu_PrintPKCS12Bag to print out a PKCS #12 Bag
-Added secu_PrintPKCS7Data, which uses the state to determine what it was printing out.
-Added secu_PrintDERPKCS7ContentInfo which is identical to the global function SECU_PrintPKCS7ContentInfo except it takes a state variable. The latter function now calls the former.
-Added secu_PrintPKCS12DigestInfo to print the Hash information of the Mac. DigestInfo is the name in the PKCS 12 spec.
-Added secu_PrintPKCS12MacData to print the Mac portion of the PKCS 12 file.
-Added SECU_PrintPKCS12 to print otu the pkcs12 file.
cmd/lib/secutil.h
-Added string for pkc12 for the command line of pp
reenabled SECU_PrintPrivateKey
-Added SECU_PrintPKCS12 for export.
cmd/pk12util/pk12util.c
-Added the -M option to specify a hash algorithm for the mac.
updated P12U_ExportPKCS12Object: pass the hash algorithm to the PasswordIntegrity handler.
-Added PKCS12U_FindTagFromString: generalized string to SECOidTag which only filters based on the oid having a matching PKCS #11 mechanism.
updated PKCS12U_MapCipherFromString to call use PKCS12U_FindTagFromString to get the candidate tag before doing it's post processing to decide if the tag is really an encryption algorithm.
-Added PKCS12U_MapHashFromString with is like MapCipherFromString except it verifies the resulting tag is a hash object.
-Updated main to 1) change the default cipher, change the default certCipher, and process the new hash argument. NOTE: in the old code we did not encrypt the certs in FIPS mode. That's because the certs were encrypted with RC4 in the default pkcs12 file, which wasn't a FIPS algorithm. Since AES is, we can use it independent on whether or not we are in FIPS mode.
cmd/pp/pp.c
-Added the pkcs12 option which calls SECU_PrintPKCS12 from secutil.c
lib/nss/nss.def
-Add exports to the new PK11_ExportEncryptedPrivKeyInfoV2 and PK11_ExportEncryptedPrivateKeyInfoV2 (V2 means PKCS 5 v2, not Version 2 of ExportEncrypted*Info).
-Add export for the old HASH_GetHMACOidTagByHashOidTag which should have been exported long ago to avoid the proliferation of copies of this function in places like ssl.
lib/pk11wrap/pk11akey.c
-Add PK11_ExportEncryptedPrivKeyInfoV2 (which the old function now calls), which takes the 3 PKCS 5 v2 parameters. The underlying pkcs5 code can fill in missing tags if necessary, but supplying all three gives the caller full control of the underlying pkcs5 PBE used.
-Add PK11_ExportEncryptedPrivateKeyInfoV2, same as the above function except it takes a cert which is used to look up the private key. It's the function that pkcs12 actually uses, but the former was exported for completeness.
lib/pk11wrap/pk11pub.h
-Added the new PK11_ExportEncryptedPriv*KeyInfoV2 functions.
lib/pkcs12/p12d.c
-Remove the switch statement and place it in p12local.c so that p12e.c can use the same function.
lib/pkc12/p12e.c
-Remove the unnecessary privAlg check so we can encode any mechanism we support. This only prevented encoding certificates in the pk12 file, not the keys.
-add code to get the hmac used in the pbe prf from the integrity hash, which is under application control.
-Do the same for key encryption, then use the new PK11_ExportEncryptedPrivateKeyInfo to pass that hash value.
-Use the new sec_pkcs12_algtag_to_keygen_mech so there is only one switch statement to update rather than 2.
-Update the hash data to old the length of the largest hash rather than the length of a SHA1 hash.
lib/pkcs12/p12local.c
- Add new function new sec_pkcs12_algtag_to_keygen_mech to factor out the common switch statement between p12e and p12d.
lib/pkcs12/p12local.h
-Export the new sec_pkcs12_algtag_to_keygen_mech
lib/pkcs12/p12plcy.c
-Map the old p12 policy functions to use the new NSS_GetAlgorithmPolicy. We keep the old table so that applications can change the policy with the old PKCS12 specific defines (so the old code keeps working). NOTE: policies now default to true rather than false.
lib/util/secoidt.h
-Add new NSS_USE_ALG_IN_PKCS12 used by pk11plcy.c
NOTE: I have not updated the policy table in pk11wrap/pk11pars.c, so we can't yet control pkcs12 policy with the nss system policy table. That's a patch for another time.
test/tools/tool.sh
-global: Remove trailing spaces
-global: DEFAULT is changed to 'default'
-Update the PBE mechanism to exactly match the string in secoid.c. PKCS #12 does case independent compares, so case doesn't matter there, but now I'm comparing to the output of pp, and I didn't want to spend the time to figure out case independent compares in bash.
-Add our defauts and shell variables at the top so there are easy to change in the future.
export_with_*** have all been colapsed into a single export_p12_file which handles taking 'default' and turning off that argument.
-Add for loops for the hash functions.
-Restore the camellia ciphers back now that they work.
-Restore the pkcs12V2pbe back now that they work.
-Collect various pbe types into single variables and use those variables in loops
-Reduce the number of tests ran in optimized mode (which takes 60x the time to do a pbe then than debug mode based on a larger iterator).
-Add verify_p12 which dumps out the p12 file and makes sure the expected CERT_ENCRYPTION, KEY_ENCRYPTION, and HASH are used.
doc/pp.xml
-Add pkcs12 option
doc/pk12util.xml
-Add -M option
-Update synopsis with options in the description but not in the synopsis
Differential Revision: https://phabricator.services.mozilla.com/D113699
|
| |
|
|
|
|
|
|
| |
1) Add code to treat softokn as a non-threadsafe module.
2) Add a cycle to test ssl against non-threadafe modules.
3) Fix deadlock by restricting the ContextMonitor to only be active around PKCS #11 function calls.
Differential Revision: https://phabricator.services.mozilla.com/D112092
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D102670
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D101218
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
signatures are disabled. r=mt
When libpkix is checking an OCSP cert, it can't use the passed in set of trust anchors as a base because only the single root that signed the leaf can sign the OCSP request. As a result it actually checks the signature of the self-signed root when processing an OCSP request. This fails of the root cert signature is invalid for any reason (including it's a sha1 self-signed root cert and we've disabled sha1 signatures (say, by policy)).
Further investigation indicates the difference between our classic code and the current code is the classic code only checks OCSP responses on leaf certs. In the real world, those responses are signed by intermediate certificates (who won't have sha1 signed certificates anymore), so our signature processing works just fine. pkix checks OCSP on the intermediate certificates as well, which are signed by the root cert. In this case the root cert is a chain of 1, and is effectively a leaf. This patch updates the OCSP response code to not check the signatures on the single cert if that cert is a selfsigned root cert. This requires bug 391476 so we still do the other validation checking on the certs (making sure it's trusted as a CA).
Differential Revision: https://phabricator.services.mozilla.com/D94661
|
| | |
| |
| |
| |
| |
| |
| |
| | |
signatures are disabled.
When libpkix is checking an OCSP cert, it can't use the passed in set of trust anchors as a base because only the single root that signed the leaf can sign the OCSP request. As a result it actually checks the signature of the self-signed root when processing an OCSP request. This fails of the root cert signature is invalid for any reason (including it's a sha1 self-signed root cert and we've disabled sha1 signatures (say, by policy)).
Further investigation indicates the difference between our classic code and the current code is the classic code only checks OCSP responses on leaf certs. In the real world, those responses are signed by intermediate certificates (who won't have sha1 signed certificates anymore), so our signature processing works just fine. pkix checks OCSP on the intermediate certificates as well, which are signed by the root cert. In this case the root cert is a chain of 1, and is effectively a leaf. This patch updates the OCSP response code to not check the signatures on the single cert if that cert is a selfsigned root cert. This requires bug 391476 so we still do the other validation checking on the certs (making sure it's trusted as a CA).
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
support
Policy update
Current state of the nss policy system:
The initial policy patch focused on getting policy working well in handling ssl. The policy infrastructure used two existing NSS infrastructure:
1) Algorithm policies tied the OIDS and
2) the ssl policy constraints first created to handle export policy restrictions.
To make loadable policies work, we added a couple of new things:
1) a policy parser to the secmod infrastructure which allows us to set algorithm policies based on a config file. This file had two sections: disallow= and allow=. Disallow turned off policy bits, and allow turned them on. Disallow was always parsed first, so you could very strictly control your policy map by saying disallow=all allow={exclusive list of allowed algorithms}
2) a new NSS_Option() value that allowed the policy parser to set integer values (like minimum tls version) based on the data in the policy parser.
3) SSL code which is run at ssl_init time that reads the algorithm policies and maps the results to SSL policies.
The resulting loaded policy code, in general, sets the boundaries of what it possible, actually enable/disable of ssl cipher suites are still under program control, and the builtin NSS default values. The only consession to configuration is if a cipher is disallowed by policy, it is also disabled. Allowing a cipher suite by policy that wasn't already enabled, however, doesn't enable that policy by default. Inside the policy restrictions, applications can still make their own decisions on configuration and preference.
At the time the policy system was designed, there were 3 additional features, which were designed, but not specified: disable, enable, and lock.
disable and enable work just like disallow and allow, except the specify what the default settings are. This would allow the policy file to change the underlying default in the case where the application doesn't try to configure ssl on it's own.
lock would make either the policy or configuration 'locked' meaning once the lock has been executed, no further changes to those configurations would be allowed.
What is needed:
We have a need for the following additional features:
1) we want to turn more of the sha-1 hash function off by default. We still need sha-1 digest because it's used in many non-secure cases, but we do want to disable more sha-1 signature usage. Currently only CERT-SIGNATURE and various hmac usages in SSL ciphers can be controlled by policy. We want to disallow a greater range of signature (that is signature use in general).
2) we want to disable more ciphers by default, but need a way to have certain policies (like LEGACY) turn them back on, so that our shipped system is more secure by default.
What this patch provides:
1) A new policy flag NSS_USE_ALG_IN_ANY_SIGNATURE was added. The cryptohi code which exports the NSS sign/verify high level code now checks the hash and signing algorithm against this new policy flag and fails if the policy isn't available.
New key words were added to the policy parser for 'all-signature', which implies all signature flags at once, and 'signature', which maps to NSS_USE_ANY_SIGNATURE. NOTE: disable=all/signature and disable=all/all-signature are effective equivalent because cert-signatures eventually call the low level signature functions, but disable=all allow=rsa-pss/all-signature and disable=all allow=rsa-pss/signature are different in that the latter allows all rsa-pss signature and the latter allows rsa-pss signatures, but no on certificates (or on smime in the future)
Also new keywords were added for rsa-pkcs, rsa-pss, and ecdsa for signature algorithms (along with dsa).
2) This patch implements disable and enable. These functions only work on SSL configuration. In the future SMIME/CMS configuration could also be added. Because the policy system is parsed and handled by NSS, and SSL configuration is handled in SSL, we use the same Apply code we used to apply ssl policy to set the inital configuration. The configured enable/disable state is configured in the ALGORTHIM policy system, where one bit says the enable/disable value is active and another bit which gives it's state.
3) two locks have been implented, policy-lock and ssl-lock. These are specified in the parser as flags (flags=policy-lock,ssl-lock). The policy locks all the policy changes: ssl_policy, algorithm policy, and options. It is implemented by two new exported functions: NSS_IsPolicyLocked() and NSS_LockPolicy(). The first allows applications to test if the policy is locked without having to try changing the policy. The various policy set functions check the NSS_IsPolicyLocked() function and returns SEC_ERROR_POLICY_LOCK if it's true.
The ssl-lock changes the state of the policy to locked, and the state cannot be changed back without shutting down NSS. The second is implemented by setting a new Option called NSS_DEFAULT_LOCKS and the NSS_DEFAULT_SSL_LOCK flag. The idea is we can add an SMIME lock in the future. SSL checks the NSS_DEFAULT_SSL_LOCK flag before trying to set the cipher suite value, and blocks the change if it's set.
4) sslpolicy tests were updated to test the enable, disable, flags=policy-lock, flags=ssl-lock and the new signature primitives.
5) policy tests were updated to be able to run standalone (like all the other all.sh tests), as well as new tests to detect when no signing algorithms have been enabled.
What is not in the patch
1) S/MIME signature policy has been defined for a while, but never hooked up.
2) S/MIME export policy needs to be connected back to the algorithm policy system just like the ssl cipher suites already are.
3) S/MIME default configuration needs to be connected back to the policy system.
4) ECC Curve policy needs to be hooked up with the signature policy (probably should create a generic 'key meets policy' function and have every call it).
Differential Revision: https://phabricator.services.mozilla.com/D93697
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
support
Policy update
Current state of the nss policy system:
The initial policy patch focused on getting policy working well in handling ssl. The policy infrastructure used two existing NSS infrastructure:
1) Algorithm policies tied the OIDS and
2) the ssl policy constraints first created to handle export policy restrictions.
To make loadable policies work, we added a couple of new things:
1) a policy parser to the secmod infrastructure which allows us to set algorithm policies based on a config file. This file had two sections: disallow= and allow=. Disallow turned off policy bits, and allow turned them on. Disallow was always parsed first, so you could very strictly control your policy map by saying disallow=all allow={exclusive list of allowed algorithms}
2) a new NSS_Option() value that allowed the policy parser to set integer values (like minimum tls version) based on the data in the policy parser.
3) SSL code which is run at ssl_init time that reads the algorithm policies and maps the results to SSL policies.
The resulting loaded policy code, in general, sets the boundaries of what it possible, actually enable/disable of ssl cipher suites are still under program control, and the builtin NSS default values. The only consession to configuration is if a cipher is disallowed by policy, it is also disabled. Allowing a cipher suite by policy that wasn't already enabled, however, doesn't enable that policy by default. Inside the policy restrictions, applications can still make their own decisions on configuration and preference.
At the time the policy system was designed, there were 3 additional features, which were designed, but not specified: disable, enable, and lock.
disable and enable work just like disallow and allow, except the specify what the default settings are. This would allow the policy file to change the underlying default in the case where the application doesn't try to configure ssl on it's own.
lock would make either the policy or configuration 'locked' meaning once the lock has been executed, no further changes to those configurations would be allowed.
What is needed:
We have a need for the following additional features:
1) we want to turn more of the sha-1 hash function off by default. We still need sha-1 digest because it's used in many non-secure cases, but we do want to disable more sha-1 signature usage. Currently only CERT-SIGNATURE and various hmac usages in SSL ciphers can be controlled by policy. We want to disallow a greater range of signature (that is signature use in general).
2) we want to disable more ciphers by default, but need a way to have certain policies (like LEGACY) turn them back on, so that our shipped system is more secure by default.
What this patch provides:
1) A new policy flag NSS_USE_ALG_IN_ANY_SIGNATURE was added. The cryptohi code which exports the NSS sign/verify high level code now checks the hash and signing algorithm against this new policy flag and fails if the policy isn't available.
New key words were added to the policy parser for 'all-signature', which implies all signature flags at once, and 'signature', which maps to NSS_USE_ANY_SIGNATURE. NOTE: disable=all/signature and disable=all/all-signature are effective equivalent because cert-signatures eventually call the low level signature functions, but disable=all allow=rsa-pss/all-signature and disable=all allow=rsa-pss/signature are different in that the latter allows all rsa-pss signature and the latter allows rsa-pss signatures, but no on certificates (or on smime in the future)
Also new keywords were added for rsa-pkcs, rsa-pss, and ecdsa for signature algorithms (along with dsa).
2) This patch implements disable and enable. These functions only work on SSL configuration. In the future SMIME/CMS configuration could also be added. Because the policy system is parsed and handled by NSS, and SSL configuration is handled in SSL, we use the same Apply code we used to apply ssl policy to set the inital configuration. The configured enable/disable state is configured in the ALGORTHIM policy system, where one bit says the enable/disable value is active and another bit which gives it's state.
3) two locks have been implented, policy-lock and ssl-lock. These are specified in the parser as flags (flags=policy-lock,ssl-lock). The policy locks all the policy changes: ssl_policy, algorithm policy, and options. It is implemented by two new exported functions: NSS_IsPolicyLocked() and NSS_LockPolicy(). The first allows applications to test if the policy is locked without having to try changing the policy. The various policy set functions check the NSS_IsPolicyLocked() function and returns SEC_ERROR_POLICY_LOCK if it's true.
The ssl-lock changes the state of the policy to locked, and the state cannot be changed back without shutting down NSS. The second is implemented by setting a new Option called NSS_DEFAULT_LOCKS and the NSS_DEFAULT_SSL_LOCK flag. The idea is we can add an SMIME lock in the future. SSL checks the NSS_DEFAULT_SSL_LOCK flag before trying to set the cipher suite value, and blocks the change if it's set.
4) sslpolicy tests were updated to test the enable, disable, flags=policy-lock, flags=ssl-lock and the new signature primitives.
5) policy tests were updated to be able to run standalone (like all the other all.sh tests), as well as new tests to detect when no signing algorithms have been enabled.
What is not in the patch
1) S/MIME signature policy has been defined for a while, but never hooked up.
2) S/MIME export policy needs to be connected back to the algorithm policy system just like the ssl cipher suites already are.
3) S/MIME default configuration needs to be connected back to the policy system.
4) ECC Curve policy needs to be hooked up with the signature policy (probably should create a generic 'key meets policy' function and have every call it).
|
| |/
|
|
|
|
|
|
|
|
|
| |
Actually, we have the implementation of ARM Crypto extension, so CI is always
run with this extension. It means that we don't run CI without ARM Crypto
extension. So I would like to add NoAES and NoSHA for aarch64 CI.
Also, we still run NoSSE4_1 on aarch64 CI, so we shouldn't run this on aarch64
hardware.
Differential Revision: https://phabricator.services.mozilla.com/D93062
|
| |
|
|
|
|
|
|
|
| |
The in-tree `PayPalEE.cert `expired today. This patch replaces it with a current copy that expires on 12 Jan 2022.
CI breakage before patch: https://treeherder.mozilla.org/#/jobs?repo=nss&revision=2890f342de631bf6774ac747515a8b5736e20d3f
CI with the fix applied: https://treeherder.mozilla.org/#/jobs?repo=nss-try&revision=bd28f21d8acbcb15502bd4fc606fc9c0ed09c810
Differential Revision: https://phabricator.services.mozilla.com/D87481
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D87489
|
| |
|
|
|
|
|
|
|
|
|
| |
This portable code contributed by the Network and Information Security Group (NISEC) at Tampere University comes from:
[ECCKiila](https://gitlab.com/nisec/ecckiila) that uses [Fiat](https://github.com/mit-plv/fiat-crypto) for the underlying field arithmetic.
Co-authored-by: Luis Rivera-Zamarripa <luis.riverazamarripa@tuni.fi>
Co-authored-by: Jesús-Javier Chi-Domínguez <jesus.chidominguez@tuni.fi>
Differential Revision: https://phabricator.services.mozilla.com/D79267
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D81559
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
initialized. r=mt
NSS has several config functions that multiprocess servers must call before NSS is initialized to set up shared memory caches between the processes. These functions call ssl_init(), which initializes the ssl policy. The ssl policy initialization, however needs to happen after NSS itself is initialized. Doing so before hand causes (in the best case) policy to be ignored by these servers, and crashes (in the worst case).
Instead, these cache functions should just initialize those things it needs (that is the NSPR ssl error codes).
This patch does:
1) fixes the cache init code to only initialize error codes.
2) fixes the selfserv MP code to 1) be compatible with ssl.sh's selfserv management (at least on Unix), and 2) mimic the way real servers handle the MP_Cache init code (calling NSS_Init after the cache set up).
3) update ssl.sh server policy test to test policy usage on an MP server. This
is only done for non-windows like OS's because they can't catch the kill signal
to force their children to shutdown.
I've verified that the test fails if 2 and 3 are included but 1 is not
(and succeeds if all three are included).
Differential Revision: https://phabricator.services.mozilla.com/D70948
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Part 2 of 2
Use the official PKCS #11 HKDF mechanism to implement tls 1.3.
1) The new mechanism is a single derive mechanism, so we no longer need to
pick it based on the underlying hmac (Note, we still need to know the
underlying hmac, which is passed in as a mechanism parameter).
2) Use the new keygen to generate CKK_HKDF keys rather than doing it by hand
with the random number generator (never was really the best way of doing this).
3) modify tls13hkdf.c to use the new mechanisms:
1) Extract: use the new key handle in the mechanism parameters to pass the
salt when the salt is a key handle.
Extract: use the explicit NULL salt parameter if for the hash len salt of
zeros.
2) Expand: Expand is mostly a helper function which takes a mechanism. For
regular expand, the mechanism is the normal _Derive, for the Raw version
its the _Data function. That creates a data object, which is extractable
in FIPS mode.
4) update slot handling in tls13hkdf.c:
1) we need to make sure that the key and the salt key are in the same
slot. Provide a PK11wrap function to make that guarrentee (and use that
function in PK11_WrapKey, which already has to do the same function).
2) When importing a 'data' key for the zero key case, make sure we import
into the salt key's slot. If there is no salt key, use PK11_GetBestSlot()
rather than PK11_GetInternal slot.
Differential Revision: https://phabricator.services.mozilla.com/D69899
|
| |
|
|
|
|
| |
Remove support for RSAE in delegated credentials (both in DC signatures and SPKIs), add SignatureScheme list functionality to initial DC extension.
Differential Revision: https://phabricator.services.mozilla.com/D65252
|
| |
|
|
| |
4349f611f7b96de63934837d6940095ac1a5db33 r=bustage
|
| |
|
|
|
|
|
|
|
| |
mode KDFs suitable for use in SCP03 and other protocols. These KDFs were
introduced in PKCS#11 v3.0.
Resolves: BZ#1599603
https://phabricator.services.mozilla.com/D54821
|
| |
|
|
|
|
|
|
|
| |
Disale libnssdbm by default and add flag to enable it in builds.
On CI a build and certs test with enabled legacy DB are added.
Note that for some reason the coverage build fails. I have no idea why. I'm open for ideas.
Differential Revision: https://phabricator.services.mozilla.com/D54673
|
| |
|
|
|
|
| |
fix for prng kat tests
Differential Revision: https://phabricator.services.mozilla.com/D54095
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D49184
|
| |
|
|
|
|
|
|
| |
end-entity certs with default scheme override r=mt
If an end-entity cert has an SPKI type of 'rsaEncryption', override the DC alg to be `ssl_sig_rsa_pss_rsae_sha256`.
Differential Revision: https://phabricator.services.mozilla.com/D49176
|
| |
|
|
|
|
|
|
|
| |
and updated support commands. r=jcj,kjacobs,mt
Added two new fields do scheduled distrust of CAs in nssckbi/builtins.
Also, created a testlib to validate these fields with gtests.
Differential Revision: https://phabricator.services.mozilla.com/D36597
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: rrelyea, mt
Reviewed By: mt
Subscribers: HubertKario
Bug #: 1494063
Differential Revision: https://phabricator.services.mozilla.com/D29166
|
