summaryrefslogtreecommitdiff
path: root/lib/ssl
Commit message (Collapse)AuthorAgeFilesLines
* Bug 1528666 - Formatting, a=bustageMartin Thomson2019-08-221-5/+6
|
* Bug 1528666 - Correct resumption validation checks, r=jcjMartin Thomson2019-08-201-7/+38
| | | | | | | | | | | | | | | 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
* Bug 1568803 - More tests for client certificate authentication, r=kjacobsMartin Thomson2019-08-221-1/+1
| | | | | | | | | 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
* Bug 1572593 - Reset advertised extensions in ssl_ConstructExtensions ↵J.C. Jones2019-08-141-0/+3
| | | | | | | | | | 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
* Bug 1572791 - Check for nulls in SSLExp_DelegateCredential and its tests ↵J.C. Jones2019-08-131-0/+5
| | | | | | | | | r=kjacobs This particularly catches test errors in tls_subcerts_unittest when the profile is stale. Differential Revision: https://phabricator.services.mozilla.com/D41429
* Bug 1516593 - Client to generate new random during renegotiation. r=mtKevin Jacobs2019-07-311-2/+3
| | | | | | | | 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
* Bug 1564727 - RSS PSS SPKI for delegated credentials, r=kjacobsMartin Thomson2019-07-101-9/+156
| | | | Differential Revision: https://phabricator.services.mozilla.com/D37521
* Bug 1563078 - Set authKeyBits for delegated credentials, r=jcjMartin Thomson2019-07-155-94/+128
| | | | | | | | | | | | | | | | | | | | | 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
* Bug 1561556 - Remove -Wmaybe-uninitialized warning in tls13esni.c ↵Giulio Benetti2019-07-101-1/+1
| | | | r=marcusburghardt,jcj
* Bug 1540403 - draft-ietf-tls-subcerts-03, r=mt,jcjChristopher Patton2019-06-2520-53/+1145
| | | | Differential Revision: https://phabricator.services.mozilla.com/D25654
* Bug 1561523 - Add string for ↵Martin Thomson2019-06-261-0/+15
| | | | | | SSL_ERROR_MISSING_POST_HANDSHAKE_AUTH_EXTENSION, r=ueno Differential Revision: https://phabricator.services.mozilla.com/D35989
* Bug 1558681 - Free the anti-replay context, a=bustageMartin Thomson2019-06-261-0/+1
|
* Bug 1558681 - Anti-replay contexts, r=jcj,kjacobsMartin Thomson2019-06-255-89/+180
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Bug 1556591 - Eliminate races in uses of PK11_SetWrapKey, r=kjacobsMartin Thomson2019-06-251-0/+12
| | | | | | | | | | | | 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
* Bug 1555207 - Option to reject 0-RTT in HRR callback, r=jcj,kjacobsMartin Thomson2019-05-292-12/+25
| | | | Differential Revision: https://phabricator.services.mozilla.com/D32940
* Bug 1558126, sslinfo: mark TLS_AES_256_GCM_SHA384 as FIPS compatible, r=rrelyeaDaiki Ueno2019-06-101-1/+1
|
* Bug 1471126 - Fix versions in document of new info fields, r=KevinJacobsMartin Thomson2019-06-031-2/+2
| | | | | | | | | | | | | | | Summary: In D1992, @glandium pointed out an error in the comments. There is the bigger question of forward compatibility there, but this is just to fix the obvious error. Reviewers: KevinJacobs Tags: #secure-revision Bug #: 1471126 Differential Revision: https://phabricator.services.mozilla.com/D33433
* Bug 1553443, send session ticket only after handshake is marked as finishedDaiki Ueno2019-05-291-2/+6
| | | | | | | | | | Reviewers: mt Reviewed By: mt Bug #: 1553443 Differential Revision: https://phabricator.services.mozilla.com/D32128
* Bug 1515236 - Centralize a SSLKEYLOGFILE enable/disable flag at build.sh r=mtJ.C. Jones2019-01-241-5/+5
| | | | | | Backs out backout 31656990b5d083f97aecc3bb9ff0685e7f444bbb Differential Revision: https://phabricator.services.mozilla.com/D17380
* Bug 1552208, prohibit use of RSASSA-PKCS1-v1_5 algorithms in TLS 1.3, r=mtDaiki Ueno2019-05-281-0/+20
| | | | | | | | | | | | | | Reviewers: mt Reviewed By: mt Subscribers: mt, jcj, ueno, rrelyea, HubertKario, KevinJacobs Tags: #secure-revision, #bmo-crypto-core-security Bug #: 1552208 Differential Revision: https://phabricator.services.mozilla.com/D32454
* Bug 1543874 - Use an external clock for SSL functions, r=ekr,kevinjacobsMartin Thomson2019-05-2013-147/+162
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This adds a new (experimental) API that allows users of libssl to provide their own clock function. This is primarily of use in testing, but it also enables our QUIC implementation, which also runs off an external clock. SSL Sockets (and session IDs, when they are in memory) now have a "now()" function and void* arg attached to them. By default, this is a function that calls PR_Now(). These values are copied from the socket to any session ID that is created from the socket, and to any session ID that is restored from the session cache. The ssl_Time() and ssl_TimeUsec() functions have been removed. As part of this, the experimental SSL_SetupAntiReplay() function had to be modified to take an external clock (PR_Now() suffices generally). That function relies on knowing the time, and it doesn't have a socket to work from. To avoid problems arising from the change in the signature, SSL_SetupAntiReplay is now removed. There are now three uses of time in the library: * The primary source of time runs of these newly added functions. This governs session expiry, 0-RTT checks, and related functions. * The session cache uses a separate time to manage its locking. This is of type PRUint32 in seconds (rather than PRTime in microseconds). In investigating this, I found several places where this time in seconds was leaking across to the main functions via the lastAccessTime property. That was fixed. The cache functions that use time now all call ssl_CacheNow() to get time. * DTLS timers run using PRIntervalTime. This is a little annoying and these could be made to use the main time source, but that would result in conversions between PRTime and PRIntervalTime at the DTLS API. PRIntervalTime has a different epoch to PRTime, so this would be a little awkward. Only the first of these can be controlled using the new API. Bugs found: * Expiration time of resumption tokens was based on the sid->expirationTime, which didn't account for the lifetime provided by the server. These are now capped by the minimum of ssl_ticket_lifetime and the value the server indicates. I removed ssl3_sid_timeout, the old limit, because inconsistent lifetimes between client and server messed with tests. The client would have a lower cap than the server, which prevented testing of the enforcement of server limits without jumping through hoops. * There was a missing time conversion in tls13_InWindow which made the window checks too lenient. * lastAccessTime was being set to seconds-since-epoch instead of microseconds-since-epoch in a few places. Reviewers: ekr, KevinJacobs Reviewed By: KevinJacobs Subscribers: cjpatton Bug #: 1543874 Differential Revision: https://phabricator.services.mozilla.com/D27238
* Bug 1487597 - Used sized pointer, fix name shadowing, a=bustageMartin Thomson2019-05-022-2/+2
|
* Bug 1487597 - Improve 0-RTT data delivery, r=ekrMartin Thomson2018-09-102-15/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This improves the code that delivers 0-RTT. When the caller provided a read buffer to small to hold an entire record, the previous code reported errors. Those errors might cause the connection to be dropped by the caller, but the socket was still usable. If the socket was used again, there would be a gap in the stream. This fixes that bug and adds a bunch of tests around 0-RTT delivery. More tests check the order of operations. For instance, in TLS, we strictly maintain ordering between 0-RTT data delivery and handshake completion. That is not the case for DTLS, where this allows 0-RTT records that arrive before the handshake completes to be read afterwards. We do drop keys as soon as we see EndOfEarlyData (this is going away for DTLS, so I assume Certificate/Finished will be the trigger eventually). The tests added here confirm that late arrival causes 0-RTT to be dropped. Another test confirms that any early arrival that is only read late will be delivered. Reviewers: ekr Subscribers: mt, ekr Tags: #secure-revision, PHID-PROJ-ffhf7tdvqze7zrdn6dh3 Bug #: 1487597 Differential Revision: https://phabricator.services.mozilla.com/D4736
* Bug 1532312, recognize certificate_required alert, r=mtDaiki Ueno2019-04-084-1/+14
| | | | | | | | | | | | Summary: Some servers send a certificate_required alert when the client returns no certificate while it is required. For server, it is not mandatory to send this alert, but it could make it easier for the client to distinguish bad_certificate and the declined cases. Reviewers: mt Reviewed By: mt Bug #: 1532312 Differential Revision: https://phabricator.services.mozilla.com/D22083
* Bug 1532312, fix transcript-hash calculation after handshake, r=mtDaiki Ueno2019-04-087-40/+217
| | | | | | | | | | | | | | | | | Summary: In post-handshake, Handshake Context should be: ``` ClientHello ... client Finished + CertificateRequest ``` while NSS continues feeding any handshake message after handshake. Reviewers: mt Reviewed By: mt Bug #: 1532312 Differential Revision: https://phabricator.services.mozilla.com/D21935
* Bug 1538479 - clang-format, a=bustageMartin Thomson2019-03-241-9/+8
| | | | This is a totally weird choice of formatting.
* Bug 1538479 - Accept post-handshake messages after record layer separation ↵Martin Thomson2019-03-231-6/+18
| | | | | | | | | | | | handshake, r=ekr Reviewers: ekr Tags: #secure-revision Bug #: 1538479 Differential Revision: https://phabricator.services.mozilla.com/D24603
* Bug 1529813 - Expose Hkdf-Expand-Label with mechanism, r=ekrMartin Thomson2019-03-154-6/+59
| | | | | | | | | | | | | | | | | Summary: It turns out that leaf keys sometimes need to be exposed with different mechanisms and sizes. The default function provides something good enough for use with the AEAD functions that were exposed, but if you want to use the key directly, that isn't enough. So here we are: new arguments for specifying the mechanism and key size are needed. Reviewers: ekr Tags: #secure-revision Bug #: 1529813 Differential Revision: https://phabricator.services.mozilla.com/D23596
* Bug 1517714 - Properly handle ESNI with HRR, r=mtEkr2019-03-144-7/+15
|
* Bug 1535122 - Align TLS 1.3 HKDF trace levels, r=mtEkr2019-03-141-1/+1
|
* Bug 1530472 - handle issue when server ECC key is in a token that doesn't ↵Robert Relyea2019-03-073-6/+55
| | | | | | handle the TLS mechanisms. Differential Revision: https://phabricator.services.mozilla.com/D22625
* Bug 1529813 - Expose HKDF-Expand-Label, r=ekrMartin Thomson2019-02-264-17/+20
| | | | | | | | | | | | | Summary: I forgot about packet number encryption. This will help with that. I decided to replace DeriveSecret with this. No point in having that when you have this. Reviewers: ekr Bug #: 1529813 Differential Revision: https://phabricator.services.mozilla.com/D20937
* Bug 1493936, add a new "DSA" policy keyword, r=kaieDaiki Ueno2019-02-211-0/+32
| | | | | | | | | | | | | | | Summary: This adds a new policy keyword "DSA" to explicitly disable DSA in TLS 1.2 or earlier. We could make this a bit more generic, e.g., by adding "ECDSA", "RSA-PSS" etc. However, considering the current use of policy in [fedora-crypto-policies](https://gitlab.com/redhat-crypto/fedora-crypto-policies), I realized that adding new keywords may cause compatibility problems; because the Fedora configuration has `disallow=ALL`, all new keywords would be disabled by default. I think it's okay for DSA, though. Reviewers: kaie Reviewed By: kaie Bug #: 1493936 Differential Revision: https://phabricator.services.mozilla.com/D6777
* Bug 1529813 - Expose TLS HKDF functions for QUIC, r=ekrMartin Thomson2019-02-215-10/+79
| | | | | | | | | | | | | | | Summary: This just does the two functions that QUIC needs. I reused the tests for HKDF for testing that the exposed function works identically, at least for those cases where DeriveSecret can be used. Reviewers: ekr Tags: #secure-revision Bug #: 1529813 Differential Revision: https://phabricator.services.mozilla.com/D20762
* Bug 1528175 - Include version in SSL_MakeAead arguments, r=ekrMartin Thomson2019-02-213-26/+48
| | | | | | | | | | | | | | | Summary: We should really include version with the ciphersuite in case we decide to reuse the ciphersuite definitions for TLS 1.4, but also change the way they operate. I also included a fixup for the clang4 build error from the last set. Reviewers: ekr Tags: #secure-revision Bug #: 1528175 Differential Revision: https://phabricator.services.mozilla.com/D20761
* Bug 1528175 - Expose an AEAD function, r=ekrMartin Thomson2019-02-1713-93/+358
|
* Bug 1471126 - Fix return codes from SSL_ForceHandshake and ↵Martin Thomson2019-02-201-10/+15
| | | | | | | | | | | | | | | | | | | SSL_RecordLayerData, r=ekr Summary: Turns out that there were two errors that made my life using SSL_RecordLayerData hard: * SSL_ForceHandshake was returning SECFailure/PR_WOULD_BLOCK_ERROR when the record layer was replaced, even when the handshake was complete. This was being obscured in the tests by the fact that we mark sockets as complete through both the callback and SSL_ForceHandshake. I didn't change that aspect of the tests because different tests rely on that being the case. I don't have a good strategy for dealing with that, but I will continue to think on it. * SSL_RecordLayerData was returning SECFailure/PR_WOULD_BLOCK_ERROR when it succeeded, but the AuthCertificate callback blocked. The contract for SSL_RecordLayerData is that it returns SECSuccess always. I had explicitly ignored this error in tests, which was just a mistake. Reviewers: ekr Tags: #secure-revision Bug #: 1471126 Differential Revision: https://phabricator.services.mozilla.com/D20528
* Bug 1471970, add support for post-handshake authentication, r=mtDaiki Ueno2019-02-2012-22/+268
| | | | | | | | | | | | Summary: This adds handling of the post_handshake_auth extension in CH and exposes tls13_SendCertificateRequest as an experimental API. For practical use, it might need another function that checks if the post_handshake_auth extension is received. Reviewers: mt Reviewed By: mt Bug #: 1471970 Differential Revision: https://phabricator.services.mozilla.com/D14154
* Bug 1471126 - Provide extra information needed to use record layer ↵Martin Thomson2018-10-237-97/+141
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | separation, r=ekr This started as an attempt to remove the cipher spec update callback we use for testing. Using the new, public secrets interface should be better for that. In doing so, it became apparent that we needed more interfaces to NSS to support the use of these secrets. In particular: 1. We need to know what the KDF hash function is for a given cipher suite. This allows users of the secret to use the right hash function. 2. We need to know what cipher spec was picked when sending 0-RTT. NSS currently doesn't expose that information. (When receiving 0-RTT you can safely assume that the negotiated cipher suite is good to use.) 3. We need to know what epoch NSS is currently using. Otherwise, we can't be sure which epoch to feed it. Data from a good epoch is saved, whereas data from a bad epoch is lost, so applications need to know. So this patch adds these functions to the appropriate info functions and uses that information in tests to remove and re-add protection. The test changes are considerable. The main effect of the changes is to rely on the new functions for managing secrets, rather than the old interface. But with the changes in the other CLs for this bug, secrets appear before they are used, which complicates things considerably. For that, I've moved more logic into the TlsCipherSpec class, which now tracks per-epoch state, like sequence numbers and record drops. Trial decryption (yep) is used to identify the right cipher spec every time when decrypting, so tests are no longer tolerant of failures to decrypt. It's no longer possible to have a test enable decryption and pass when decryption fails; this is particularly true for some parameterized tests that assumed it was OK to enable decryption even for TLS 1.2 and earlier.
* Bug 1471126 - Record layer separation, r=ekrMartin Thomson2019-02-1710-207/+314
| | | | | | | | | | | | | Summary: Add functions for QUIC that provide the raw content of records to callback functions. Reviewers: ekr Reviewed By: ekr Bug #: 1471126 Differential Revision: https://phabricator.services.mozilla.com/D1874
* Bug 1471126 - Provide a callback for traffic secrets, r=ekrMartin Thomson2019-02-1710-75/+160
| | | | | | | | | | | | | Summary: Provide updated secrets to a callback function as soon as those secrets are available. Reviewers: ekr Reviewed By: ekr Bug #: 1471126 Differential Revision: https://phabricator.services.mozilla.com/D1824
* Bug 1520459 - Send decode_error for padded record_size_limit extension, r=jcjMartin Thomson2019-02-131-1/+1
| | | | | | | | | | | | Summary: This is all I plan to do for this bug. Reviewers: jcj Tags: #secure-revision Bug #: 1520459 Differential Revision: https://phabricator.services.mozilla.com/D19576
* Bug 1160721 - Remove double spacing in SSLerrs.h and SECerrs.h strings r=jcjui.manish2019-01-281-4/+4
| | | | Differential Revision: https://phabricator.services.mozilla.com/D17721
* Backed out changeset 32ad1532c67aJ.C. Jones2019-01-271-5/+5
|
* Bug 1515236 - Centralize a SSLKEYLOGFILE enable/disable flag at build.sh r=mtJ.C. Jones2019-01-241-5/+5
|
* Bug 1515236 - Initialize debug environment variables before use r=mtJ.C. Jones2019-01-221-0/+2
|
* Bug 1490006, reject invalid CH.legacy_version in TLS 1.3Daiki Ueno2019-01-021-0/+7
| | | | | | | | | | | | Summary: As suggested in RFC 8446 Appendix D.5, TLS 1.3 server should send protocol_version alert in response to a ClientHello with legacy_version set to 0x300 or smaller. Reviewers: mt Reviewed By: mt Bug #: 1490006 Differential Revision: https://phabricator.services.mozilla.com/D11870
* Bug 1485864 - improve RSA key exchange handling, r=mtFranziskus Kiefer2018-10-261-26/+31
| | | | Differential Revision: https://phabricator.services.mozilla.com//D9914
* Bug 1507179, reject CCS after handshake is complete in TLS 1.3, r=mtDaiki Ueno2018-11-293-11/+15
| | | | | | | | | | | | | | Reviewers: mt Reviewed By: mt Subscribers: mt, ekr, franziskus, ueno Tags: #secure-revision, PHID-PROJ-ffhf7tdvqze7zrdn6dh3 Bug #: 1507179 Differential Revision: https://phabricator.services.mozilla.com/D12887
* Bug 1412829, reject empty supported_signature_algorithms in CR in TLS 1.2, r=mtDaiki Ueno2018-11-221-8/+9
| | | | | | | | | | | | Summary: This basically reverts bug 1335069 to align with RFC 5246. Reviewers: mt Reviewed By: mt Bug #: 1412829 Differential Revision: https://phabricator.services.mozilla.com/D12563
View Lorry Controller Status