searching for reviewer(ekr)
0556b3040451e8a7ca0a499005993a95921754d4: Bug 1543874 - Use an external clock for SSL functions, r=ekr,kevinjacobs
Martin Thomson <mt@lowentropy.net> - Mon, 20 May 2019 09:45:56 +0100 - rev 15126
Push 3365 by martin.thomson@gmail.com at Mon, 20 May 2019 11:05:18 +0000
Bug 1543874 - Use an external clock for SSL functions, r=ekr,kevinjacobs 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
b56a298b42752de328f18a8514a1db80069b2b16: Bug 1487597 - Improve 0-RTT data delivery, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Mon, 10 Sep 2018 11:47:55 +1000 - rev 15093
Push 3334 by martin.thomson@gmail.com at Thu, 02 May 2019 04:01:33 +0000
Bug 1487597 - Improve 0-RTT data delivery, r=ekr 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
893fff17234f9fb28b692166109122e04d685e98: Bug 1534468 - Expose ChaCha20 primitive through PKCS#11, r=ekr
Martin Thomson <mt@lowentropy.net> - Tue, 12 Mar 2019 10:37:17 +1100 - rev 15087
Push 3328 by martin.thomson@gmail.com at Fri, 26 Apr 2019 07:00:42 +0000
Bug 1534468 - Expose ChaCha20 primitive through PKCS#11, r=ekr Summary: This adds a "CTR" mode for ChaCha20. This takes a composite 16 octet "IV", which is internally decomposed into a nonce and counter. This operates like a CTR mode cipher on arbitrary input, up to the ChaCha20 limit of 2^32 x 64 octet blocks. The counter provided is a starting counter and it is incremented if more than 64 octets of input is provided. Reviewers: ekr Tags: #secure-revision Bug #: 1534468 Differential Revision: https://phabricator.services.mozilla.com/D23060
3359040b2c8f8ec6ecb355a405280a0367e87742: Bug 1538479 - Accept post-handshake messages after record layer separation handshake, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Sat, 23 Mar 2019 14:10:09 +0100 - rev 15071
Push 3314 by martin.thomson@gmail.com at Sun, 24 Mar 2019 10:30:02 +0000
Bug 1538479 - Accept post-handshake messages after record layer separation handshake, r=ekr Reviewers: ekr Tags: #secure-revision Bug #: 1538479 Differential Revision: https://phabricator.services.mozilla.com/D24603
cf30a49bf53e6ae06a55c4ed63302c893c072b74: Bug 1529813 - Expose Hkdf-Expand-Label with mechanism, r=ekr NSS_3_43_BRANCH NSS_3_43_BETA4
Martin Thomson <mt@lowentropy.net> - Fri, 15 Mar 2019 09:07:53 +1100 - rev 15053
Push 3301 by martin.thomson@gmail.com at Thu, 14 Mar 2019 23:54:38 +0000
Bug 1529813 - Expose Hkdf-Expand-Label with mechanism, r=ekr 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
03d7bcade60aa49fa7561215c83c176d0709b200: Bug 1529813 - Expose Hkdf-Expand-Label with mechanism, r=ekr
Martin Thomson <mt@lowentropy.net> - Fri, 15 Mar 2019 09:07:53 +1100 - rev 15052
Push 3300 by martin.thomson@gmail.com at Thu, 14 Mar 2019 23:53:48 +0000
Bug 1529813 - Expose Hkdf-Expand-Label with mechanism, r=ekr 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
5ea3ab44389052cd2a8174350b86fb8fdadce075: Bug 1529813 - Expose HKDF-Expand-Label, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Tue, 26 Feb 2019 16:07:29 +1100 - rev 15036
Push 3287 by martin.thomson@gmail.com at Sun, 03 Mar 2019 21:54:45 +0000
Bug 1529813 - Expose HKDF-Expand-Label, r=ekr 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
a5f74f7c1d73390d724b40d2a7b5da7605d5fc12: Bug 1529813 - Expose TLS HKDF functions for QUIC, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Thu, 21 Feb 2019 17:43:45 -0800 - rev 15025
Push 3276 by martin.thomson@gmail.com at Sat, 23 Feb 2019 00:02:29 +0000
Bug 1529813 - Expose TLS HKDF functions for QUIC, r=ekr 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
29a507bef51a52f5444037ad90bbebb5ced214fe: Bug 1528175 - Include version in SSL_MakeAead arguments, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Thu, 21 Feb 2019 17:42:24 -0800 - rev 15024
Push 3276 by martin.thomson@gmail.com at Sat, 23 Feb 2019 00:02:29 +0000
Bug 1528175 - Include version in SSL_MakeAead arguments, r=ekr 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
9b0427677190cf3eca2854a80db27a08ab702ade: Bug 1528175 - Expose an AEAD function, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Sun, 17 Feb 2019 15:27:05 -0800 - rev 15023
Push 3275 by martin.thomson@gmail.com at Thu, 21 Feb 2019 22:17:16 +0000
Bug 1528175 - Expose an AEAD function, r=ekr
20543fe8ce40f0bf4fb4a21016d3a3edbb2537c9: Bug 1471126 - Fix return codes from SSL_ForceHandshake and SSL_RecordLayerData, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Wed, 20 Feb 2019 09:43:54 -0800 - rev 15020
Push 3272 by martin.thomson@gmail.com at Thu, 21 Feb 2019 00:29:27 +0000
Bug 1471126 - Fix return codes from SSL_ForceHandshake and 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
c1a1ee048c07fef6ef889e5ff459ddbda8da0273: Bug 1471126 - Provide extra information needed to use record layer separation, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Tue, 23 Oct 2018 15:35:13 +1100 - rev 15018
Push 3270 by martin.thomson@gmail.com at Mon, 18 Feb 2019 16:51:53 +0000
Bug 1471126 - Provide extra information needed to use record layer 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.
4f9d8e9f0b5c1e2806061c2bc848c0618056d57a: Bug 1471126 - Record layer separation, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Sun, 17 Feb 2019 13:07:04 -0800 - rev 15017
Push 3270 by martin.thomson@gmail.com at Mon, 18 Feb 2019 16:51:53 +0000
Bug 1471126 - Record layer separation, r=ekr 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
1a1e0017c77664c7e5e2867a21404b77a9ea97e4: Bug 1471126 - Provide a callback for traffic secrets, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Sun, 17 Feb 2019 12:31:37 -0800 - rev 15016
Push 3270 by martin.thomson@gmail.com at Mon, 18 Feb 2019 16:51:53 +0000
Bug 1471126 - Provide a callback for traffic secrets, r=ekr 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
3b79af0fa294b4b1c009c1c0b659bb72b4d2c1c8: Bug 1423043 - Enable half-close, r=ttaubert,ekr
Martin Thomson <martin.thomson@gmail.com> - Thu, 25 Oct 2018 13:55:30 +1100 - rev 14925
Push 3217 by martin.thomson@gmail.com at Fri, 26 Oct 2018 06:07:19 +0000
Bug 1423043 - Enable half-close, r=ttaubert,ekr Summary: TLS 1.3 explicitly changed to allow close_notify on one half of the connection. Since SSL, an endpoint was required to send close_notify if it received close_notify. The general agreement was that this was a silly requirement and that we would remove it and allow one side of the connection to be closed. This is critical for some protocols that are being moved to use TLS. NSS was almost perfect here. The only problem was that it suppressed the second close_notify. I've added a test for that. Differential Revision: https://phabricator.services.mozilla.com/D797
87b0372b6a2da431630336702ae8c2d0d0fdb04e: Bug 1459824 - Enable 0.5 RTT data from the server, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Tue, 08 May 2018 15:11:14 +1000 - rev 14492
Push 3192 by martin.thomson@gmail.com at Sun, 23 Sep 2018 17:29:06 +0000
Bug 1459824 - Enable 0.5 RTT data from the server, r=ekr This uses the recently added tls13_CanRequestClientAuth() function to determine whether the server is able to request a certificate. If it can, then we disable 0.5 RTT. Note that there are two ways to enable 0.5 RTT as a result: 1. Don't request a client certificate 2. This is a resumption handshake The latter is non-obvious, so I've added a big comment.
8f6014565b91d90ffe67f28a74c4e5cb0d4ab0ec: Bug 1488320 - Cross-version resumption tests, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Tue, 04 Sep 2018 13:30:11 +1000 - rev 14488
Push 3188 by martin.thomson@gmail.com at Thu, 06 Sep 2018 01:34:05 +0000
Bug 1488320 - Cross-version resumption tests, r=ekr This fixes an issue that arises from an interaction between compatibility mode and cross-version resumption in DTLS. The DTLS 1.3 spec has an open PR that makes the spec align with this: https://github.com/tlswg/dtls13-spec/pull/59
f182a11fbe532b1b9edb76a57a0d4609d9d8ab75: Bug 1483128 - Test that randoms aren't fixed, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Tue, 28 Aug 2018 11:58:00 +1000 - rev 14484
Push 3184 by martin.thomson@gmail.com at Mon, 03 Sep 2018 00:15:31 +0000
Bug 1483128 - Test that randoms aren't fixed, r=ekr We can't easily test that ClientHello.random and ServerHello.random are truly random in these tests, but we can catch mistakes the likes of which produced this bug. This just runs a few handshakes and tests that none of the random values are equal to any other, or they are equal to zero.
f14b7ffd05fd8fabc729e6ee5f8c59f82a677860: Bug 1487597 - Don't deliver 0-RTT after processing EndOfEarlyData, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Fri, 31 Aug 2018 15:02:37 +1000 - rev 14482
Push 3183 by martin.thomson@gmail.com at Mon, 03 Sep 2018 00:13:56 +0000
Bug 1487597 - Don't deliver 0-RTT after processing EndOfEarlyData, r=ekr
91b6fb509cb01bbf4466f647cccfa2a2e060c504: Bug 1483416 - Disable false start if there might be a downgrade, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Wed, 15 Aug 2018 10:24:18 +1000 - rev 14456
Push 3169 by martin.thomson@gmail.com at Sun, 26 Aug 2018 23:51:29 +0000
Bug 1483416 - Disable false start if there might be a downgrade, r=ekr
ee357b00f2e6c44589dcd406097357888d59ef06: Bug 1483129 - TLS 1.3 RFC version, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Mon, 09 Jul 2018 12:24:13 +1000 - rev 14455
Push 3169 by martin.thomson@gmail.com at Sun, 26 Aug 2018 23:51:29 +0000
Bug 1483129 - TLS 1.3 RFC version, r=ekr This retains the ability to negotiate draft versions of DTLS 1.3, but uses the final RFC version for TLS 1.3. This also refactors the handling of the downgrade sentinel. As we've discovered - to our dismay - some MitM boxes forward handshake messages when they shouldn't. This could result in triggering the downgrade sentinel. I've done two things here: - The server always sets the sentinel. It reduces the assumed version if it only supports a draft version though on the basis that the client might expect the full version. - The client has a new option SSL_ENABLE_HELLO_DOWNGRADE_CHECK which is disabled by default. The client will reject a handshake that appears to be a downgrade only when this is explicitly enabled. The client will allow an apparent downgrade to TLS 1.2 if it is running a draft version of TLS 1.3. The allowance for a draft version is now only effective for DTLS 1.3. Tests for version downgrade have been updated and enabled. These were rotten in a few ways, but nothing dramatic.
5bc69334e84f04e676626fe94d232827ab28b4d9: Bug 1471967, skip unrecognized session tickets in TLS 1.3, r=ekr
Daiki Ueno <dueno@redhat.com> - Wed, 22 Aug 2018 17:25:03 +0200 - rev 14453
Push 3167 by dueno@redhat.com at Wed, 22 Aug 2018 15:26:10 +0000
Bug 1471967, skip unrecognized session tickets in TLS 1.3, r=ekr Summary: In TLS 1.3, upon receiving a malformed ticket, server doesn't immediately abort the connection, but rejects client's resumption attempt. Reviewers: ekr Reviewed By: ekr Subscribers: mt, ekr, kaie, ueno, rrelyea, HubertKario Tags: #secure-revision, PHID-PROJ-ffhf7tdvqze7zrdn6dh3 Bug #: 1471967 Differential Revision: https://phabricator.services.mozilla.com/D3620
1adf32e363a7ba0d7952ca9c6098b2d5cff2cfe0: Bug 1479988 - Log the TLS 1.3 Finished result, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Wed, 01 Aug 2018 14:16:10 +1000 - rev 14434
Push 3151 by martin.thomson@gmail.com at Wed, 01 Aug 2018 21:58:03 +0000
Bug 1479988 - Log the TLS 1.3 Finished result, r=ekr
ed450ac8ac6de3ca6173032507431d4dd933477c: Bug 1471126 - Rename SSL3ContentType and make it public, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Tue, 26 Jun 2018 15:49:14 +1000 - rev 14412
Push 3130 by martin.thomson@gmail.com at Tue, 03 Jul 2018 05:08:41 +0000
Bug 1471126 - Rename SSL3ContentType and make it public, r=ekr The renaming here is less widespread than I expected. I removed the content_alt_handshake while I was at this; no point in putting that in a public API.
bde45e406ea449f0a6259814587b8508539802d5: Bug 1396487 - Record size limiting extension, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Fri, 24 Nov 2017 16:40:22 +1100 - rev 14382
Push 3111 by martin.thomson@gmail.com at Fri, 01 Jun 2018 09:10:49 +0000
Bug 1396487 - Record size limiting extension, r=ekr Summary: See draft-ietf-tls-record-limit for details. Reviewers: ekr Bug #: 1396487 Differential Revision: https://phabricator.services.mozilla.com/D23
328d235fc7eefe7411bb32b4806203220636a60f: Bug 1423018 - Retain write polling when 0-RTT is enabled, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Tue, 28 Nov 2017 15:56:47 +1100 - rev 14368
Push 3099 by martin.thomson@gmail.com at Thu, 24 May 2018 05:26:53 +0000
Bug 1423018 - Retain write polling when 0-RTT is enabled, r=ekr This is a nasty one. I was having trouble with tstclnt when testing against other implementations. It would hang. I made similar changes to that for kazuho and picotls, where the input file is read for every connection. So, I did that here too and it also worked nicely. In order to get 0-RTT working though, I needed to teach ssl_Poll about 0-RTT. Luckily, there was code already there for that and it just needed a tweak. The only thing I ran into here was that boringssl (the server I was using to test against here), was too fast. By the time we had written out the ClientHello, it had produced a response and we would complete the handshake before leaving the handshake loop in ssl3_Do1stHandshake(). That meant that we would never actually send any 0-RTT data, either before or after this patch. Adding a sleep(1) to the handshake in boringssl did the trick and I could show that we can send data before the handshake completes. Nothing really actionable here unless you can think of ways to make our handshake more performant. Mostly just information. Separately, people have noticed that tstclnt writes 0-RTT after the first round trip. That's a symptom of not retaining the poll on write.
ff35a3edaafb1586d839fca8cdcae53dcdf02ee9: Bug 1462303 - Allow TLS 1.3 compat mode when attempting to resume TLS 1.2, r=ekr,ttaubert NSS_3_36_BRANCH
Martin Thomson <martin.thomson@gmail.com> - Fri, 18 May 2018 12:51:29 +1000 - rev 14359
Push 3091 by martin.thomson@gmail.com at Fri, 18 May 2018 23:09:42 +0000
Bug 1462303 - Allow TLS 1.3 compat mode when attempting to resume TLS 1.2, r=ekr,ttaubert
2f5e8b4bf89729ea5ee18c089e684d4e8138b557: Bug 1462303 - Allow TLS 1.3 compat mode when attempting to resume TLS 1.2, r=ekr,ttaubert NSS_3_37_BRANCH
Martin Thomson <martin.thomson@gmail.com> - Fri, 18 May 2018 12:51:29 +1000 - rev 14358
Push 3090 by martin.thomson@gmail.com at Fri, 18 May 2018 23:03:19 +0000
Bug 1462303 - Allow TLS 1.3 compat mode when attempting to resume TLS 1.2, r=ekr,ttaubert
43018e031dee1b0c7cac16d3de268de3de6d938d: Bug 1462303 - Allow TLS 1.3 compat mode when attempting to resume TLS 1.2, r=ekr,ttaubert
Martin Thomson <martin.thomson@gmail.com> - Fri, 18 May 2018 12:51:29 +1000 - rev 14354
Push 3086 by martin.thomson@gmail.com at Fri, 18 May 2018 06:30:29 +0000
Bug 1462303 - Allow TLS 1.3 compat mode when attempting to resume TLS 1.2, r=ekr,ttaubert
350b7210e90758de454feb4339379ef7f6b9b470: Bug 1452549 - Discard application data that arrives before DTLS handshake completes, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Mon, 09 Apr 2018 17:49:00 +1000 - rev 14349
Push 3081 by martin.thomson@gmail.com at Tue, 08 May 2018 22:06:00 +0000
Bug 1452549 - Discard application data that arrives before DTLS handshake completes, r=ekr
7aacbcdb41d17d5cf242e7ab62b282efd8bbde77: Bug 1423043 - Enable half-close, r=ttaubert,ekr
Martin Thomson <martin.thomson@gmail.com> - Tue, 01 May 2018 10:51:04 +1000 - rev 14341
Push 3074 by martin.thomson@gmail.com at Tue, 01 May 2018 06:49:16 +0000
Bug 1423043 - Enable half-close, r=ttaubert,ekr Summary: TLS 1.3 explicitly changed to allow close_notify on one half of the connection. Since SSL, an endpoint was required to send close_notify if it received close_notify. The general agreement was that this was a silly requirement and that we would remove it and allow one side of the connection to be closed. This is critical for some protocols that are being moved to use TLS. NSS was almost perfect here. The only problem was that it suppressed the second close_notify. I've added a test for that. Reviewers: ttaubert, ekr Reviewed By: ttaubert, ekr Subscribers: ekr Bug #: 1423043 Differential Revision: https://phabricator.services.mozilla.com/D797
3e452651e2829315f0961a08a0dad808171926c7: Bug 1455002 - Bump TLS 1.3 version to draft-28, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Tue, 17 Apr 2018 14:51:19 -0700 - rev 14331
Push 3066 by ekr@mozilla.com at Wed, 18 Apr 2018 16:03:20 +0000
Bug 1455002 - Bump TLS 1.3 version to draft-28, r=ekr Summary: I probably messed this one up. Reviewers: ekr Reviewed By: ekr Bug #: 1453586 Differential Revision: https://phabricator.services.mozilla.com/D919
5bbce52d2929a82d14a3ba44ed54ef064d92730d: Bug 1427675 - Short header for DTLS 1.3, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Fri, 16 Mar 2018 10:54:00 +0000 - rev 14294
Push 3030 by martin.thomson@gmail.com at Fri, 16 Mar 2018 11:40:55 +0000
Bug 1427675 - Short header for DTLS 1.3, r=ekr Summary: The code changes here are relatively straightforward, though there are a few changes of note: * To make read and write more consistent, I changed `seqNum` on ssl3CipherSpec `nextSeqNum`. The write side didn't change, but the read side previously saved the last sequence number in that slot. This makes the sequence number recovery simpler and makes the code easier to reason able as a whole. * SSL3Ciphertext now it holds the raw header and no longer has a type field. Passing the raw header through allows ssl3_HandleRecord and the functions that it calls to recover the sequence number. I considered doing the recovery in the gather functions, which used to recover the sequence number, but they don't have access to the cipher spec. * Record construction now works in order: the header is written out first, with the length filled in after encryption. This uses sslBuffer in a way more consistent with other functions. * The hack where a cText of NULL was passed to ssl3_HandleRecord in order to have it handle the outstanding handshake message from the receive buffer was removed. In addition to teaching TlsRecordFilter about the agent that it is operating with (in a separate CL), there are several changes to tests: * We previously relied on the epoch and sequence number being properly encoded for DTLS records, so the sequence number reconstruction (used when we decrypt and re-encrypt) was invalid. I restored the epoch to this field when doing DTLS. * TlsRecordHeader no longer stores the wire format of the version, it includes a variant and non-wire version. * TlsRecordHeader needs to know whether it is parsing DTLS 1.3, so TlsRecordFilter passes that info to it after asking the agent. * TlsRecordHeader writes out DTLS 1.3 records in the 7 octet form always. It can read the 2 octet header, using logic similar to that used by the main code, but it won't ever write that form. * TlsAgentTestBase::MakeRecord also writes the 7 octet header. * I parameterized the record drop tests so that I could test out of order delivery and various patterns with the short header. This revealed some issues, including one good one. I had a neat underflow bug that can happen near zero, which leads to ridiculously large sequence numbers being incorrectly assumed by a receiver. This includes fuzzing-specific changes to account for the fact that fuzzing operates at the record layer, which is inconvenient for this change. Ideally, we should change the fuzzing code so that only the core cipher parts are changed (that is, ssl3CipherSpec->cipher and ssl3CipherSpec->aead). That will have to wait for another day. Reviewers: ekr Reviewed By: ekr Bug #: 1427675 Differential Revision: https://phabricator.services.mozilla.com/D554
e9b2a26297daab9b4e237b1292d3de313102ff96: Bug 1443136 - Add support for signature scheme preferences in BoGo r=franziskus,ekr
Tim Taubert <ttaubert@mozilla.com> - Tue, 06 Mar 2018 10:14:59 +0100 - rev 14283
Push 3019 by ttaubert@mozilla.com at Tue, 06 Mar 2018 09:15:43 +0000
Bug 1443136 - Add support for signature scheme preferences in BoGo r=franziskus,ekr Reviewers: franziskus, ekr Reviewed By: franziskus Bug #: 1443136 Differential Revision: https://phabricator.services.mozilla.com/D676
54a2412cbcc3c1016fa3cd0cf1fbcb52cb116ebc: Bug 1427675 - Template for common TlsRecordFilter instantiation pattern, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Wed, 14 Feb 2018 14:01:46 +1100 - rev 14255
Push 2995 by martin.thomson@gmail.com at Thu, 15 Feb 2018 01:47:05 +0000
Bug 1427675 - Template for common TlsRecordFilter instantiation pattern, r=ekr
74e4cd34e49fa72806ed7405926591d90f4a2d2a: Bug 1427675 - Add TlsAgent argument to TlsRecordFilter, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Wed, 03 Jan 2018 15:36:18 +1100 - rev 14254
Push 2995 by martin.thomson@gmail.com at Thu, 15 Feb 2018 01:47:05 +0000
Bug 1427675 - Add TlsAgent argument to TlsRecordFilter, r=ekr This is a fairly disruptive change, but mostly just mechanical. There are a few extra changes: - I have renamed the TlsInspector* filters for consistency. This was purely mechanical. - I renamed the SetPacketFilter function to just SetFilter. Also mechanical. - TlsRecordFilter maintains a weak pointer reference to the TlsAgent now rather than using a bare pointer. This meant that I had to change TlsAgentTestBase to use shared_ptr rather than unique_ptr to support of use of filters with those tests. - I removed the helper function that enables decryption. Enabling decryption is now more explicit. - I ran a newer clang-format version and it fixed a few extra things, like the comments on the end of namespace {} blocks, some of which were wrong. - I discovered a bug in some of the drop tests: in the 0-RTT tests, the filters were being installed on the client and server right at the start, which meant that they were capturing the first handshake and not the second one. This was clearly against intent, but the tests were mostly right still, it was only the expected ACKs that were wrong. We were expecting just one record to be ACKed by a server (Finished), but the record with EndOfEarlyData should have been acknowledged as well. - In TlsSkipTest and Tls13SkipTest, I had to override SetUp() so that client_ and server_ are initialized prior to constructing filters. In doing so, I noticed that we weren't being consistent about overriding SetUp properly, so I fixed the small number of instances of that by adding an override label to each and marking the base method virtual. - The stateless HRR test for TLS 1.3 compat mode was replacing the server, but expecting to retain the same filters. That wasn't a problem in that case, but I didn't want to have any places where the filter was set on a different agent from the one that was passed to it.
d5cedac63e25e15b3c6e21674d791d9718fe012d: Bug 1427556 - API for setting max_early_data_size, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Tue, 23 Jan 2018 10:00:08 +1100 - rev 14239
Push 2981 by martin.thomson@gmail.com at Mon, 29 Jan 2018 00:02:34 +0000
Bug 1427556 - API for setting max_early_data_size, r=ekr Summary: We had an API for this in tests, but this formalizes it. Note that we can't use SSL_OptionSet here, but I decided to use the structures. Reviewers: ekr Subscribers: mcmanus Bug #: 1427556 Differential Revision: https://phabricator.services.mozilla.com/D344
fa1f3948cb000ea3dba1c12a00426eb8a94d46f9: Bug 1427556 - API for setting max_early_data_size, r?ekr
Martin Thomson <martin.thomson@gmail.com> - Tue, 02 Jan 2018 12:57:41 +1100 - rev 14217
Push 2961 by martin.thomson@gmail.com at Wed, 17 Jan 2018 07:23:37 +0000
Bug 1427556 - API for setting max_early_data_size, r?ekr
1dd546143b8f28c1090bf78c1d7ba941d2c81e60: Bug 1427921 - RSA-PSS codepoints for TLS 1.3 draft-23, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Fri, 05 Jan 2018 10:08:01 +1100 - rev 14207
Push 2952 by martin.thomson@gmail.com at Tue, 09 Jan 2018 00:04:59 +0000
Bug 1427921 - RSA-PSS codepoints for TLS 1.3 draft-23, r=ekr
5a07078fb33827a3dec05f64a12690a0be789fa3: Bug 1427921 - Update to TLS 1.3 draft-23, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Thu, 04 Jan 2018 11:35:03 +1100 - rev 14204
Push 2949 by martin.thomson@gmail.com at Thu, 04 Jan 2018 23:37:33 +0000
Bug 1427921 - Update to TLS 1.3 draft-23, r=ekr
a32eec0bdec8c4fc6e0bc1b65b73b9b1a498041d: Bug 1422688 - Fix for blocking mode reads of 0-RTT, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Wed, 29 Nov 2017 11:11:26 +1100 - rev 14185
Push 2931 by martin.thomson@gmail.com at Tue, 05 Dec 2017 00:30:55 +0000
Bug 1422688 - Fix for blocking mode reads of 0-RTT, r=ekr We talked about this in an earlier iteration of Bug 1386475, but we didn't like that the code checked whether there was early data twice. Turns out that it is necessary for blocking sockets. If we return PR_WOULD_BLOCK_ERROR on a blocking socket, the calling code rightfully objects. As it turns out, selfserv is an example of this. It was breaking with boringssl. I don't know why this wasn't an issue with other clients, but I suspect that it is because very few implementations are doing exactly the same thing with 0-RTT and timing is critical here.
179bb12e1dc54eebd8e0470a420354ea121ee91f: Bug 1315865 - Automatic KeyUpdate to avoid cipher exhaustion, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Fri, 01 Sep 2017 16:46:28 +1000 - rev 14179
Push 2926 by martin.thomson@gmail.com at Mon, 04 Dec 2017 08:54:24 +0000
Bug 1315865 - Automatic KeyUpdate to avoid cipher exhaustion, r=ekr
c7806ef48b38f0349fcddffa7a1f8ae2dff6f1e9: Bug 1315865 - Basic KeyUpdate handling, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Tue, 14 Feb 2017 20:35:14 +1100 - rev 14178
Push 2926 by martin.thomson@gmail.com at Mon, 04 Dec 2017 08:54:24 +0000
Bug 1315865 - Basic KeyUpdate handling, r=ekr Summary: KeyUpdate for TLS (not DTLS). Experimental API for triggering one. Reviewers: ekr
401de51885384e2d612ca7cc32ffc0936bc5969b: Bug 1421572 - Correct early exporter secret derivation, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Wed, 29 Nov 2017 06:23:19 -0800 - rev 14175
Push 2923 by ekr@mozilla.com at Wed, 29 Nov 2017 14:47:26 +0000
Bug 1421572 - Correct early exporter secret derivation, r=ekr Summary: This was pretty obviously wrong before, which was made obvious when I moved a few things around. Reviewers: ekr, Lekensteyn Reviewed By: Lekensteyn Subscribers: mt, Lekensteyn Bug #: 1421572 Differential Revision: https://phabricator.services.mozilla.com/D297
2b6dc5a87babdfbc15fefe0ef561bf6cc9b83562: Bug 1429776 - Various coverity issues on TLS 1.3 branch, r=ekr
Martin Thomson <martin.thomson@gmail.com> - Mon, 27 Nov 2017 10:08:54 +1100 - rev 14168
Push 2917 by martin.thomson@gmail.com at Mon, 27 Nov 2017 00:04:16 +0000
Bug 1429776 - Various coverity issues on TLS 1.3 branch, r=ekr
90fa0804c6238a22e9f6804c260fe51364f1c525: Bug 1385203 - Ensure wrBuf is empty when not in use, r=ekr NSS_TLS13_DRAFT19_BRANCH
Martin Thomson <martin.thomson@gmail.com> - Fri, 24 Nov 2017 10:48:17 +1100 - rev 14160
Push 2911 by martin.thomson@gmail.com at Fri, 24 Nov 2017 05:31:28 +0000
Bug 1385203 - Ensure wrBuf is empty when not in use, r=ekr
5bd4fdfaaac3d10b7f839835ade5a644d4782aa1: Bug 1418862 - Make HelloRetryRequest look like ServerHello, r=ekr NSS_TLS13_DRAFT19_BRANCH
Martin Thomson <martin.thomson@gmail.com> - Wed, 22 Nov 2017 20:33:29 +1100 - rev 14158
Push 2911 by martin.thomson@gmail.com at Fri, 24 Nov 2017 05:31:28 +0000
Bug 1418862 - Make HelloRetryRequest look like ServerHello, r=ekr Update TLS 1.3 implementation for draft-22. This makes the changes from Bug 1411475 the default mode of operation. A new option, SSL_ENABLE_TLS13_COMPAT_MODE, is added to control whether a client attempts to force the server into compatibility mode. When enabled, clients will send a fake session_id in the ClientHello and send a ChangeCipherSpec message before sending any encrypted records. This patch also includes changes to make a HelloRetryRequest look like a ServerHello. This includes the version number change to draft-22.
6d6672247fc449fb3c8831857ea72c14537f63bf: Bug 1418943 - Properly handle absent cookie on second ClientHello, r=ekr NSS_TLS13_DRAFT19_BRANCH
Martin Thomson <martin.thomson@gmail.com> - Mon, 20 Nov 2017 21:20:00 +1100 - rev 14137
Push 2894 by martin.thomson@gmail.com at Tue, 21 Nov 2017 00:56:08 +0000
Bug 1418943 - Properly handle absent cookie on second ClientHello, r=ekr
108071abbd93058da6201f47ff5e022e25e01e28: Bug 1418948 - Configure anti-replay for selfserv, r=ekr NSS_TLS13_DRAFT19_BRANCH
Martin Thomson <martin.thomson@gmail.com> - Mon, 20 Nov 2017 21:27:05 +1100 - rev 14136
Push 2894 by martin.thomson@gmail.com at Tue, 21 Nov 2017 00:56:08 +0000
Bug 1418948 - Configure anti-replay for selfserv, r=ekr
4c32e391f1acaf9c7345fa6c2d897f9024af41d4: Bug 1413787 - Remove lazy initialization, r=ekr NSS_TLS13_DRAFT19_BRANCH
Martin Thomson <martin.thomson@gmail.com> - Thu, 02 Nov 2017 14:29:49 +1100 - rev 14135
Push 2894 by martin.thomson@gmail.com at Tue, 21 Nov 2017 00:56:08 +0000
Bug 1413787 - Remove lazy initialization, r=ekr The only subtle change here is that I needed to move the call to ssl_FilterSupportedGroups() from ssl3_InitState() to ssl3_config_match_init(). It is the only thing in ssl3_InitState that depends on configuration. The rest is pretty straightforward. The other change of note is that a newly imported socket will have ss->ssl3.hs.ws set to wait_client_hello (server) or idle_handshake (client). Previously, the value was initialized to idle_handshake only.