OpenSSL added a similar helper function. It's very, very common for us
to malloc something an then zero it. This saves some effort. Also
replace some more malloc + memcpy pairs with memdup.
Change-Id: I1e765c8774a0d15742827c39a1f16df9748ef247
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/63345
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Old version Chrome with the existing ALPS codepoint can potentially cause network error due to an arithmetic overflow bug in Chrome ALPS decoder (We already fixed the issues starting from M100 in Chrome).
This CL add a new codepoint for ALPS extension in a way that can be enabled on individual connections., To support multiple versions of Chrome, we need to support both codepoints in BoringSSL.
For details: https://docs.google.com/document/d/16pysbV_ym_qAau_DBYnrw2A4h5ve2212wfcoYASt52U
Change-Id: Iea7822e757d23009648febc8eaff1c91b0f06e18
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61125
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
We have a corresponding check on the ServerHello, but not
HelloRetryRequest. See also https://github.com/rustls/rustls/pull/1374,
where rustls forgot to apply the compatibility logic to
HelloRetryRequest.
(From the perspective of a TLS-1.2-expecting observer, HelloRetryRequest
is the ServerHello, so encoding hacks need to apply to both.)
Change-Id: I9b711ea45c54770a76ecfbca8bc992a4eaef6fcd
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62906
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Newer glibc have an attribute((nonnull(1))) on fclose. Attributes aren't
part of the language, so decltype(fclose) lose the attribute. It seems
this causes std::unique_ptr<FILE, decltype(fclose)> to trip
-Wignored-attributes in GCC.
This is a bit aggressive of a warning, but work around this with a
custom deleter, which makes the unique_ptr object smaller anyway.
(Though the compiler can, I hope, dissolve all of this anyway.)
Fixed: 642
Change-Id: I9a0206a8c5675f856e80c5266c90be42d66a5606
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62465
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Pretty much all of std::span and base::span are constexpr. der::Input
similarly has constexpr bits. So we can use bssl::Span in der::Input,
align bssl::Span in constexpr-ness.
Also fix const-ness of first() and last().
Bug: chromium:770501
Change-Id: Ic0031cd955d8ac0af9c3cb928411f23a34820347
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61945
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Like OPENSSL_NO_FILESYSTEM, keep us honest: if the symbol is missing,
don't declare it in the headers. This ensures folks aren't relying on
dead code elimination and then later break when they build in a context
where it doesn't happen.
Bug: 629
Change-Id: I3e56c3879e970aa8d0d6e0e5f1ad046d0f420ef0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61730
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Detecting errors (i.e. fs-less platforms using fs-only APIs) at compile
time is generally preferable to doing so at runtime, so
https://boringssl-review.googlesource.com/c/boringssl/+/61726 opted to
remove the APIs altogether on applicable targets.
However, Trusty uses rust-openssl somewhere and rust-openssl binds a
bunch of filesystem-dependent APIs unconditionally. To keep that
working, switch to a stub fopen when OPENSSL_NO_FILESYSTEM is set. We
effectively model a platform where the filesystem "exists", but is
empty. Upstream OpenSSL similarly has OPENSSL_NO_STDIO still define the
file BIO (unlike the socket BIO, which is excluded), but in a stub form.
As part of this, I've gone ahead and resolved one of the Trusty TODOs.
It does produce a duplicate symbol with [1], but things seem to link
fine in treehugger. In case it does break, I've bumped
BORINGSSL_API_VERSION, so we can go in and condition it if needed.
[1] https://android.googlesource.com/trusty/lib/+/refs/heads/main/lib/openssl-stubs/bio.c
Bug: 629
Change-Id: I4f20d872a7cde863d21c78090f270b77b03545fa
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61925
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This corresponds to the libcrypto_baremetal build target in Android,
which is an embedded-style platform that uses a subset of the bionic
libc. It will also, eventually, use getentropy for its PRNG.
As part of this, generalize the OPENSSL_TRUSTY exclusion for file BIOs
to OPENSSL_NO_FILESYSTEM. Upstream OpenSSL uses OPENSSL_NO_STDIO, but
that excludes all of FILE entirely. We already require FILE in quite a
few places (urandom.c, self_test.c) for writing to stderr, and FILE is
part of C standard library. So, let's tentatively say that we require
you have FILE and stderr.
Instead, OPENSSL_NO_FILESYSTEM is saying you don't have fopen. You're
still required to have the three std{in,out,err} FILEs, and given a
FILE, you need to allow the standard operations on it. (Possibly in
forms that always fail.)
To keep us honest, whenever a function is excluded, I've dropped it from
the header too, and followed callers up the chain. I have not attempted
to make the tests work when these are excluded. Later CLs in this series
will do the same for NO_SOCK and NO_POSIX_IO. This was a little tedious,
but not too bad.
(I assume we'll end up changing our minds on this a lot. For now, let's
try this.)
I haven't yet restored OPENSSL_RAND_TRUSTY or removed the OPENSSL_TRUSTY
ifdef on file.c. Having a separate CL makes it a bit easier to revert if
something goes wrong.
This depends on
https://android-review.googlesource.com/c/platform/bionic/+/2659335,
which fixes the header bionic uses for getentropy.
Bug: 629, b:291102972
Change-Id: Idd839cd3fa4253128de54bd1be7da261dbcdeb7c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61726
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Our BIO_snprintf is just a thin wrapper over the libc one, and we
already call it directly in other places. Just call the libc one
consistently.
Change-Id: Ia7daf26b9789ddcecab67118c4ec4a077aad5a22
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61685
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
We'd leak the socket if Connect failed in the middle. (This doesn't
especially matter. The test process would just exit anyway.)
Change-Id: I8e1f252781810b1d8ef3c41bd707dfebb0371e60
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61665
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Also remove unnecessary EC_GROUP_free calls. EC_GROUP_free is only
necessary in codepaths where arbitrary groups are possible.
Bug: 20
Change-Id: I3dfb7f07b890ab002ba8a302724d8bc671590cfe
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60932
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
We've required C++14 for a while now. As we're mostly C with a little
C++, this is less helpful, but may as well avoid bare new where
possible.
Change-Id: Icf3386e3f3b6f2092bb0089ed874cc50985f1a40
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61429
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This was, I assume, needed for cross-version tests, but we're long past
2020 now. While I'm here, switch a unique_ptr(new T) into make_unique as
we can rely on C++14 now.
Change-Id: I3f2fde90f124522c21868c15217f607b7f6d75db
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61428
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CMake and the generate builds now broadly share a source of truth for
the test files.
Update-Note: In the standalone CMake build, build/crypto/crypto_test is
now build/crypto_test, etc. For now, the build still copies the outputs
to the subdirectories (it's cheap and avoids some workflow turbulence),
but I'm thinking we keep that for six months or so and then remove it.
Bug: 542
Change-Id: I8f97e1fcedea1375d48567dfd2da01a6e66ec4e8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61286
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
While I'm here, update x/crypto and x/net to their latest versions.
byteReader is a straightforward port, except there doesn't seem to be a
convenient way to read length-prefixed bytes without manually casting
from cryptobyte.String to []byte, so I've done that.
byteBuilder is a bit more involved because it's based on closures, but
still a mechanical change.
As part of this, I switched runner's ticket format to use u24 length
prefixes instead of u32, because cryptobyte.String doesn't have u32
length prefixes. (Although, oddly, cryptobyte.Builder does.)
Fixed: 374
Change-Id: If9bea0b41fe2b8bc48f040a667753b160da469bb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61186
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
The shim is now passed a shim ID which allows us to dispatch.
Previously, we dispatched with a distinct TCP server port per test, but
this seems to exhaust local ports.
As with https://boringssl-review.googlesource.com/c/boringssl/+/60885,
this changes the runner/shim protocol, but not the shim/handshaker
protocol. See that CL for discussion.
Change-Id: Ia22d1bc0bcda1b1869bce4630138538c30f02668
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60888
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
That we pull a value out of a channel and put it back is pretty weird.
Also we don't need a select in accept(). It's enough to just close the
listener when we learn the child is gone. (That will cancel the
Accept call.)
Change-Id: If520d9f405fa0b1ad6e3cd23e9ba8a35ff39ba75
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60887
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
It's a bit more verbose to set up, but makes the error paths in
Connect() tidier. While I'm here, stick to Windows' actual SOCKET
type until we have to cross into BIO. It doesn't really matter
(Windows cannot use the upper half of that type without badly
breaking backwards compatibility), but it silences some 64/32
truncation warnings.
Change-Id: I7be7c2b543373a7a9fc50711131e5345d84ebb8b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60886
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The runner currently tries to listen on IPv6 and then falls back to IPv4
on error. The shim does the same. If they pick different ones, this
breaks down.
Normally, fallback happens because the system doesn't have IPv6, and
both sides will make the same decision. But if binding to IPv6 fails for
other reasons, they may mismatch. We're observing them fail due to what
seems to port exhaustion. When this happens, shim and runner don't
agree on the same address family.
Instead, just tell the shim which address to connect to. This doesn't
fix the underlying port exhaustion problem, but it does seem to fix the
flakes. Although given we are still exhausting ports and falling back to
IPv4, it doesn't truly fix it. Later CLs will address port exhaustion by
using a single server port.
This changes the runner <-> shim protocol, but hopefully in a fairly
obvious way that others using BoGo can easily follow. It shouldn't break
our cross-version tests because we keep runner and shim at the same
versio there.
To avoid needing to make an incompatible change to the shim <->
handshaker protocol, which would impact our cross-version tests, this
introduces a mechanism for the shim omit flags when talking to the
handshaker. The handshaker doesn't need to know how to connect to the
runner.
Also print the error string on Windows. Sadly this is a bit tedious.
Change-Id: Ic8bda9a854a115c206c05a659a2e34f544b844a6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60885
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This would have made debugging some cross-version test easier.
Change-Id: I7b1bc160b5acf40ec02b9ed5ac2d836e3203cf9a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60805
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
We added SSL_CIPHER_get_prf_nid to match the other SSL_CIPHER_get_*_nid
functions, but OpenSSL went with returning the EVP_MD instead.
rust-openssl uses this function, and all the callers of
SSL_CIPHER_get_prf_nid then call EVP_get_digestbynid anyway, so this
version is preferable.
Update-Note: This change is backwards-compatible, but we should update
the QUIC code to use this new function when OPENSSL_API_VERSION is
high enough. It has the benefit of not pulling in random other hash
functions like MD4.
Change-Id: Ied66a6f0adbd5d7d86257d9349c40a2830e3c7e8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60606
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@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>
This adds "group" versions of our codepoint-based APIs. This is mostly
because it looks weird to switch terminology randomly in the
implementation. See I7a356793d36419fc668364c912ca7b4f5c6c23a2 for
additional context.
I've not bothered renaming the bssl_shim flags. That seems a waste of
time.
Change-Id: I566ad132f5a33d99efd8cb2bb8b76d9a6038c825
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60207
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@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>
Update-Note: SSL_CIPHER_get_value was our original name for the
function. OpenSSL later called it SSL_CIPHER_get_protocol_id. I believe
all external callers have since been updated to use the new function.
(If I missed a few stragglers, replace with SSL_CIPHER_get_protocol_id
to fix.)
Change-Id: I956fb49bf2d13a898eed73177493d2c8d50778ad
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60205
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
3DES has long been obsolete. It uses a small block size, making it
vulnerable to attacks at sufficiently high volumes (see
https://sweet32.info/, CVE-2016-6329). On top of this, it is slow even
without constant-time protections, making it a DoS risk for server
operators.
Since the alias "3DES" has existed in OpenSSL for a long time, keep that
one working, to reduce the risk of breaking someone who specifically
wanted 3DES enabled.
Update-Note: This CL disables TLS_RSA_WITH_3DES_EDE_CBC_SHA by default.
Specifically, it will not be included unless explicitly listed in the
cipher config, as "TLS_RSA_WITH_3DES_EDE_CBC_SHA", its legacy OpenSSL
name "DES-CBC3-SHA", or the alias "3DES". To restore it, add one of the
above to your cipher config.
Bug: 599
Change-Id: Ib94a2f149b3bfa240ef1008b9f3729a9c10368fb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59425
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This is intended to be run under TSan. ex_data currently works by taking
a global read lock every time an RSA, SSL, SSL_CTX, etc., is freed. We
should be able to fix that but, first, make sure we have test coverage
for the threading requirements.
Bug: 570
Cq-Include-Trybots: luci.boringssl.try:linux_clang_rel_tsan
Change-Id: I0e12907e116481d88e45191a1f15f3a51833bf6d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59865
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Saves some duplicated logic.
Change-Id: I202fa92a88101f9ad735648bc414ab05752641da
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59685
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Envoy needs to have the possible cipher, etc., strings predeclared to
reduce synchronization needs in the steady state. It currently does this
by (1) iterating over SSL_CTX_get_ciphers at SSL_CTX creation time and
(2) hard-coding a lists of known TLS 1.3 ciphers, TLS versions,
NamedGroups, etc.
(1) would work for some applications, but it breaks any applications
that configure ciphers on the SSL on a certificate callback, etc. If the
callback configures a cipher that wasn't configured on the SSL_CTX (e.g.
if the SSL_CTX were left at defaults), Envoy's logging breaks and we hit
an ENVOY_BUG assertion.
(2) breaks whenever BoringSSL adds a new feature. In principle, we could
update Envoy when updating BoringSSL, but this is an unresasonable
development overhead for just one of many BoringSSL consumers to impose.
Such costs are particularly high when considering needing to coordinate
updates to Envoy and BoringSSL across different repositories.
Add APIs to enumerate the possible strings these functions can return.
These string lists are a superset of those that any one application may
care about (e.g. we may have a deprecated cipher that Envoy no longer
needs, or an experimental cipher that's not yet ready for Envoy's
stability goals), but this is fine provided this is just used to
initialize the table. In particular, they are *not* intended to
enumerate supported features.
Bump BORINGSSL_API_VERSION to aid in patching these into Envoy.
Bug: b:280350955
Change-Id: I4d11db980eebed5620d3657778c09dbec004653c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59667
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This TLS 1.2 algorithm is substantially inferior to AES-GCM and should
never be used. It will not be available unless configured by name.
However, in can be used to provide backwards-compatibility with devices
that cannot be updated if so needed.
Change-Id: I1fd78efeb33aceca76ec2e7cb76b70f761ed1af8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59585
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: Adam Langley <agl@google.com>
This generalizes the scheme we previously had with
TLS_RSA_WITH_NULL_SHA, in preparation for TLS_RSA_WITH_3DES_EDE_CBC_SHA
(to be deprecated in a later CL) and
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (to regretably be added back in,
but in a deprecated state).
The story is that deprecated ciphers can always be listed by name, but
by default, selectors will not match them when adding ciphers. They will
still match them when removing ciphers. This is so instructions like
"@STRENGTH" or "!RSA" will still sort or disable the deprecated ciphers,
rather than accidentally leaving them at the front or enabled.
Additionally, a selector can mark itself as including deprecated
ciphers. This is specifically for TLS_RSA_WITH_3DES_EDE_CBC_SHA, because
many callers reference it with just "3DES". As an added quirk,
"RSA+3DES" will also match it. (The rule is that, if any selector matches
deprecated ciphers, we'll allow the overall expression to match it. This
is slightly weird, but keeps "RSA+3DES" working.)
Note, in this CL, 3DES is not actually deprecated. This just sets up the
machinery and doesn't do anything with it. But the blockers for
deprecating that should hopefully be resolved soon.
Bug: 599
Change-Id: I7212bdc879b0e49c6742025644f3100026f24228
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59646
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
The initial codepoint is called X25519Kyber786Draft00 in the draft, so
align with that name for this version. Also remove the placeholder bits
for the other combinations, which haven't gotten that far yet.
Update-Note: Update references to NID_X25519Kyber768 to
NID_X25519Kyber768Draft00. For now, the old name is available as an
alias.
Change-Id: I2e531947f41e589cec61607944dca844722f0947
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59605
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Satisfy a go lint. As of Go 1.18, any is the preferred spelling of
interface{}.
Also remove an instance of redundant types in
util/fipstools/acvp/acvptool/acvp.go because my editor warned about it.
(A []map[string]any{map[string]any{...}, map[string]any{...}} literal
can omit the inner copy of the type because it's implicit from the outer
one.)
Change-Id: I2251b2285c16c19bc779fa41d1011f7fa1392563
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59465
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Change-Id: I49920d3917f0aebf1b9efbd45d0bcd944d6c8117
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59405
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
It's unwise for organisations to try and define TLS profiles. As in this
case, they usually make security worse. However, since this is already
established and supported by Android, this change raises it to the level
of a supported policy.
Change-Id: Ic66d5eaa33d884e57fc6d8eb922d86882b621e9e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58626
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
AllCurves interferes with cross-version handshake hint tests. If any
curve is removed, the test breaks. This is a particular nuisance for
signing tests, where we'd rather like to see cross-version hint
compatibility. It's also a nuisance for writing test suppressions
because the remove curve is not actually listed in the test name.
The signing tests don't actually need to enable all curves. They just
need to handle some TLS 1.2 ECDSA rules. Fix that by having the test
know the expected curve and to configure it explicitly. Hopefully
that'll reduce the exceptions needed in the future.
Change-Id: I432e084c49a943afc92726ccf0b73658e7bd30b1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59325
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
We previously used the functions from the cipher language to define it,
but it's more straightforward to just list them out.
Change-Id: I1467d6db47a93c8443a0a448ef974c827b1b3233
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59146
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Add a new flag, -shim-extra-flags, which allows specifying additional
flags to pass to the shim binary on all invocations. These flags will be
passed as the first flags to the shim in order to take advantage of some
slightly confusing Go flag semantics.
Change-Id: I382f47bfe2662903b43135fcb249b46646fc9e7b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59245
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Per b/31553927, the last use of this is long gone. This cipher has been
deprecated since it was (re)-added in 2015, so it's long past time to
remove it.
Update-Note: TLS_RSA_WITH_NULL_SHA is no longer available. Nothing
should be enabling it anymore. Callers using
SSL_CTX_set_strict_cipher_list instead of SSL_CTX_set_cipher_list will
notice if they're affected very quickly, because the functino will
fail if this cipher is referenced. As a deprecated cipher suite, this
cipher was already unavailable unless explicitly named, so if your
configuration doesn't say "TLS_RSA_WITH_NULL_SHA" or "NULL-SHA", you
were not using this cipher.
Bug: b:31553927
Change-Id: Id560bb4f9b156be3650d63f4ecf7783fad5ae209
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59145
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
This relands
https://boringssl-review.googlesource.com/c/boringssl/+/54606, which was
temporarily reverted.
Update-Note: By default, clients will now require RSA server
certificates used in TLS 1.2 and earlier to include the keyEncipherment
or digitalSignature bit. keyEncipherment is required if using RSA key
exchange. digitalSignature is required if using ECDHE_RSA key exchange.
If unsure, TLS RSA server signatures should include both, but some
deployments may wish to include only one if separating keys, or simply
disabling RSA key exchange. The latter is useful to mitigate either the
Bleichenbacher attack (from 1998, most recently resurfaced in 2017 as
ROBOT), or to strengthen TLS 1.3 downgrade protections, which is
particularly important for enterprise environments using client
certificates (aka "mTLS") because, prior to TLS 1.3, the TLS client
certificate flow was insufficiently encrypted or authenticated. Without
reflecting an RSA key exchange disable into key usage, and then the
client checking it, an attacker can spoof a CertificateRequest as coming
from some server.
This aligns with standard security requirements for using X.509
certificates, specified in RFC 5280, section 4.2.1.3, and reiterated in
TLS as early as TLS 1.0, RFC 2246, section 7.4.2, published 24 years ago
on January 1999. Constraints on usage of keys are important to mitigate
cross-protocol attacks, a class of cryptographic attacks that is
well-studied in the literature.
We already checked this for each of ECDSA, TLS 1.3, and servers
verifying client certificates, so this just fills in the remaining hole.
As a result, this change is also important for avoiding some weird
behaviors when configuration changes transition a server in or out of
this hole. (We've seen connection failures get misattributed to TLS 1.3
when it was really a certificate misconfiguration.)
Chrome has also enforced this for some time with publicly-trusted
certificates. As a temporary measure for callers that need more time,
the SSL_set_enforce_rsa_key_usage API, added to BoringSSL in January
2019, still exists where we need to turn this off.
Fixed: 519
Change-Id: I91bf2cfb04c92aec7875e640f90ba6f837146dc1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58805
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Change-Id: I32a40a73f96e029ac9096af826d15b22d9dcad28
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58745
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
HRSS itself remains in libcrypto because there are some direct users of
it. But this will let it be dropped by the linker in many cases.
Change-Id: I870eda30c9ed1d08693c770e9e7df45a2711b7df
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58645
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Also unexport PEM_proc_type and PEM_dek_info. They're never called
externally, just private functions within one file. Also, while I'm
here, fix the include guard on asn1/internal.h.
Bug: 516
Change-Id: I6961a65f638e7b464a8c349663898a954d7826b4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58548
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This was replaced with the upstream-compatible SSL_CIPHER_standard_name
in https://boringssl-review.googlesource.com/17324. It looks like we've
since migrated everything off the old name, so let's just remove it.
Update-Note: SSL_CIPHER_get_rfc_name calls can be replaced with
SSL_CIPHER_standard_name, which is also more efficient as it avoids an
allocation and copy. If anyone's using this function and can't easily
migrate, let us know and we can put this back for a little longer.
Change-Id: I6bce40a8a146671429641a5dbff6f614006a9a1c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58665
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Change-Id: I06773ff0c42c68f1f2d4c581f52b71008c4cdb3c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58625
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Auto-Submit: Adam Langley <agl@google.com>
Normally these would be size_t, but we try to reduce per-connection
memory in libssl, so use uint8_t, then add asserts, checks, and casts as
appropriate.
Bug: 516
Change-Id: Ibdd9d88f2b05173daee2db5f6fb77d619302bfdf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58547
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
David Benjamin
Victor Tan
Adam Langley
Adam Langley
Adam Langley
Roland Shoemaker
Bob Beck