Bug: chromium:1322914
Change-Id: Ic5a1349013bcfb279e5fee9f9838c63558d663b7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/63025
Auto-Submit: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This also removes fillins/check.h which is no longer needed.
Crbug: 1322914
Change-Id: If5e8355700472bf6703c80809ea276c4c07ddc52
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62485
Auto-Submit: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Seed the corpus from cert_corpus. As part of that, check in the result of minimizing all the corpora.
Note this is just making one of the fuzzers build, I'll adapt
the others and follow on by updating the IMPORT process to do it
in a follow on cl.
Bug: chromium:1322914
Change-Id: Iea1b89f8fee938fa99c0a4d8134bcd0e7023d149
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61765
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Right now we use NIDs to configure the group list, but group IDs (the
TLS codepoints) to return the negotiated group. The NIDs come from
OpenSSL, while the group ID was original our API. OpenSSL has since
added SSL_get_negotiated_group, but we don't implement it.
To add Kyber to QUIC, we'll need to add an API for configuring groups to
QUICHE. Carrying over our inconsistency into QUICHE's public API would
be unfortunate, so let's use this as the time to align things.
We could either align with OpenSSL and say NIDs are now the group
representation at the public API, or we could add a parallel group ID
API. (Or we could make a whole new SSL_NAMED_GROUP object to pattern
after SSL_CIPHER, which isn't wrong, but is even more new APIs.)
Aligning with OpenSSL would be fewer APIs, but NIDs aren't a great
representation. The numbers are ad-hoc and even diverge a bit between
OpenSSL and BoringSSL. The TLS codepoints are better to export out to
callers. Also QUICHE has exported the negotiated group using the
codepoints, so the natural solution would be to use codepoints on input
too.
Thus, this CL adds SSL_CTX_set1_group_ids and SSL_set1_group_ids. It
also rearranges the API docs slightly to put the group ID ones first,
and leaves a little note about the NID representation before introducing
those.
While I'm here, I've added SSL_get_negotiated_group. NGINX seems to use
it when available, so we may as well fill in that unnecessary
compatibility hole.
Bug: chromium:1442377
Change-Id: I47ca8ae52c274133f28da9893aed7fc70f942bf8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60208
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We're this awkward mix of "group" and "curve" right now. On the spec
side, this is because they used to be "curves", but then RFC 7919
renamed to "group" in an attempt to generalize FFDH and ECDH. The
negotiated FFDH stuff never really went anywhere (the way it used cipher
suite values in TLS 1.2 made it unusable), but the name change stuck.
In our implementation and API, we originally called it "curve". In
preparation for TLS 1.3, we renamed the internals to "group" to match
the spec in
https://boringssl-review.googlesource.com/c/boringssl/+/7955, but the
public API was still "curve".
Then we exported a few more things in
https://boringssl-review.googlesource.com/c/boringssl/+/8565, but I left
it at "curve" to keep the public API self-consistent.
Then we added OpenSSL's new "group" APIs in
https://boringssl-review.googlesource.com/c/boringssl/+/54306, but
didn't go as far to deprecate the old ones yet.
Now I'd like to add new APIs to clear up the weird mix of TLS codepoints
and NIDs that appear in our APIs. But our naming is a mess, so either
choice of "group" or "curve" for the new API looks weird.
In hindsight, we probably should have left it at "curve". Both terms are
equally useless for the future post-quantum KEMs, but at least "curve"
is more unique of a name than "group". But at this point, I think we're
too far through the "group" rename to really backtrack:
- Chromium says "group" in its internals
- QUICHE says "group" in its internals and public API
- Our internals say "group"
- OpenSSL has switched to "group" and deprecated "curve", so new APIs
will be based on "group"
So align with all this and say "group". This CL handles set1_curves and
set1_curves_list APIs, which already have "group" replacements from
OpenSSL. A follow-up CL will handle our APIs. This is a soft deprecation
because I don't think updating things is particularly worth the churn,
but get the old names out of the way, so new code can have a simpler API
to target.
Also rewrite the documentation for that section accordingly. I don't
think we need to talk about how it's always enabled now. That's a
reference to some very, very old OpenSSL behavior where ECDH negotiation
needed to be separately enabled.
Change-Id: I7a356793d36419fc668364c912ca7b4f5c6c23a2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60206
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Trying to fix all the places where these formats go quadratic isn't a
good use of time. We've already documented that they're not safe for use
with untrusted inputs. Even without such DoS issues, they cannot be
safely used anyway. (E.g. RUSTSEC-2023-0023.)
Just cap the fuzzer input. It'd be nice if we could avoid this more
systematically in the function, but they're not structured to make this
easy to do, and anyone concerned about DoS in this function has worse
problems.
Bug: chromium:1444420, oss-fuzz:56048, 611
Change-Id: I53eeb346f59278ec2db3aac4a92573b927ed8003
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59785
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
We used to have a tower of fallbacks to support older Androids that were
missing getauxval. The comments say getauxval is available in Android
API level 20 or higher, but this wasn't right. It's actually API level
18 or higher per the NDK headers and
https://developer.android.com/ndk/guides/cpu-features
Android API level 18 is Android 4.3, or Jelly Bean MR2. Recent versions
of the NDK (starting r24, March 2022) don't even support Jelly Bean,
i.e. the minimum API level is 19, and the usage statistics in the latest
Android Studio stop at KitKat. As far as I know, nothing needs us to
support API levels 17 and below anymore.
Update-Note: BoringSSL now requires API level 18 or later. Projects
needing to support API level of 17 or below will fail to build due to
the use of getauxval. If any such projects exist, please contact
BoringSSL maintainers.
Change-Id: Iedc4836ffd701428ab6d11253d4ebd5a9121e667
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57506
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This was added with the generated symbol-prefixing header. But it
seems to be sufficient for crypto to have a dependency on the
generated header, along with some of the stray bits of delocate.
It's a little unclear from CMake documentation how these are processed;
normally .o files can be built before libraries are built or linked,
only the link step depends on.
But, empirically, if A links B, and B has a dependency on C, then CMake
seems to run C before building any of A. I tested this by making a small
project where the generation step slept for three seconds and running
with enough parallelism that we'd have tripped.
Interestingly, in the Makefile output, the individual object file
targets didn't have that dependency, but the target itself did. But this
was true on both A and B, so I think that just might not work.
Also fix the dependency in the custom target. The old formulation broke
when using an absolute path to the symbols file.
Change-Id: I2053d44949f907d465da403a5ec69c191740268f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56928
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
It's unclear to me whether doing it target-by-target is an improvement
in crypto/fipsmodule, but this otherwise does seem a bit tidier. This
aligns with CMake's documentation and "modern CMake" which prefers this
pattern.
Change-Id: I36c81842bff8b36eeaaf5dd3e0695fb45f3376c9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56585
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
All evidence we have points to these devices no longer existing (or at
least no longer taking updates) for years.
I've kept CRYPTO_has_broken_NEON around for now as there are some older
copies of the Chromium measurement code around, but now the function
always returns zero.
Change-Id: Ib76b68e347749d03611d00caecb6b8b1fdbb37b1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56765
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
This fuzzes the config file parser, and the converrsion to X.509
extensions. The initial corpus was computed by:
1. Import every file from OpenSSL 1.1.1 that ends in .cnf.
2. For each section in each such file, add a copy with that section
copied to the top (the "default") section.
3. Also add a file for each unit test.
4. Minimize the corpus.
While I'm here, sort the targets in fuzz/CMakeLists.txt.
Change-Id: I0cfc1ae8e2be3e67dae361605ad19833aec3fe4d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56167
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
X509 objects do some deferred parsing. Make sure we cover that code with
fuzzers.
Change-Id: I618e90aaf4d8decbc3af59f36910feb9949a8cd2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55751
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
We use unsigned, but we actually assume it is 32-bit for the bit-packing
strategy. But also introduce a typedef to hint that callers shouldn't
treat it as an arbitrary 32-bit integer. A typedef would also allow us
to extend to uint64_t in the future, if we ever need to.
Update-Note: Some APIs switch from unsigned * to uint32_t * out
pointers. This is only source-compatible if unsigned and uint32_t are
the exact same type. The CQ suggests this is indeed true. If they are
not, replace unsigned with CBS_ASN1_TAG to fix the build.
Bug: 525
Change-Id: I45cbe127c1aa252f5f6a169dca2e44d1e6e1d669
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54986
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
ECDSA_verify does a runtime check that our parser round-trips, but that
should already be true. Add a fuzzer to ensure it.
Change-Id: I396863b8f9ed66c6296cfb16f7197a63ae99e156
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52733
Reviewed-by: Adam Langley <agl@google.com>
We use underscores everywhere except these files, which use hyphens.
Switch them to be consistent.
Change-Id: I67eddbdae7caaf8405bdb4a0c1b65e6f3ca43916
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50808
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Ran the following command at OpenSSL commit
18622c7625436d7f99c0f51895c4d3cea233c62e:
./build-fuzz/fuzz/cert -merge=1 -max_len=10000 fuzz/cert_corpus/ ~/openssl/fuzz/corpora/x509
Change-Id: I22c4051351138736a0fa0202c0977ca9afc6924c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49047
Reviewed-by: Adam Langley <agl@google.com>
Given the error handling issues in the previous CL, we'll probably be
chasing down bugs in there for a while.
Change-Id: I7a219e0fe2496f602d38b4bd0fcd5585ebd72cb7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49046
Reviewed-by: Adam Langley <agl@google.com>
Previously we would extract the KEM ID from the ECHConfig and then parse
the private key using the corresponding KEM type. This CL makes it take
a pre-pared EVP_HPKE_KEY and checks it matches. This does require the
caller pass the key type through externally, which is probably prudent?
(On the other hand we are still inferring config from the rest of the
ECHConfig... maybe we can add an API to extract the EVP_HPKE_KEM from a
serialized ECHConfig if it becomes a problem. I could see runner or tool
wanting that out of convenience.)
The immediate motivation is to add APIs to programmatically construct
ECHConfigs. I'm thinking we can pass a const EVP_HPKE_KEY * to specify
the key, at which point it's weird for SSL_ECH_KEYS_add to look
different.
Bug: 275
Change-Id: I2d424323885103d3fe0a99a9012c160baa8653bd
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48002
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Also generate a corpus to unblock the Chromium roll. The build tools
expect there to be a corresponding directory somewhere.
Bug: 275
Change-Id: I7a061ba6625ec57c10b0ae17e68b6b0159c539d4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46826
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
'corpora' seems to be more common than 'corpuses' in Chromium code
search, including in libFuzzer's source itself.
Change-Id: I6489b57a4608f47274c4400aac135cbfb991953a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46825
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This CL adds an initial implementation of the ECH server, with pieces of
the client in BoGo as necessary for testing. In particular, the server
supports ClientHelloInner compression with ech_outer_extensions. When
ECH decryption fails, it can send retry_configs back to the client.
This server passes the "ech-accept" and "ech-reject" test cases in
tls-interop-runner[0] when tested against both the cloudflare-go and nss
clients. For reproducibility, I started with the main branch at commit
707604c262d8bcf3e944ed1d5a675077304732ce and updated the endpoint's
script to pass the server's ECHConfig and private key to the boringssl
tool.
Follow-up CLs will update HPKE to the latest draft and catch us up to
draft-10.
[0]: https://github.com/xvzcf/tls-interop-runner
Bug: 275
Change-Id: I49be35af46d1fd5dd9c62252f07d0bae179381ab
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45285
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Bob Beck
David Benjamin
Dan McArdle
Adam Langley