There are two naming conventions for TLS cipher suites, the standard
IETF names (SSL_CIPHER_standard_name) and the ad-hoc OpenSSL names
(SSL_CIPHER_get_name). When we added TLS 1.3, we had to come up with
OpenSSL-style names for the cipher suites.
OpenSSL-style names use hyphens rather than underscores (and omit
underscores in odd places), so the natural name for
TLS_AES_128_GCM_SHA256 would have been "AES128-GCM-SHA256". However,
that name is already taken by TLS_RSA_WITH_AES_128_GCM_SHA256 because
OpenSSL's naming convention treats the legacy RSA key exchange as
default. Instead, we used an "AEAD-" prefix to indicate the ciphers only
specified the AEAD.
Since then, OpenSSL has implemented TLS 1.3. Instead, they simply made
the OpenSSL-style name match the standard name starting TLS 1.3,
underscores and all. (This is why openssl s_client will return very
different-looking cipher names in TLS 1.2 and TLS 1.3.)
Align with OpenSSL and do the same.
Update-Note: SSL_CIPHER_get_name will return different values for TLS
1.3 ciphers than before. Note that we did not allow TLS 1.3 ciphers to
be configured at all, so no cipher suite configurations will need to
change, but code logging or asserting on the result of a TLS connection
may observe differences.
It is also recommended that consumers replace uses of
SSL_CIPHER_get_name with SSL_CIPHER_standard_name which gives a much
more consistent naming convention. (BoringSSL supports both standard and
OpenSSL names in the cipher suite configuration, so there's no need to
use OpenSSL names at all.)
Change-Id: I40b1de0689dd7b32af88602acc063934f2877999
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36764
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@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>
The added code is a one-shot function. A handful of instructions could
be saved by having a context object for repeated use of the same key,
but perhaps it's not needed.
Selected the 2-4 variant to implement because it seems to be
overwhelmingly the most commonly used.
Change-Id: I1e4f699f7dd5a2d35e12245fa116bafbd3439979
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36664
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
KWP is Key Wrap with Padding, defined in RFC 5649 and SP 800-38F. Like
Key Wrap, it's a poor-man's AEAD and shouldn't be used. However, some
existing systems use it and we need to interoperate.
The interface of the added functions is a little unfortunate, but they
match the interfaces of the existing Key Wrap functions which, in turn,
match functions in OpenSSL. Hopefully this way, if OpenSSL ever add
support, we'll line up.
Change-Id: I3496c288f32230a891261586ca2e9c4ee8456c09
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36324
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This change adds a FIPS integrity check using shared libraries. Unlike
with the static case, a shared build can take advantage of the linker
resolving relocations and thus doesn't need delocation. It does mean
that both .text and .rodata sections need to be handled, however, so the
hashing format is slightly different. inject-hash.go is updated to be
able to rewrite shared libraries to inject the correct hash value.
Change-Id: I9a71910cd6df3a85e4efac896b0913e65b5f875b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36024
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@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>
OpenSSL uses the private key to find the leaf certificate. cryptography.io's
tests rely on this.
Update-Note: PKCS12_parse's behavior changes slightly. Affected callers are
recommended to switch to PKCS12_get_key_and_certs, which has much more
predictable behavior and has no pressures from 3rd-party software to match
OpenSSL's quirks.
Change-Id: I4ee2befbd56a0882ee166f00e748f2fe58ac6a86
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36125
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>
cryptography.io expects this API for Ed25519. Replace the now redundant
EVP_PKEY_new_ed25519_* functions. Ours were more static-linker-friendly,
but we weren't taking advantage of it and EVP_PKEY needs an overhaul to
be static-linker-friendly anyway.
Update-Note: EVP_PKEY_new_ed25519_public and
EVP_PKEY_new_ed25519_private are removed in favor of
EVP_PKEY_new_raw_{public,private}_key. I do not believe anyone was using
those functions.
Change-Id: Ibd12b4e9e37cd8dd4dbc7ebc4346ba52655d523a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35806
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Including ssl.h is quite a chunk of code and #defines, so we've tried to
limit its spread internally in the interests of code hygine given that
we have a multi-billion-line repo.
However, header files that mention enums from ssl.h currently need to
include ssl.h. For example, your class may have static class member
functions intended to be callbacks, and they need to be class members
because they'll call other private methods.
C cannot predeclare enums, but C++ can if you explicitly type them.
Sadly C doesn't support explicit types. So option one is to move the
enums into base.h. That works, but the enums properly live in ssl.h and
reading the header file is a lot clearer if you don't have to jump
around to see all the pieces.
So option two (this change) is to explicitly type and predelcare the
enums in base.h for C++ only. The worry now is that C and C++ might
disagree about the type of the enums. However, this has already
happened: at least for |ssl_private_key_result_t|, g++ thinks that it's
an |int| (without any explicit type) and gcc thinks that it's an
|unsigned|. At least they're the same length, I guess?
So, to make sure that this doesn't slip any more, this change also adds
|ssl_test_c.c| which tests that C views the enums as having the same
size as an |int|, at least.
Change-Id: I8248583ec997021f8226d5a798609f6afc96dac4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35664
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
The common name fallback does not interact well with name constraints.
Until we remove this fallback, we must resolve this conflict.
Blindly applying name constraints to the common name will reject
"decorative" common names that aren't intended to be hostnames (e.g.
[0]). We need to guess based on format whether the common name is a DNS
name. It is important this same check is applied to *both* name
constraints and name matching, which means the OpenSSL version (see
5bd5dcd49605ca2aa7931599894302a3ac4b0b04,
d02d80b2e80adfdde49f76cf7c7af4e013f45005, and
55a6250f1e7336e8a7d89fb609eb23398715ff6f) is unsuitable as a
compatibility data point.
In theory we could limit this to chains with name constraints, which are
uncommon, but X509_check_host sees only the leaf. We must apply it
uniformly. That means a strict check risks problems with malformed
non-WebPKI setups like [1].
For a first pass, mirror Go's behavior. Like Go, rather than run
SAN-less DNS-like common names through name constraints, we simply
reject all such certificates. Name constraints now exclude all leaf
certificates that can trigger the common name fallback. They are rare
enough that we can hopefully hold them to a higher standard.
Note this does not make misclassified decorative common names any worse,
compared to the checking the name constraint. Such names would not have
matched the constraint anyway.
Update-Note: This can may cause two kinds of errors:
1. Leaf certificates whose chain contains a name constraint and lack
SANs may be rejected with X509_V_ERR_NAME_CONSTRAINTS_WITHOUT_SANS.
2. Leaf certificates which use the common name fallback and verify
against an insufficiently DNS-looking hostname may fail with
X509_V_ERR_HOSTNAME_MISMATCH.
In both cases, the fix is to include the subjectAltName in the
certificate, rather than rely on the common name fallback. (Refining the
heuristic is also an option, but the two failure modes pull it in
opposite directions, so this is tricky.)
[0] https://github.com/golang/go/issues/24151
[1] https://github.com/GoogleCloudPlatform/cloudsql-proxy/issues/194
Change-Id: If25557de428768292a14ba3bdeeffbd74e3a3bf8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35665
Reviewed-by: Adam Langley <agl@google.com>
This flag is backwards. We want to check the common name less, not more. See if
anything was actually relying on this.
Update-Note: X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT is now ignored.
Change-Id: I8288d57540f8117059e58d72cc173aa4d3077fb6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35646
Reviewed-by: Adam Langley <agl@google.com>
cryptography.io uses this and it's also the correct behavior. Ideally it would
be default, but start with just adding the flag. See also
dd60efea955e41a6f0926f93ec1503c6f83c4e58 from upstream.
Change-Id: I9e13cdbfd44c904ba5bd69a5a66c68c4b7596867
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35645
Reviewed-by: Adam Langley <agl@google.com>
This will allow edge servers to pass judgement on the ClientHello before
completing the handoff process. This also means that edge servers will
now enforce ClientHello well-formedness — previously that check didn't
occur until the handshaker tried to parse the handoff submission.
Change-Id: I9804ac0224632b4b4381c1a81f434d188e0b9376
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35584
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
AES_set_*_key used to call directly into aes_nohw_set_*_key which
gracefully handles some NULL parameters and invalid bit sizes. However,
we now enable optimized assembly implementations, not all of which
perform these checks. (vpaes does not.)
This is fine for the internal assembly functions themselves. Such checks
are better written in C than assembly, and the calling C code usually
already knows the key size. (Indeed aes_ctr_set_key already assumes the
assembly functions are infallible.) AES_set_*_key are public APIs,
however. The NULL check is silly, but we should handle length-like
checks in public APIs.
Change-Id: I259ae6b9811ceaa9dc5bd7173d5754ca7079cff8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35564
Reviewed-by: Adam Langley <agl@google.com>
Child and root CBBs share a type, but are different kinds of things. C++
programmers sometimes mistakenly believe they should use ScopedCBB for
everything. This mostly works because we NULL cbb->child->base on flush,
making CBB_cleanup a no-op. This zeroing also skips the assert in
CBB_cleanup. (If we ran it unconditionally, CBB_zero + CBB_cleanup would
not work.)
However, if a CBB operation fails and a function returns early, the
child CBB is not cleared. ScopedCBB will then call CBB_cleanup which
trips the assert but, in release build, misbehaves.
Run the assert unconditionally and, when the assert fails, still behave
well. To make this work with CBB_zero, negate is_top_level to is_child,
so a flushed child CBB and a (presumably) root CBB in the zero state are
distinguishable.
Update-Note: Code that was using CBB wrong may trip an assert in debug builds.
Change-Id: Ifea7759e1d0331f2e727c59bbafa355d70fb9dba
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35524
Reviewed-by: Adam Langley <agl@google.com>
We usually name output parameters 'out'. (Someone made a C++ templating
change in Chromium which messed up const-ness, saw the compile error,
and thought it was in MD5_Final.) Also tag the parameters with the
sizes.
Sadly, there's a bit of goofiness around SHA224_Final/SHA256_Final and
SHA384_Final/SHA512_Final, but they're just documentation anyway.
(Though it does touch on the mess that is sha->md_len which would be
nice to clear through somehow.)
Change-Id: I1918b7eecfe13f13b217d01d4414ac2358802354
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35484
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
When building node with boringssl, `SSL_CTX_get_min_proto_version` and
`SSL_CTX_get_max_proto_version` are used. Openssl exposes those; this
change adds support for boringssl.
For this to work right in DTLS, we switch conf_{min,max}_version to store wire
versions, rather than our internal normalized versions.
Change-Id: I282ed224806c41f69e6f166ca97c6cc05ff51f17
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35404
Reviewed-by: Nitish Sakhawalkar <nitsakh@gmail.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
With all those structures made opaque, it's not really useful as a build
sanity-check anymore.
Update-Note: This function is removed, but I don't see any actual uses.
Change-Id: Ib5640e778466da980596e7085d97104d22aa9d33
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35184
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Unfortunately, it's not enough to be able to turn it on thanks to the
PURE_VIRTUAL macro. But it gets us most of the way there.
Change-Id: Ie6ad5119fcfd420115fa49d7312f3586890244f4
Reviewed-on: https://boringssl-review.googlesource.com/c/34949
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
For now, this is off by default and controlled by SSL_set_enforce_rsa_key_usage.
This may be set as late as certificate verification so we may start by enforcing
it for known roots.
Generalizes ssl_cert_check_digital_signature_key_usage to check any part of the
key_usage, and adds a new error KEY_USAGE_BIT_INCORRECT for the generalized
method.
Bug: chromium:795089
Change-Id: Ifa504c321bec3263a4e74f2dc48513e3b895d3ee
Reviewed-on: https://boringssl-review.googlesource.com/c/34604
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
OpenSSL's EVP-level EC API involves a separate "paramgen" operation,
which is ultimately just a roundabout way to go from a NID to an
EC_GROUP. But Node uses this, and it's the pattern used within OpenSSL
these days, so this appears to be the official upstream recommendation.
Also add a #define for OPENSSL_EC_EXPLICIT_CURVE, because Node uses it,
but fail attempts to use it. Explicit curve encodings are forbidden by
RFC 5480 and generally a bad idea. (Parsing such keys back into OpenSSL
will cause it to lose the optimized path.)
Change-Id: I5e97080e77cf90fc149f6cf6f2cc4900f573fc64
Reviewed-on: https://boringssl-review.googlesource.com/c/34565
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This doesn't cover all the functions used by Node, but it's the easy
bits. (EVP_PKEY_paramgen will be done separately as its a non-trivial
bit of machinery.)
Change-Id: I6501e99f9239ffcdcc57b961ebe85d0ad3965549
Reviewed-on: https://boringssl-review.googlesource.com/c/34544
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
11.0.2 has since been released, but we are now aware of several more
bugs, so the workaround is unlikely to be removable for the foreseeable
future.
Change-Id: I8e7edcba2f002d0558a21e607306ddf9a205bfb3
Reviewed-on: https://boringssl-review.googlesource.com/c/34484
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
With HRSS-SXY, the sampling algorithm now longer has to be the same
between the two parties. Therefore we can change it at will (as long as
it remains reasonably uniform) and thus take the opportunity to make the
output distribution flatter.
Change-Id: I74c667fcf919fe11ddcf2f4fb8a540b5112268bf
Reviewed-on: https://boringssl-review.googlesource.com/c/34404
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
The first attempt involved using Linux's support for hardware
breakpoints to detect when assembly code was run. However, this doesn't
work with SDE, which is a problem.
This version has the assembly code update a global flags variable when
it's run, but only in non-FIPS and non-debug builds.
Update-Note: Assembly files now pay attention to the NDEBUG preprocessor
symbol. Ensure the build passes the symbol in. (If release builds fail
to link due to missing BORINGSSL_function_hit, this is the cause.)
Change-Id: I6b7ced442b7a77d0b4ae148b00c351f68af89a6e
Reviewed-on: https://boringssl-review.googlesource.com/c/33384
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Since |ssl_renegotiate_never| is the default, this option is moot.
However, OpenSSL defines and supports it so this helps code that wishes
to support both.
Change-Id: I3a2f6e93a078d39526d10f9cd0a990953bd45825
Reviewed-on: https://boringssl-review.googlesource.com/c/34384
Reviewed-by: Adam Langley <alangley@gmail.com>
Commit-Queue: Adam Langley <alangley@gmail.com>
This allows sharing SSL_CTX between TCP and QUIC connections, such that
common settings can be configured without having to duplicate the
context.
Change-Id: Ie920e7f2a772dd6c6c7b63fdac243914ac5b7b26
Reviewed-on: https://boringssl-review.googlesource.com/c/33904
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Steven Valdez