Now skipping over HPKE decryption in |ssl_client_hello_decrypt| when
fuzzer mode is enabled. To improve code coverage, this fuzzer-only logic
also also has the ability to simulate a failed decryption.
As a result of mostly skipping the decryption, we now have to exclude
"*-ECH-Server-Decline*" tests from running in fuzzer mode. These tests
rely on the now-broken assumption that decryption will fail when the
client used an ECHConfig unknown to the server.
Bug: 275
Change-Id: I759a79c8596897cdd3d3a37e05f2973d47346ef9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47624
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
We'll return 0 and get confused. (Negotiating early data and not using
it is plausible if, say, the client preconnects but gets a ServerHello
before any request binds the socket.)
Change-Id: I94d458e18c58223f73c9340cac06e5ec5f8c84a0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47684
Reviewed-by: Adam Langley <agl@google.com>
If we ever forget to fill it in the randoms, they'll end up all zero.
Particularly at the ClientHello, that logic is getting increasingly far
away from ClientHello serialization, so add a test to make sure we
notice.
(This will flakily fail with probability 2^-256, which is reasonably
unlikely.)
Change-Id: I81f32fd96dbccf377cb92198a222b557ab66976b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47665
Reviewed-by: Adam Langley <agl@google.com>
This is part of a very deep dependency chain. I'm sniffing at making all
the add_clienthello callbacks const. Between HelloVerifyRequest,
HelloRetryRequest, and soon ECH, we're creating lots of ClientHellos per
connection. That's probably easiest to manage if constructing a
ClientHello had no side effects.
Update-Note: The change to the return type isn't quite compatible, but I
only found one caller of this function, which has since been fixed. (If
we need to return a non-const value for compatibility, we can do that
and document that the caller should not mutate the output.)
Change-Id: I21f18f7438920a5b03d874fa548f054af3a42c4a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47664
Reviewed-by: Adam Langley <agl@google.com>
We misread (or maybe it changed?) the draft padding scheme. The current
text does not round the whole payload to a multiple of 32, just the
server name as a fallback. Switch the GREASE size selection to match.
Although, we may want to change the draft here. See also
https://github.com/tlswg/draft-ietf-tls-esni/issues/433
While I'm here, update some references from draft-09 to draft-10. Also
make the comment less verbose.
Bug: 275
Change-Id: I3c9f34159890bc3b7d71f6877f34b895bc7f9b17
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47644
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
We didn't end up deploying this. We also never implemented the final
RFC, so what we do have isn't useful for someone who wishes to deploy
it anyway.
Update-Note: Token binding APIs are removed.
Change-Id: Iecea7c3dcf9d3e2644a3b7afaf61511310b45d5f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47584
Reviewed-by: Adam Langley <agl@google.com>
We can unexport the X509_REQ_INFO type entirely. (NB: OpenSSL hasn't
done this, but has unexported so much of X509_REQ_INFO that it is
impossible to use what remains anyway.)
Update-Note: Callers that reach into X509_REQ and X509_REQ_INFO must use
accessors instead.
Change-Id: I1eea5207b9195c8051d5e467acd63ad5f0caf89d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47564
Reviewed-by: Adam Langley <agl@google.com>
ServerHello/EncryptedExtensions/Finished is logically one atomic flight
that exits the early data state, we have process each message
sequentially. Until we've processed Finished, we are still in the early
data state and must support writing data. Individual messages *are*
processed atomically, so the interesting points are before ServerHello
(already tested), after ServerHello, and after EncryptedExtensions.
The TLS 1.3 handshake internally clears ssl->session when processing
ServerHello, so getting the early data information from ssl->session
does not work. Instead, use hs->early_session, which is what other
codepaths use.
I've tested this with runner rather than ssl_test, so we can test both
post-SH and post-EE states. ssl_test would be more self-contained, since
we can directly control the API calls, but it cannot test the post-EE
state. To reduce record overhead, our production implementation packs EE
and Finished into the same record, which means the handshake will
process the two atomically. Instead, I've tested this in runner, with a
flag to partially drive the handshake before reading early data.
I've also tweaked the logic to hopefully be a little clearer.
Bug: chromium:1208784
Change-Id: Ia4901042419c5324054f97743bd1aac59ebf8f24
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47485
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We usually call the parameter 'digest', but people sometimes think they
can skip the hashing for short inputs are short. I also suspect the term
'digest' is less common. Add warnings about this.
There were also some cases where we called it 'in' and even 'msg'. This
CL fixes those to say 'digest'. Finally, RSA_{sign,verify}_raw are
documented to be building blocks of signature schemes, rather than
signature schemes themselves.
It's unfortunate that EVP_PKEY_sign means "sign a digest", while
EVP_DigestSign means "sign, likely internally digesting it as the first
step", but we're a bit stuck there.
Change-Id: I4c38afff9b6196e2789cf27653fe5e5e8c68c1bf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47504
Reviewed-by: Adam Langley <agl@google.com>
https://boringssl-review.googlesource.com/c/boringssl/+/42504 aligned
RSA private key checks, but I missed the public key ones. We have two
different sets of RSA public key checks right now. One in the parser
just checks for e = 1 and even e. The other, when using the key, checks
for overly large e and n.
Align the two. Now parsing RSA public keys calls RSA_check_key and the
extra checks on e are added to RSA_check_key. Note RSA private key
parsing already called RSA_check_key. The consequences are:
First, RSA public keys with large n, large e, or n < e will be rejected
at parse time. Previously, they would be parsed but all operations on
them would fail. This aligns with our existing behavior for parsing
private keys.
Second, operations on RSA public keys with even e will fail. They
already failed to parse, but it was possible to manually construct such
a key. Previously, operations wouldn't explicitly fail, but they
wouldn't do anything useful because even exponents are not invertible.
(Encrypting would produce something undecryptable and the private key
would have a hard time reliably producing signatures we'd accept.) There
is no change to RSA private keys with even e. Those would already fail
the (e, d) consistency check and the fault check.
Third, operations on RSA public keys with e = 1 will fail. They already
failed to parse, but it was possible to manually construct such a key
and "verify" signatures or "encrypt" messages. However, with e = 1,
those operations are no-ops.
Finally, RSA private keys with e = d = 1 will be rejected at parse and
use. This is the only case that affects private keys because e = d = 1
are inverses, just pointless. Uses paired with RSA public key parsing
(e.g. our TLS library checks consistency with a certificate public key)
are not affected. Those already rejected such keys because we rejected
them in the public key parser. This CL aligns the private half.
This doesn't close https://crbug.com/boringssl/316, but we won't be able
to resolve that without a consistent story for what keys are valid.
Update-Note: See above.
Bug: 316
Change-Id: Ic27df18c4f48e5e3e57a17d6fe39399e2f8d5c68
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47524
Reviewed-by: Adam Langley <agl@google.com>
This aligns with OpenSSL. In particular, we clear not_resumable as soon
as the SSL_SESSION is complete, but it may not have an ID or ticket.
(Due to APIs like SSL_get_session, SSL_SESSION needs to act both as a
resumption handle and a bundle of connection properties.)
Along the way, use the modified function in a few internal checks which,
with the ssl_update_cache change, removes the last dependency within the
library on the placeholder SHA256 IDs.
Change-Id: Ic225109ff31ec63ec08625e9f61a20cf0d9dd648
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47447
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We've inherited some behavior from OpenSSL where, in ticket-based client
sessions, we fill in a placeholder session ID of SHA256(ticket). This
was done to avoid confusing other code in OpenSSL (and possibly
callers?) that assumed session_id_length != 0 determined validity.
Separately, TLS 1.2 session tickets are syntactically weird. The client
generates a fake signaling session ID, which the server echoes on
resumption.
These combined meant we used the placeholder SHA256 value as this
signaling ID. Since we already have code to generate random session IDs
for TLS 1.3, use that instead to minimize unnecessary implementation
quirks visible on the wire. This removes one of the places we still rely
on the placeholders within the library.
Change-Id: I0de2781da72e2bbc030505611589c853f105ce9d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47446
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
We do not offer sessions on renegotiation. Rather than applying this at
both the ClientHello and ServerHello, just drop ssl->session, which
takes care of both cases.
Change-Id: I5ebaedc8d9cc0fca61242ed9b85fa3449636dfec
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47445
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
It's kind of weird that we assign a session ID, based on whether we
detect the handshake wants stateful resumption, and then erase it
afterwards.
Also remove the is_server parameter, which we can get from hs.
Change-Id: I94ac817c63abb08a457e0e0c29f5c2d2b60aa498
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47444
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This was fixed in review, but we forgot to update the comment.
Change-Id: If1fdd9211ff085edeb50457edf0caba5e31b6d16
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47448
Reviewed-by: Dan McArdle <dmcardle@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
It's sometimes hpke and sometimes ctx. Our other EVP_FOO_CTX types are
usually called ctx, so use ctx.
Bug: 410
Change-Id: Ib1c6d8018ffd8fd180b89f5be58283f3f098e44b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47404
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This introduces an EVP_HPKE_KEM, to capture the KEM choice, and
EVP_HPKE_KEY, to capture the key import (and thus avoids asking
receivers to pass in the full keypair). It is a bit more wordy now, but
we'll be in a better place when some non-TLS user inevitably asks for a
P-256 version.
Bug: 410
Change-Id: Icb9cc8b028e6d1f86e6d8adb31ebf1f975181675
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47329
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
NIST breaks these URLs so often it's unclear if it's worth including
them. If they do it again it might be a signal to remove them all.
However, until then, this change updates many of them. Some were deleted
because the format of the anchors has been switched and all the section
numbers remove, and I don't think it's worth trying to unpick all that.
Change-Id: I31457c225e68ee44d383a5a148fdcc80a3430864
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47464
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Callers using private key callbacks may retain non-trivial state with a
private key. In many cases, the private key is no longer necessary
immediately after the first round-trip (e.g. non-HRR TLS 1.3
connections). Add a function that callers can query to drop the state a
hair earlier.
This is tested in two ways. First, the asserts in front of using the
key, combined with existing tests, ensure we don't start reporting it
too early. Second, I've added tests in ssl_test.cc to assert we report
it as early as we expect to.
In doing so, the number of parameters on ConnectClientAndServer()
started getting tedious, so I've split that into a
CreateClientAndServer() and CompleteHandshakes(). Callers that need to
configure weird things or drive the handshake manually can call
CreateClientAndServer() (which takes care of the BIO pair business) and
continue from there.
Bug: b/183734559
Change-Id: I05e1edb6d269c8468ba7cde7dc90e0856694a0ca
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47344
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
I meant to grab more interesting types this round, but I missed a few
spots. We should be able to get these out of the way though.
Update-Note: Direct access of these structs should be replaced by
accessors.
Change-Id: I43cb8f949d53754cfebef2f84be66e89d2b96f96
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47384
Reviewed-by: Adam Langley <agl@google.com>
In cases where the RPC from acvptool to modulewrapper is expensive,
these iterated tests take excessive amounts of time. By moving the
inner loop into the module wrapper the number of round-trips is reduced
by 1000×.
Change-Id: Ic047db071239492e416a08cab60d6a7e2905e8dc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47364
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This is a little tedious but aligns with some of our other
variable-length parameters. This is in preparation for making the HPKE
APIs KEM-agnostic, so we don't need to make so many variations on the
HPKE functions for each KEM. (Especially if we ever need to implement
SetupPSK*, SetupAuth*, or SetupAuthPSK*.)
Bug: 410
Change-Id: I0625580b15358ab1f02b7835122256e8f058a779
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47328
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This replaces the ID-based API with one that is more static linker
friendly. For ECH, it doesn't make a difference because we currently
pull in all the options we've implemented. But this means other HPKE
uses need not pull in everything ECH needs and vice versa.
Along the way, fix an inconsistency: we prefixed all the AEAD constants
with "AEAD", but not the others. Since the rest of the name already
determines everything, go with the shorter version.
Bug: 410
Change-Id: I56e46c13b43c97e15eeb45204cde7019dd21e250
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47327
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Although we only support X25519 right now, we may need to support other
KEMs in the future. In the general case, a public/private keypair is
less meaningful. (If something like NTRU-HRSS even goes here, I guess
it'd be the entropy passed to HRSS_encap.)
Instead of taking an entire keypair, just take the private key. Perhaps
we call it the "seed"?
Bug: 410
Change-Id: Ifd6b6ea8ea36e6eca60d303706d6d2620f8c42d4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47326
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
(Imported from upstream's 65b88a75921533ada8b465bc8d5c0817ad927947 and
7c65179ad95d0f6f598ee82e763fce2567fe5802.)
Change-Id: Id6a9604231d3cacc5e20af07e40d09e20dc9d3c0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47332
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We can always add it back later, but nothing's using it right now.
Looking at all references to draft-irtf-cfrg-hpke in the IETF tracker,
there are zero uses of any of the modes beyond SetupBase.
Bug: 410
Change-Id: I23deb27554d36152776417d86e7759cb2c22e4eb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47325
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We can add them if we need them, but we're only using HKDF-SHA256 in
ECH. Keep the set small to encourage a common set of parameters.
Bug: 410
Change-Id: I5b9ddf3daa1d0c7f35df473470998369e9882553
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47324
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
PKCS#7 stores certificates and CRLs in (implicitly-tagged) SET OF
types. This means they're unordered and, in DER, must be sorted.
We currently sort neither. OpenSSL upstream sorts CRLs but doesn't sort
certificates. https://github.com/openssl/openssl/pull/13143 reports that
Microsoft has a stricter parser that checks this. This CL fixes both
fields in our serializer.
This does not change the parsing code, which still preserves whatever
order we happened to find, but I've updated the documentation to clarify
that callers should not rely on the ordering.
Based on [0] and the odd order in kPKCS7NSS, I believe this aligns with
NSS's behavior.
Update-Note: It is no longer the case that constructing a PKCS#7 file
and parsing them back out will keep the certificates and CRLs in the
same order.
[0] https://source.chromium.org/chromium/chromium/src/+/main:chrome/common/net/x509_certificate_model_nss_unittest.cc;drc=c91b0c37b5ddf31cffd732c661c0c5930b0740f4;l=286
Change-Id: If776bb78476557af2c4598f1b6dc10e189adab5d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47304
Reviewed-by: Adam Langley <agl@google.com>
Bug: 275
Change-Id: I8096070386af7d2b5020875ea09bcc0c04ebc8cd
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47245
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
When updating the test file for SHA-1 support, I forgot to remove the
non-deterministic bits (i.e. key and signature generation) from the
input vectors.
Change-Id: Id47f9b2cc85282f68b71aedc271d4b4b53e04c70
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47285
Reviewed-by: David Benjamin <davidben@google.com>
Upstream ultimately preferred a different naming convention, and
type-specific constants. Align with them.
Update-Note: This renames some BoringSSL-specific constants that we
recently added. It doesn't look like anyone's used them yet.
Change-Id: I580e0872a5f09fb1c5bab9127c35f1ed852680c0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47164
Reviewed-by: Adam Langley <agl@google.com>
The implementation is a little goofy, but OBJ_dup internally makes a
copy of all the data.
Change-Id: I58e6804ede00100211ac112f03e26a34a2d29b5a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47125
Reviewed-by: Adam Langley <agl@google.com>
Someone asked me about this API and I realized it didn't clarify what
DER representation.
Change-Id: I3c53df200612dd5a8269a14dd04e7b430cd96389
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47124
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Clang 12 in opt mode produces a couple of assembly patterns that were
not handled by delocate.
Firstly, two-digit vector indexes were just a simple omission. Fixed.
Secondly, Clang puts symbol deltas in .byte directives, and bit-shifts
them. The .byte directive was not considered to be a symbol-containing
directive because it's too small, but it could store deltas.
Additionally, bit-shifting of symbol expressions was not supported.
Fixed.
Change-Id: I796299821f5ac7d3639fa6243c5d9bd5342bbddf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47064
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Change-Id: Ieb403b6651d445948abef48d7432fd248294284f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47084
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
These functions are not in any released version of OpenSSL. The history
is they were added to 1.0.2 beta for CT, but then removed in favor of
i2d_re_X509_tbs. We forked in between the two events.
I'm not sure what the reasoning was upstream's end. I'm thinking:
- X509 currently only captures the serialized TBSCertificate. It might
be nice to capture the whole Certificate to avoid needing a
serialization in X509_cmp and make it easier to interop with other
stacks. (Unclear.) That would require not exporting the X509_CINF
standalone for serialization.
- The modified bit means, without locking, i2d_X509 is not const or
thread-safe. We *might* be able to shift the re-encoding to
i2d_re_X509_tbs, which is already inherently non-const. That requires
not having X509_CINF_set_modified.
I'm not sure how feasible either of these are, but between that,
upstream alignment, and X509_CINF otherwise being absent from public
accessors, it seems worth removing.
Update-Note: X509_get_cert_info, X509_CINF_set_modified, and
X509_CINF_get_signature are removed. I believe all callers have been
updated. Callers should use i2d_re_X509_tbs, i2d_X509_tbs, and
X509_get0_tbs_sigalg instead.
Change-Id: Ic1906ba383faa7903973cb498402518985dd838c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46985
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This is mostly to confirm the STACK_OF(ASN1_TYPE) was created the right
number of times.
Change-Id: I30c32f91cb6091e63bfcaebb0fe966270e503d93
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46984
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
b571e77773 changed these fd numbers, but that interacts poorly with
cross-version tests. Instead, remove the assumptions StartProcess() was
making about the relationship between the two sets of fds.
Change-Id: If8fe62e4d20d22776e79e05e82cb5920cbb545ec
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47044
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Dan McArdle
David Benjamin
Adam Langley
Steven Valdez
Piotr Sikora