| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D43200
|
|
|
|
|
|
|
| |
Looks good and it was already tested locally with this gtest patch:
https://phabricator.services.mozilla.com/D42026
Differential Revision: https://phabricator.services.mozilla.com/D37991
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We allowed cross-suite resumption before, but it didn't work. This enables that
for clients.
As a secondary minor tweak, clients will no longer validate the availability of
a cipher suite based on their configured version range when attempting
resumption. Instead, they will check whether the suite works for the version
in the session that they are attempting to resume. In theory, this doesn't
change anything because the previous session should not have selected an
incompatible combination of version and cipher suite, but it's worth being extra
precise.
Differential Revision: https://phabricator.services.mozilla.com/D20119
|
|
|
|
|
|
|
|
|
| |
These were previously disabled because of difficulties (at the time) in writing
these tests for TLS 1.3. The framework, and my understanding of it, has since
improved, so these tests can be restored and expanded. This exposed a
minor correctness issue that is also corrected.
Differential Revision: https://phabricator.services.mozilla.com/D39639
|
|
|
|
|
|
| |
UTN-USERFirst-Client, Deutsche Telekom Root CA 2. r=jcj,KathleenWilson
Differential Revision: https://phabricator.services.mozilla.com/D42633
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D41640
|
|
|
|
|
|
|
|
| |
#define SQLITE_VERSION "3.29.0"
#define SQLITE_VERSION_NUMBER 3029000
#define SQLITE_SOURCE_ID "2019-07-10 17:32:03 fc82b73eaac8b36950e527f12c4b5dc1e147e6f4ad2217ae43ad82882a88bfa6"
Differential Revision: https://phabricator.services.mozilla.com/D42332
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D42161
|
|
|
|
|
|
|
|
|
|
| |
r=mt,kjacobs
Reset the list of advertised extensions before sending a new set.
This reverts the changes of https://hg.mozilla.org/projects/nss/rev/1ca362213631d6edc885b6b965b52ecffcf29afd
Differential Revision: https://phabricator.services.mozilla.com/D41302
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D41884
|
|
|
|
|
|
| |
This patch adds additional length checks around cryptographic primitives.
Differential Revision: https://phabricator.services.mozilla.com/D36079
|
|
|
|
|
|
| |
r=jcj,kjacobs
Differential Revision: https://phabricator.services.mozilla.com/D40649
|
|
|
|
|
|
|
|
|
| |
r=kjacobs
This particularly catches test errors in tls_subcerts_unittest when the profile
is stale.
Differential Revision: https://phabricator.services.mozilla.com/D41429
|
|
|
|
|
|
| |
Adds Wycheproof test vectors for AES-KW and fix a correctness issue.
Differential Revision: https://phabricator.services.mozilla.com/D38924
|
|
|
|
|
|
| |
The recent x25519 update added some assertions in `curve25519_32.c`. For these, we need to include a new header file in order to support Makefile builds on armv7.
Differential Revision: https://phabricator.services.mozilla.com/D40752
|
|
|
|
|
|
|
|
| |
This patch adds `client_hello_renegotiation` to the list of //sslClientHelloTypes// for which a new `client_random` is generated.
It also adds renegotiation tests to confirm that new client and server (for completeness) randoms are generated during renegotiation.
Differential Revision: https://phabricator.services.mozilla.com/D39248
|
|
|
|
|
|
| |
arm_aes_encrypt_cbc_128 on Android 8.0 Pixel2 pgo
See bug 1570991
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D34473
|
|
|
|
| |
r=marcusburghardt,jcj
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D39444
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: rrelyea
Reviewed By: rrelyea
Bug #: 1453408
Differential Revision: https://phabricator.services.mozilla.com/D38459
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D37521
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The delegated credentials patch left the channel info unmodified, which meant
that it reported the key strength of the end entity certificate and not the
delegated credential. For a using application, this is problematic because it
can't access information about delegated credentials. In this case, the only
omission was the strength of the key.
Firefox checks key strength for the entire certificate chain according to its
policies, but it also wants to apply the same sort of policy to the delegated
credential. In particular, it wants to ensure that an RSA credential (which
shouldn't be used, but whatever...) has a long enough modulus, because the NSS
policy is less strict than the Firefox one.
To address this use case, SSLChannelInfo.authKeyBits is set to the length of the
delegated credential key when delegated credentials are in use. This is
consistent with the definition of the parameter, but implies a different
understanding of its meaning when delegated credentials are enabled.
Differential Revision: https://phabricator.services.mozilla.com/D36699
|
|
|
|
|
|
|
| |
Seems clang's inline assembler doesn't want registers to be prefixed with "r",
while gcc accepts both - r0 and 0 for GPR0.
tested with clang 6.0 and gcc 8.1
|
|
|
|
| |
pkix_pl_ldapdefaultclient.c r=marcusburghardt,jcj
|
|
|
|
|
|
|
|
| |
According to issue tracker of BoringSSL (https://bugs.chromium.org/p/boringssl/issues/detail?id=46), some ARMv8 devices won't have `AT_HWCAP2`. So even if SoC supports AES etc, NSS doesn't detect ARM extensions. So we should read `/proc/cpuinfo` if `AT_HWCAP2` returns 0.
This detection code is from `mozglue/build/arm.cpp` in mozilla-central.
Differential Revision: https://phabricator.services.mozilla.com/D38166
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D37680
|
| |
|
|
|
|
| |
r=marcusburghardt,jcj
|
|
|
|
| |
r=marcusburghardt,jcj
|
| |
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D37099
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implementation is from the paper of https://conradoplg.cryptoland.net/files/2010/12/gcm14.pdf
benchmark of `bltest -E -m aes_gcm -i tests/aes_gcm/plaintext10 -v tests/aes_gcm/iv10 -k tests/aes_gcm/key10 -5 10` on Cortex-A72 (AWS a1)
### Before
```
# mode in symmkey opreps cxreps context op time(sec) thrgput
aes_gcm_e 265Mb 192 4M 0 0.000 10000.000 10.000 26Mb
```
### After
```
# mode in symmkey opreps cxreps context op time(sec) thrgput
aes_gcm_e 659Mb 192 11M 0 0.000 10000.000 10.000 65Mb
```
Differential Revision: https://phabricator.services.mozilla.com/D34995
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r=jcj,mt,mhoye
This patch changes the 32-bit Curve25519 implementation in NSS from ref to fiat-crypto (https://github.com/mit-plv/fiat-crypto). There is no HACL* variant available for 32-bit platforms.
A helpful benchmark comparison is here: https://bench.cr.yp.to/impl-scalarmult/curve25519.html. fiat-crypto proved to be ~5-8% faster than ref10 in my tests.
**Notes about this patch: **
1) MIT license is listed as compatible in https://docs.google.com/document/d/1Oguqp43W4_ChyroJ9AJAzG1jSwkUWfKvBKVvrDxVsMg/, but mhoye will have to approve before landing
Differential Revision: https://phabricator.services.mozilla.com/D33725
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D25654
|
|
|
|
|
|
| |
SSL_ERROR_MISSING_POST_HANDSHAKE_AUTH_EXTENSION, r=ueno
Differential Revision: https://phabricator.services.mozilla.com/D35989
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stop using a global anti-replay context and enable creating a context directly.
This increases the overhead of managing anti-replay for applications marginally,
but allows much greater flexibility in use of anti-replay mechanisms. In
particular, it enables the testing of 0-RTT in a threaded environment.
The comments in sslexp should be clear enough in explaining how this works.
Basically, this is a new reference-counted object that can be created and
tracked by applications.
The only thing that I can see might be a problem with the API is that I haven't
exposed a function to add a reference for use by applications. My thinking is
that reference counting is an internal thing; it seems like applications won't
need to worry about that.
selfserv is updated to create a context and attach it to sockets. This shows
that the management overhead is minor.
The gtests have been tweaked to create a context during setup. The context is
owned by the overall test framework and is passed to server instances after the
sockets are initialized.
Bonus changes:
* ESNI keys are copied from the model socket when calling SSL_ReConfigFD().
* Some better tracing in the anti-replay functions.
Neither of these seemed worth the overhead of a bug to fix.
Differential Revision: https://phabricator.services.mozilla.com/D34660
|
|
|
|
|
|
|
|
|
|
|
|
| |
These functions are terrible, but in the spirit of ABI compatibility, I
can't really change their signature. And it isn't important enough to fix them,
so this introduces a quick hack.
This is wrapped up in the mess that is Bug 1556588, but I'm proceeding here
under the assumption that unconditional use of the lock is safe and that a
non-thread-safe module will explode in many other ways.
Differential Revision: https://phabricator.services.mozilla.com/D34650
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D32940
|
| |
|
| |
|
|
|
|
|
|
| |
All part of applying better discipline throughout.
Differential Revision: https://phabricator.services.mozilla.com/D33736
|
|
|
|
|
|
| |
PKCS11 import. r=jcj,mt
Differential Revision: https://phabricator.services.mozilla.com/D31671
|
|
|
|
|
|
| |
lcc (the Elbrus C Compiler) has no __int128 support
before version 1.24 being developed at the moment,
still it pretends to be gcc5 confusing the tests.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Differential Revision: https://phabricator.services.mozilla.com/D28519
Patch notes:
cmd/fipstest:
Update fipstest to allow using old CAVS vectors in our all.sh. The various scripts have been moved to tests/fips/cavs_scripts. IKE functions were added to fipstest, and fipstest was updated to support verifying the output of ecdh and dh key agreement tests (kas).
fipstest.c:
NOTE: fipstest is the program NSS uses to process CAVS vectors from NIST. For historical reasons, it has known memory management issues. In general if there is a mistake, fipstest will likely crash. It has very little error checking. It has a very simplistic parser for the CAVS files. It requires the elements of the CAVS files to be in the correct order (most notably it requires the last element to always be in the last position. This is true of all the tests in fipstest, not just the new code.
1. when verifying ec_dh and dh, accept both CAVSHashZZ and HashZZ as the input hash. This allows verify not only to verify NIST CAVS vectors, but also the output of ec_dh and dh functional tests.
2. create ike functions modelled after the tls test functions. We test ike at the pkcs #11 level. There are three ike tests (driven by the three types of ike tests that NIST supplies):
2.1) ikev1. This generates the ike v1 keys from the provided input. It used ike_prf to generate SKEYID and ikev1_prf to generate SKEYID_d, SKEYID_a, and SKEYID_e.
2.2) ikev1_psk. This generates ike v1 keys from the provided input. It uses a pre-shared-secret-key. It also
used ike_prf to generate SKEYID (though it uses it with bDataAsKey=false), and ikev1_prf to generate SKEYID_d, SKEYID_a, and SKEYID_e.
2.3) ikev2. This generates ike v2 keys from the provided input. It uses ike_prf to generate SKEYSEED and ike_prf_plus to generate the key material. It also does a rekey using ike_prf and bRekey = true.
3. Add parameters so the tls can be called.
lib/softoken
This is the main location where the new functionality is provided.
fipstest.c
Add the power up self test for ike. The actual test lives in sftkike.c.
manifest.mn
Add sftkike.c to the build.
pkcs11.c
Add AES XCBC MAC and IKE Mechanisms to the softoken mechanism table.
pkcs11c.c
sftk_MapCryptError() is now a 'global' within softoken and lives in pkcs11u.c. This was done so that sftkike.c can use it.
sftk_InitCBCMac(). Update to handle AES XCBC., which is AES CBC MAC except 1) the underlying AES key is derived from the input key, and 2) the pad block is obscured using 2 new keys (k2, k3) also derived from the input key.
sftk_MACFinal() handle the special pad processing for the XCBC case.
sftk_MACUpdate() change the padding code to keep one full pad in the buffer. This won't affect normal MACs, but means that the last block in the Mac is always in the buffer so it can be processed in the XCBC case.
NSC_DerviceKey() add the ike functions into the mechanism swtich table. The actual implementations are in sftkike.c
pkcs11i.h
Add the XCBC state information into the SessionContext structure.
sftk_MapCryptError is now global, include it in the header.
include the ike and aes_xcbc helper functions.
pkcs11u.c
sftk_MapCryptError() now lives in pkcs11 utilities.
sftkike.c
prf_* functions implement all the underlying prf specific stuff. It hides whether the prf is an hmac or aes_xcbc. If there are additional prfs, they can be implemented here without affecting the rest of the derivation code. The AES_XCBC code is aes specific. If we ever add another XCBC type operation, we would probably want to initialize some encryption functions in prf_setup and only handle the difference between hmac and xcbc in the other prf functions.
sftk_aes_xcbc_get_keys - takes in input key and derives k1, k2, and k3. This function handles this derivation for both the prf_ functions in sftkike and the exported AES_XCBC Mac in pkcs11c.c
sftk_xcbc_mac_pad - function to handle the correct padding method for the last block of an xcbc operation. Unlike sftk_aes_xcbc_get_keys, it is independent of the xcbc's underlying encryption method, though only AES_XCBC is defined at this time.
sftk_ike_prf - common prf between ikev1 and ikev2 to generate SKEYID/SKEYSEED. See comments in code.
sftk_ike1_prf - ikev1 prf to generate the session keys in ikev1 from SKEYID. See comments in code.
sftk_ike_prf_plus - ike prf+ to generate the session keys in ikev2 from SKEYSEED. See comments in code.
sftk_aes_xcbc_new_keys - used in pkcs11c.c to generate the 2 derived keys used in aes_xcbc. Loads k1 into the pkcs11 slot as a session key.
prf_test - helper function to test our known test vectors for our FIPS powerup self tests.
sftk_fips_IKE_PowerUpSelfTests - test to make sure our basic system is working correctly.
softokn.gyp - add sftkike.c to gyp
lib/util
pkcs11n.h
add defines and structures for IKE. Since they are not yet an official PKCS #11 mechanism, use CKM_NSS and CK_NSS names for them.
pkcs11t.h
add CKM_AES_XCBC* mechanisms. These are defined in the latest PKCS #11 spec.
tests/fips
The work in this directory hooks up the CAVS tests we run to do fips validation into our normal test suite. This lets us use the NIST generated samples for
cavs_samples/* These are all vectors generated by the NIST CAVS tools (*.req) or the expected results generated by the last openssl or NSS runs and verified by the NIST CAVS tools (*.fax). These are the inputs to our fipstest. No need to detail review these. The are not explicitly included in this patch because they are too big for phabricator to handle.
cavs_scripts/* See the read me in that directory. These scripts were originally in cmd/fipstest. I added ike.sh, and I updated the verify target of all the scripts so they they return 0 on success and 1 on failure. This allows us to use the tests in fips.sh
fips.sh run the CAVS tests as part of the fips tests. This works to test our IKE support. Three of the cavs tests can take significant type (dsa and rsa takes several minutes, tdea is just over a minute). The code currently skips running those tests. You can run all the cavs tests by setting CAV_VECTORS=all
|