| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D106617
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A few minor ECH -09 fixes for interop testing and fuzzing:
- selfserv now takes a PKCS8 keypair for ECH. This is more maintainable and significantly
less terrible than parsing the ECHConfigs and cobbling one together within selfserv
(e.g. we can support other KEMs without modifying the server).
- Get rid of the newline character in tstclnt retry_configs output.
- Fuzzer fixes in tls13_HandleHrrCookie:
- We shouldn't use internal_error when PK11_HPKE_ImportContext fails. Cookies are
unprotected in fuzzer mode, so this can be expected to occur.
- Only restore the application token when recovering hash state, otherwise the
copy could happen twice, leaking one of the allocations.
Differential Revision: https://phabricator.services.mozilla.com/D103247
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D98634
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for Encrypted Client Hello (draft-ietf-tls-esni-08), replacing the existing ESNI (draft -02) support.
There are five new experimental functions to enable this:
- SSL_EncodeEchConfig: Generates an encoded (not BASE64) ECHConfig given a set of parameters.
- SSL_SetClientEchConfigs: Configures the provided ECHConfig to the given socket. When configured, an ephemeral HPKE keypair will be generated for the CH encryption.
- SSL_SetServerEchConfigs: Configures the provided ECHConfig and keypair to the socket. The keypair specified will be used for HPKE operations in order to decrypt encrypted Client Hellos as they are received.
- SSL_GetEchRetryConfigs: If ECH is rejected by the server and compatible retry_configs are provided, this API allows the application to extract those retry_configs for use in a new connection.
- SSL_EnableTls13GreaseEch: When enabled, non-ECH Client Hellos will have a "GREASE ECH" (i.e. fake) extension appended. GREASE ECH is disabled by default, as there are known compatibility issues that will be addressed in a subsequent draft.
The following ESNI experimental functions are deprecated by this update:
- SSL_EncodeESNIKeys
- SSL_EnableESNI
- SSL_SetESNIKeyPair
In order to be used, NSS must be compiled with `NSS_ENABLE_DRAFT_HPKE` defined.
Differential Revision: https://phabricator.services.mozilla.com/D86106
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for TLS 1.3 external PSKs in tstclnt and selfserv with the `-z` option.
Command examples:
- `selfserv -D -p 4443 -d . -n localhost.localdomain -w nss -V tls1.3: -H 1 -z 0xAAAAAAAABBBBBBBBCCCCCCCCDDDDDDDD[:label] -m`
- `tstclnt -h 127.0.0.1 -p 4443 -z 0xAAAAAAAABBBBBBBBCCCCCCCCDDDDDDDD[:label] -d . -w nss`
For OpenSSL interop:
- `openssl s_server -nocert -port 4433 -psk AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDD [-psk_identity label]`
Note: If the optional label is omitted, both NSS tools and OpenSSL default to "Client_identity".
Differential Revision: https://phabricator.services.mozilla.com/D75836
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: rrelyea, mt
Reviewed By: mt
Subscribers: HubertKario
Bug #: 1494063
Differential Revision: https://phabricator.services.mozilla.com/D29166
|
|
|
|
|
|
| |
cmds. r=kjacobs
Differential Revision: https://phabricator.services.mozilla.com/D42165
|
|
|
|
| |
r=marcusburghardt,jcj
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D25654
|
|
|
|
|
|
|
|
|
|
|
|
| |
auth, r=mt
Reviewers: mt
Reviewed By: mt
Bug #: 1532312
Differential Revision: https://phabricator.services.mozilla.com/D21936
|
|
|
|
|
| |
Phabricator: https://phabricator.services.mozilla.com/D6042
|
| |
|
|
|
|
| |
r=franziskus
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: franziskus
Reviewed By: franziskus
Bug #: 1464778
Differential Revision: https://phabricator.services.mozilla.com/D1433
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
Reviewers: mt
Differential Revision: https://phabricator.services.mozilla.com/D314
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Reverting name change of experimental API (transplanted changed from 3.34 branch).
blocks D222
Reviewers: mt
Reviewed By: mt
Bug #: 1415795
Differential Revision: https://phabricator.services.mozilla.com/D261
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes the TLS 1.3 handshake look like TLS 1.2.
The trickiest part here is in 0-RTT. I've chosen to remember that the
alternative handshake was used and send a ChangeCipherSpec if the previous
session used the alternative AND if the client enables the alternative.
This assumes that a server will commit to supporting - and selecting - this
alternative handshake type for as long as it supports 0-RTT from sessions that
have the alternative handshake type. That is, if you negotiate the alternative
handshake and the server supports 0-RTT, then it will not just support TLS 1.3
for the duration of the ticket, but also the alternative handshake type. A
client can disable the alternative handshake because the version in the
ClientHello indicates whether the client intended to send a CCS, but the server
cannot refuse to pick it if the client offers.
Of course, if we agree that the final TLS 1.3 is in this form, we don't have a
problem, it's only an issue because we need to switch-hit.
I chose to remove the Facebook alternative content type hack as all signs
indicate that it doesn't help.
|
|
|
|
|
|
|
| |
Reviewers: mt
Differential Revision: https://nss-review.dev.mozaws.net/D389
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Reviewers: mt
Differential Revision: https://nss-review.dev.mozaws.net/D110
|
|
|
|
| |
Differential Revision: https://nss-review.dev.mozaws.net/D60
|
|
|
|
| |
Differential Revision: https://nss-review.dev.mozaws.net/D61
|
|
|
|
|
| |
Differential Revision: https://nss-review.dev.mozaws.net/D57
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
resume. r=mt
Summary:
It is difficult to resumption and 0-RTT with tstclnt as it currently is.
This CL fixes that. The changes involve two new flags:
A -- Read a fixed request from a file and use that instead of
reading from stdin
L -- Disconnect and reconnect L - 1 times.
Reviewers: mt
Differential Revision: https://nss-review.dev.mozaws.net/D39
Fix npds
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
resume. r=mt
Summary:
It is difficult to resumption and 0-RTT with tstclnt as it currently is.
This CL fixes that. The changes involve two new flags:
A -- Read a fixed request from a file and use that instead of
reading from stdin
L -- Disconnect and reconnect L - 1 times.
Reviewers: mt
Differential Revision: https://nss-review.dev.mozaws.net/D39
Fix npds
|
|
|
|
| |
(requireDHNamedGroups). r=franziskus
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
v3 with improvements by Martin Thomson, r=rrelyea
|
| |
|
| |
|