This makes it possible to fetch the min and max versions configured
directly on SSL objects (as opposed to SSL_CTX ones).
This is useful when configuring supported TLS versions on per-connection
basis.
Change-Id: Ibccc92c5f7668e9a7be5a01d6f84089608382407
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38104
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Chromium's renegotiation handling currently relies on reads being the only
thing that can discover a renegotiation. However, for a number of reasons, we
would like to eagerly drive the read loop after a handshake:
- 0-RTT + HTTP/1.1 will otherwise not pick up ServerHellos until after we send
a request. In particular, if we preconnect a 0-RTT socket sufficiently in
advance, such that the ServerHello comes in by the time we use it, we should
send 1-RTT data rather than 0-RTT.
- In TLS 1.2 False Start, if HTTP/1.1 or preconnect, we will not pick up the
server Finished and NewSessionTicket until later. This way we pick it up
sooner.
- If the server does not implement
https://boringssl-review.googlesource.com/c/boringssl/+/34948, this plugs the
theoretical deadlock on the client end. The False Start and 0-RTT scenarios
above also have theoretical deadlocks and cannot be mitigated on the server.
- TLS 1.3 client certificate alerts interact badly with TCP reset. Eagerly
reading from the socket makes it behave slightly better, though it's still
not reliable unless the server defers closing the socket.
So we can SSL_peek without triggering a renegotiation, add an
ssl_renegotiate_explicit mode to defer processing the renegotiation.
Bug: chromium:950706, chromium:958638
Change-Id: I78242d93d651b7a32a5c4c24ea9032ef63a027cf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37944
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This is test-only code and a no-op, but it's prudent to avoid making
assumptions about the initial state of *out. Hopefully someday later we can
assume std::optional or pull in absl::optional.
Change-Id: I85af87bb2cc3cda3d40801c91e6abe4f5a7d89f8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37184
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
This adapts our existing API for QUIC, although I'm not entirely
convinced the shape of it fits as it does with TCP. Things that needed
to be changed:
- There is a slight ordering issue on the server with HRR and releasing
the 0-RTT keys to QUIC.
- Remove EndOfEarlyData.
- At the early return point for the server, QUIC needs to have installed
the client traffic secrets earlier.
- The maximum early data value is a constant in QUIC.
- QUIC never installs early secrets at the TLS level. (In particular,
this avoids nuisances with do_send_second_client_hello's null cipher
not updating the encryption level.)
- The read/write secrets for 0-RTT keys were mixed up.
As the QUIC tests are getting a bit unwieldy, I tidied them up a bit.
This CL does *not* handle the QUIC transport parameters or HTTP/3
server SETTINGS frame interactions with 0-RTT. That will be done in a
separate CL.
I suspect if we ever implement DTLS 1.3, we'll find ourselves wanting to
align some of the QUIC bits here with DTLS and perhaps refine the
handshake/transport abstractions a bit.
Bug: 221
Change-Id: I61f701d7241dbc99e5dbf57ae6c283e10b85b049
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37145
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
QUIC is going to make this flow a bit more complicated, so let's simplify it a
bit. The client flight states already know to skip themselves in 1-RTT
resumption, so just run through the same states. Also remove a redundant
early_data_offered check.
(I think we originally skipped the states because we do half-RTT tickets and
the transcript bits were precomputed.)
Bug: 221
Change-Id: I3a62c864458012e74b46f7ef212abc125760c12d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37144
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Unexpected SSL_ERROR_* values usually mean the caller didn't handle an
error case for some opt-in feature, but it still would be handy to
stringify them when logging.
Change-Id: If1c44a180b5c124a51ba61410ba02bd637f3429a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37188
Reviewed-by: Adam Langley <agl@google.com>
There's no sense in having two of these (with similar but slightly
different numbers, no less!). Fold them together and remove the
redundant SSL_want constants. Almost everything uses SSL_get_error.
Update-Note: Most of the SSL_want constants have been removed, except
SSL_NOTHING, SSL_READING, and SSL_WRITING which are used by external
code.
Change-Id: I75727f7cf6333694767ce8129ee6815fd464c163
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37187
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This undoes a lot of the MakeConstSpans and MakeSpans that were just
added, though it does require a bit of helper machinery. This should
make us much more consistent about which buffer is sized with which size
(even though they are secretly all the same size).
Change-Id: I772ffd2e69141ff20511bcd3add865afa82cf3a0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37127
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
The callers become filled with MakeConstSpans, but the various TLS 1.3
secrets will get fixed in a subsequent CL. We do still need a better
pattern for the EVP_MAX_MD_SIZE buffers.
Change-Id: Ide9c173bf0760ecdb8cc45e63969457c20310de2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37125
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
We perform all our negotiation based on the first ClientHello (for
consistency with what |select_certificate_cb| observed), which is in the
transcript, so we can ignore most of the second one.
However, we ought to check the second PSK binder. That covers the client
key share, which we do consume. In particular, we'll want to check if it
we ever send half-RTT data on these connections (we do not currently do
this). It is also a tricky computation, so we enforce the peer handled
it correctly.
Tested that both Chrome and Firefox continue to interop with this check,
when configuring uncommon curve preferences that trigger HRR. (Normally
neither browser sees HRRs against BoringSSL servers.)
Update-Note: This does enforce some client behavior that we hadn't been
enforcing previously. However, it only figures into TLS 1.3 (not many
implementations yet), and only clients which hit HelloRetryRequest
(rare), so this should be low risk.
Change-Id: I42126585ec0685d009542094192e674cbd22520d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37124
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Due to padding and slightly silly field ordering, I think this actually ends up
a no-op memory-wise, but may amount to win with cleverer reordering or as
fields change.
Change-Id: I14e38d747a90112cf06c741aec148b77cc5902fb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36791
Reviewed-by: Adam Langley <agl@google.com>
EVP_MAX_MD_SIZE is sized for the largest hash function supported, SHA-512, but
TLS never uses anything larger than SHA-384, which is plenty large enough. This
shaves 16 * 3 = 48 bytes of per-connection overhead plus an addition 16 * 7 =
112 bytes of per-handshake overhead. (Per-handshake structures are discarded
when the handshake completes, so this matters less.)
Change-Id: Iabe15d25fc9182ffcdde876facbe4d80c8143197
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36790
Reviewed-by: Adam Langley <agl@google.com>
This avoids early callback users writing their own SNI parser and gives us a
place to surface the server name from ESNI in the future.
Update-Note: This isn't a breaking change, but users of
SSL_CTX_set_select_certificate_cb can likely drop a bit of code after this CL.
Bug: 275
Change-Id: I9685ae5cca8e0483de76229d12dac45ff8e9ec32
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36784
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Keep the setup_ctx logic, which, among other things, checks if the
signature algorithm is valid. This cuts down on some unnecessary
fuzzer-mode suppressions.
Change-Id: I644f75630791c9741a1b372e5f83ae7ff9f01c2f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36766
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The names of those tests don't actually matter to the shim because we
don't pass them in anywhere. Note hasComponent() is also used by the
signature algorithm tests, so that also needs to use underscores as a
result.
Change-Id: I393df4c6ffebcc66a55f256df5a641ad87e66441
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36765
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
When testing HRSS-SXY and SIKE, we also want a control group. However,
how are clients to indicate that they're part of the 1/3 of the
experiment population that's not advertising CECPQ? And how are servers
to indicate that they would have negotiated CECPQ2 / 2b if only the
client had asked?
This change adds a temporary signaling extension to solve these issues.
Change-Id: Ic087a09149ef10141568b734396981ae97950a9b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36725
Reviewed-by: David Benjamin <davidben@google.com>
* CECPQ2b will use SIKE/p434 instead of SIKE/p503
* KEM uses SHA256 instead of HMAC-256
* implements new starting curve: y^2=x^3 + 6x^2 + x
* adds optimized implementation for aarch64
* adds optimized implementation for AMD64
which do not support MULX/ADOX/ADCX
* syncs the SIKE test code with the NIST Round 2
specification.
* removes references to field size from variables
names, tests and defines.
Change-Id: I5359c6c62ad342354c6d337f7ee525158586ec93
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36704
Reviewed-by: Adam Langley <agl@google.com>
Go 1.13 will add Ed25519 support to the standard library. Switch the
order of our vendored Ed25519 bits so we do not get mixed up by this.
When Go 1.13 is released, we can then unwind all this in favor of the
standard library version.
Update-Note: See b/135634259
Change-Id: Iddc0ea58db5b2181cecacfcdd3cc058159271787
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36504
Reviewed-by: Adam Langley <agl@google.com>
Implements support for hybrid key exchange based on SIKEp503, a post
quantum, isogeny based KEM. This is a hybrid construction mixed with
X25519 key agreement. Code point is 0xFE32. Cloudflare's SIDH
implementation is used for testing. Key exchange can be used with TLS1.3
only.
Change-Id: I3a5f38d6f7d016274e5bcfb629249664e1d983eb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35264
Reviewed-by: Adam Langley <alangley@gmail.com>
This stores early data tickets regardless of whether early data is enabled in
the initial handshake, and provides an API to query whether early data would be
performed to allow for comparison between early data enabled and disabled
resumptions.
Change-Id: Id3ef62e36b5be48f6a39fcd7c67d332b7d495141
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35964
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Out-of-band errors, the UNIX gift that keeps on giving...
We almost always ignore the result of ssl_send_alert, treating it as
largely a "best effort". Sending an alert is the only place in the TLS
stack where we call back to user code with state in the error queue. (If
we've put something in the error queue, it means we are in the process
of failing an operation.) That user code may mess up state by, say,
calling ERR_clear_error.
In particular, if the underlying BIO is implemented with SSL_write, as
in TLS tunneled over an HTTPS proxy, the call to SSL_write will
ERR_clear_error and clobber our error state. (SSL_write must
ERR_clear_error so that SSL_get_error works. This is one of the few
places we are sensitive to clearing the error queue.)
Split ssl_send_alert into a low-level ssl_send_alert_impl (for the two
places we do honor the return value) an ssl_send_alert wrapper which
saves and restores the error queue across the call, more explicitly
ignoring the return value.
This is intended as a minimal fix to https://crbug.com/959305, in case
we need to merge it to a release branch. As a follow-up, I plan to
rework the handshake state machine so it never calls ssl_send_alert,
instead returning the alert as part of the error. This is the last bit
of I/O still in the handshake. (We have the out_alert calling
convention, but I'm thinking it's worth a small sum type where the error
branch has an alert so we don't forget to supply one everywhere.
Update-Note: This changes our behavior when sending an alert fails.
Bug: chromium:959305
Change-Id: I24033205ad0f7ebd1797964489e4d46414a3e7ec
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35904
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
At one point we had -expect-foo and TestConfig::expect_foo for boolean
flags and -expect-bar and TestConfig::expected_bar for flags that take a
value. This seems to have been confusing and got applied inconsistently.
Match the variable names to the flag names and consistently use
"expect".
Change-Id: Ia346b91ad37b1177918c50392f9f80a384926e27
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35889
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
At one point, the ticket early data extension was under a separate
ticket_early_data_info code point. That was later consolidated. Rename
the tests which still reference the "info" name.
Change-Id: Ie3c9257d32a95569906ad24e7b419434b9faae1c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35887
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
For now just hard-code a tolerance of 1 minute.
SSL_get_early_data_reason and SSL_get_ticket_age_skew will allow us to
tune this.
Bug: 113
Change-Id: I85a530494d5405a3e11198d49bfa9cfd355f4f35
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35886
Reviewed-by: Adam Langley <agl@google.com>
This is to help servers diagnose 0-RTT rejects. (QUIC has a similar
feature, and this will help determine if we need to adjust the ticket
age skew.)
Bug: 113
Change-Id: Icc7e5df326b5fa82e744605021b1205298efba6a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35885
Reviewed-by: Adam Langley <agl@google.com>
We have a generic mechanism for this now. While
-expect-early-data-accept only makes sense for the resumption leg, we
have some tests which send fake early data to a server on the first leg.
This is in preparation for adding an SSL_get_early_data_reason, where
asserting in those cases would be useful.
(Also -expect-early-data-reject works just fine for initial connections.
It might make sense to make that implicit from the lack of
-expect-early-data-accept?)
Change-Id: I41ad0c5bb538409628885183f88f7fbd619bc6aa
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35884
Reviewed-by: Adam Langley <agl@google.com>
Alessandro Ghedini