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>
x509_req.c changes imported from upstream's
9b0a453190efc9b14cc04e74ce2e8e35af45fb39.
Update-Note: Direct accesses of X509_ATTRIBUTE should be replaced with
one of the accessors. I couldn't find any direct accesses, so hopefully
this is fine.
Change-Id: I7eab6375d5dcf366ef72e5ce059f3558c947f35b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46946
Reviewed-by: Adam Langley <agl@google.com>
I stopped short of documenting the add1_attr_by functions because the
type parameter is a bit of a mess. It appears to be several enums put
together. To that end, I've updated the documentation on
V_ASN1_MAX_UNIVERSAL to note that we also need to avoid MBSTRING_FLAG.
As a preview of what I'm putting off to later, see
X509_ATTRIBUTE_set1_data for how the type parameter is used. set1_data
is extra fun because PKCS#10 attributes are set-valued. Plus there's
upstream's e20b57270dece66ce2c68aeb5d14dd6d9f3c5d68, which we should
import first.
Change-Id: I3453a0b224e42c6e22828c7d332ee133e09e6173
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46945
Reviewed-by: Adam Langley <agl@google.com>
Update-Note: Direct accesses of X509_PUBKEY should be replaced with one
of the accessors. I believe all callers have been fixed at this point.
Change-Id: Ib325782867478fb548da1bf5ef0023cf989f125b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46944
Reviewed-by: Adam Langley <agl@google.com>
See go/handshake-hints (internal).
CL originally by Bin Wu <wub@google.com>. I just reworked the tests and
tidied it up a bit. This is the start of a replacement for the split
handshakes API. For now, only TLS 1.3 is supported. It starts with an
initial set of hints, but we can add more later. (In particular, we
should probably apply the remote handshaker's extension order to avoid
needing to capability protect such changes.)
Change-Id: I7b6a6dfaa84c6c6e3436d2a4026c3652b8a79f0f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46535
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
See also 86a90dc749af91f8a7b8da6628c9ffca2bae3009 from upstream. This
differs from upstream's which treats {NULL, 2} as a valid way to spell
the empty list. (I think this is a mistake and have asked them about
it.)
Upstream's CL also, for them, newly makes the empty list disable ALPN,
when previously they'd disable it but misread it as a malloc failure.
For us, we'd already fixed the misreading due to our switch to
bssl::Array and bssl::Span, but the documentation was odd. This CL
preserves that behavior, but updates the documentation and writes a
test.
Update-Note: SSL_CTX_set_alpn_protos and SSL_set_alpn_protos will now
reject invalud inputs. Previously, they would accept them, but silently
send an invalid ALPN extension which the server would almost certainly
error on.
Change-Id: Id5830b2d8c3a5cee4712878fe92ee350c4914367
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46804
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>
PKCS#10 CSRs don't contain extensions but attributes, which are kind of
like extensions, but defined separately. There is an attribute type from
PKCS#9 to embed a list of X.509 extensions inside an attribute, as well
as a Microsoft variant.
X509_REQ_set_extension_nids allowed callers globally reconfigure the set
of attributes recognized as aliases of this extensions attribute. This
is not used by anyone and not thread-safe. Remove it and only support
the two default attribute types.
From there, document the remaining functions.
Update-Note: This removes a pair of unused functions.
Change-Id: Ic1fc41163996c0c980ba8320b417e444d484aa39
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46326
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
One thing of note is the name setters are copying, not
ownership-transfering. They're non-const because currently even
serializing or duplicating a X509_NAME potentially mutates it (ugh).
Change-Id: I5265ea54c776cd9f6bed86870d0505fa3e16c794
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46325
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This fixes a bug in ASN1_TYPE_get. Partly imported from upstream's
261ec72d58af64327214a78ca1c54b169ad93c28, though I don't believe
ASN1_TYPE_set was broken per se. There's also a lot more than in that
commit.
I've added a test to ensure we maintain the unused bits invariant
anyway, in case external code relies on it. (The invariant comes from
the pointer being NULL-initialized and from ASN1_primitive_free zeroing
*pval on free.)
Change-Id: I4c0c57519a7628041d81c26cd850317e01409556
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46324
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This API does not come from OpenSSL, but OpenSSL does not appear to have
any way to get this information. There is X509_get0_pubkey_bitstr, but
that only works for X509 objects, not X509_PUBKEY.
Change-Id: Ifc8be554a4d8cbf830c32b95b953f092980804df
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46304
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This reverts commit a3437c09c7. There was
a miscommunication and it does not seem like we currently need this. If
that changes later, it's in Git and we can bring it back easily.
Change-Id: Ibbce29df2258a2d893d725ab3ee6fd78c5b6cb00
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46286
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
In doing so, this switches make_errors.go to take library names as
parameters rather than detecting it from the CWD. (I considered
detecting it, but then we'd need to map evp -> crypto/whatever and
crypto/whatever -> evp in both directions.)
Since crypto/hpke currently sits in the EVP namespace, I've gone ahead
and added that, so it should be easier to define new errors in
crypto/hpke. I've not added crypto/cipher, etc., yet. Moving those will
be a breaking change (consumers that put ERR_LIB_CIPHER and ERR_LIB_EVP
in a switch/case need patches).
Bug: 398
Change-Id: Ibae2afd46e076891fa517c377b540b2e492516f0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46264
Reviewed-by: Adam Langley <agl@google.com>
See draft-davidben-tls13-pkcs1-00. The code point is disabled by default
and must be configured in SSL_set_verify_algorithm_prefs and
SSL_set_signing_algorithm_prefs. It is also only defined for TLS 1.3
client certificates and otherwise ignored.
This required reworking the tests a bit since this is the first
signature algorithm that's disabled by default, and the first algorithm
that behaves differently between client and server.
Change-Id: Iac4aa96a4963cbc33688c252e958a572c5c3b511
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46187
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
When it is and isn't safe to assume an X509 field is non-NULL seems to
cause some confusion. (I often get requests to add NULL checks when
rewriting calling code.)
X.509 has surprisingly few optional fields, and we generally say
pointers are non-NULL unless documented. But that only works if we
remember to mention the nullable ones.
Change-Id: I18b57a17c9d57c377ea2227347e423f574389818
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46185
Reviewed-by: Adam Langley <agl@google.com>
The representation here is a bit more messy than necessary. In doing so,
clean up the variable names and smooth away two rough edges:
- X509_ALGOR_get0 would leave *out_param_value uninitialized if
*out_param_type is V_ASN1_UNDEF. Instead, set it to NULL, so callers
do not accidentally use an uninitialized pointer.
- X509_PUBKEY_set0_param, if key is NULL, would leave the key alone. No
one calls this function externally and none of the (since removed)
callers in OpenSSL rely on this behavior. A NULL check here adds a
discontinuity at the empty string that seems unnecessary here:
changing the algorithm without changing the key isn't useful.
(Note the API doesn't support changing the key without the algorithm.)
Note for reviewing: the representation of ASN1_TYPE is specified
somewhat indirectly. ASN1_TYPE uses the ASN1_ANY ASN1_ITEM, which has
utype V_ASN1_ANY. Then you look at asn1_d2i_ex_primitive and asn1_ex_c2i
which peel off the ASN1_TYPE layer and parse directly into the value
field, with a fixup for NULL. Hopefully we can rework this someday...
Change-Id: I628c4e20f8ea2fd036132242337f4dcac5ba5015
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46165
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
In order to provide evidence to auditors that high-level functions end
up calling into the FIPS module, provide counters that allow for such
monitoring.
Change-Id: I55d45299f3050bf58077715ffa280210db156116
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46124
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
ASN1_OBJECTs are awkward. Sometimes they are static, when returned from
OBJ_nid2obj, and sometimes they are dynamic, when parsed from
crypto/asn1.
Most structures in crypto/asn1 need to support unknown OIDs and thus
must own their ASN1_OBJECTs. But they also may be initialized with
static ones in various APIs, such as X509_ALGOR_set0. To make that work,
ASN1_OBJECT_free detects static ASN1_OBJECTs and is a no-op.
Functions like X509_ALGOR_set0 take ownership, so OpenSSL has them take
a non-const ASN1_OBJECT*. To match, OBJ_nid2obj then returns a non-const
ASN1_OBJECT*, to signal that it is freeable.
However, this means OBJ_nid2obj's mutability doesn't match its return
type. In the fork, we switched OBJ_nid2obj to return const. But, in
doing so, we had to make X509_ALGOR_set0 and X509_PUBKEY_set0_param take
const ASN1_OBJECT, even though they would actually take ownership of
dynamic ASN1_OBJECTs. There are also a few internal casts with a TODO to
be const-correct.
Neither situation is ideal. (Perhaps a more sound model would be to copy
static ASN1_OBJECTs before putting them in most structs. But that would
not match current usage.) But I think aligning with OpenSSL is the
lesser evil here, since it avoids misleading set0 functions. Managing
ownership of ASN1_OBJECTs is much more common than mutating them. To
that end, I've added a note that ASN1_OBJECTs you didn't create must be
assumed immutable[*].
Update-Note: The change to OBJ_nid2obj should be compatible. The changes
to X509_PUBKEY_set0_param and X509_ALGOR_set0 may require fixing some
pointer types.
[*] This is *almost* honored by all of our functions. The exception is
c2i_ASN1_OBJECT, which instead checks the DYNAMIC flag as part of the
object reuse business. This would come up if we ever embedded
ASN1_OBJECTs directly in structs.
Change-Id: I1e6c700645c12b43323dd3887adb74e795c285b9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46164
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This will also pull in POLICY_MAPPINGS by way of STACK_OF(T) handling.
Change-Id: I8ddc9547647f8cae3800047eb58e1c83f6ae1085
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46104
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This is to help with cryptography.io compatibility. We don't implement
any of the flags (PKCS7_sign checks flags == PKCS7_DETACHED), but
cryptography.io now depends on the constant and PKCS7_SIGNER_INFO type
being available.
(cryptography.io also wants some new functions, but I think it's easier
to stub those out externally for now. If we need to actually enable
those features, we can look at actually implementing more of
PKCS7_sign.)
Change-Id: Id8419e34a68c04d4894417c7d6b13c1952d0bb88
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46084
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
OpenSSL classified their behavior as a bug and are fixing it for the
next release. In principle it'd be more compatible to emulate OpenSSL's
bug and undo it when we update OPENSSL_VERSION_NUMBER, but use of
PKCS12_parse is rare and this behavior is confusing, so let's leave it
as-is.
Bug: 250
Change-Id: I5f9825490a8afde67272dfaf476b35dbde94b59c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46064
Reviewed-by: Adam Langley <agl@google.com>
We aim to eventually make the entire X509 structure opaque, but let's
start small.
Update-Note: I believe this is now safe to do. If there are compile
failures, switch to X509_get0_notBefore, X509_getm_notBefore, and
X509_set1_notBefore, or revert this if I'm wrong and too many callers
still need updating.
Change-Id: I6e9d91630a10ac777e13ebcdeb543b3cbeea6383
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45965
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
PKCS#12 is overly general and, among other things, supports disabling
encryption. In practice, the unencrypted form is not widely implemented.
Moreover, even in contexts where cleartext is fine, an unencrypted
PKCS#12 file still requires a password for the mandatory MAC component.
They're not very useful.
However, cryptography.io uses them. Previously, we added support for
parsing these. This CL adds support for creating them too, because now
cryptography.io now also depends on that.
Change-Id: Ib7c4e29615047b6c73f887fea7c80f8844999bb7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46045
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Update-Note: This removes a function that appears to be unused. It also
hardcodes the use of MD5, so please do not use it.
Change-Id: I67909c6360e4737fc22742592f88b907eb818e96
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45964
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
I got the values flipped around. Also cryptography.io wants
EC_GROUP_get_asn1_flag to check a curve's encoding. We (mostly) only
support named curves, so just return OPENSSL_EC_NAMED_CURVE.
Change-Id: I544e76b7380ecd8dceb1df3db4dd4cf5cb322352
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46024
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This improves compatibility with cryptography.io. cryptography.io
doesn't actually care what we return, since the code won't run, but
feigning success seems better than failure. If some application does try
to run this function and checks, returning an error will probably crash
it.
Change-Id: I7a8164753a2f1a7b31dbeb10c7030c5e5fea2bc9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46004
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Per RFC5280, section 5.1.1.2,
[signatureAlgorithm] MUST contain the same algorithm identifier as the
signature field in the sequence tbsCertList (Section 5.1.2.2).
This aligns with a check we already do on the X.509 side.
Update-Note: Invalid CRLs with inconsistent inner and outer signature
algorithms will now be rejected.
Change-Id: I9ef495a9b26779399c932903871391aacd8f2618
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45946
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This may as well be computed from block_size. This reduces the
per-EVP_CIPHER_CTX memory usage slightly.
Update-Note: It doesn't look like anyone is reading into this field. If
they are, we can ideally fix it, or revert this if absolutely necessary.
Change-Id: Ieef9177bed1671efca23d4f94d3d528f82568fc6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45884
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Get the up_ref functions and signature accessors.
Change-Id: Ie12e3a48ccc7e4c165ba08001232f5453e3dca11
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45945
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The X509 version APIs confuse everyone, including our own tests
(v3name_test.cc was using the wrong value). Introduce constants. Also
document which version to use for each type. It is extra confusing that,
although certificates and CRLs use the same Version enum, RFC5280
defines X.509 v3 certificates with X.509 v2 CRLs. (There are no v3
CRLs.)
I'll send a similar patch to OpenSSL to keep upstream aligned.
Change-Id: If096138eb004156d43df87a6d74f695b04f67480
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45944
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Change-Id: I85f0364b83440469c0d15c32dd96607be31fc1b7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45904
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
There are a few places where it is useful to run ECDSA with a specified
nonce:
- An ECDSA KAT in the module self-check
- Unit tests for particular test vectors
- Fuzzing the implementation (requested by the cryptofuzz project)
This replaces the fixed_k machinery with a separate function. Although
they are effectively the same, I've used two different functions.
One is internal and only used in the module self-check. The other is
exported for unit tests and cryptofuzz but marked with a for_testing.
(Chromium's presubmits flag uses of "for_testing" functions outside of
unit tests. The KAT version isn't in a test per se, so it's a separate
function.)
Bug: 391
Change-Id: I0f764d89bf0ac2081307e1079623d508fb0f2df7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45867
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CVE-2021-23840
(Imported from upstream's 6a51b9e1d0cf0bf8515f7201b68fb0a3482b3dc1.)
This differs slightly from upstream's version:
- EVP_R_OUTPUT_WOULD_OVERFLOW didn't seem necessary when ERR_R_OVERFLOW
already exists. (Also since we use CIPHER_R_*, it wouldn't have helped
with compatibility anyway. Though there's probably something to be
said for us folding CIPHER_R_* back into EVP_R_*.)
- For simplicity, just check in_len + bl at the top, rather than trying
to predict the exact number of bytes written.
Update-Note: Passing extremely large input lengths into EVP_CipherUpdate
will now fail. Use EVP_AEAD instead, which is size_t-based and has more
explicit output bounds.
Change-Id: I31835c89dcdecb6b112828f57deb798dc7187db5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45685
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Update-Note: No one uses this function. It had a NULL dereference in
some error cases. See CVE-2021-23841.
Change-Id: Ie1cc97615ac8b674147715d7d62e62faf218ae65
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45684
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This aligns with OpenSSL's behavior. RFC7301 says servers should return
no_application_protocol if the client supported ALPN but no common
protocol was found. We currently interpret all values as
SSL_TLSEXT_ERR_NOACK. Instead, implement both modes and give guidance on
whne to use each. (NOACK is still useful because the callback may be
shared across multiple configurations, some of which don't support ALPN
at all. Those would want to return NOACK to ignore the list.)
To match upstream, I've also switched SSL_R_MISSING_ALPN, added for
QUIC, to SSL_R_NO_APPLICATION_PROTOCOL.
Update-Note: Callers that return SSL_TLSEXT_ERR_ALERT_FATAL from the
ALPN callback will change behavior. The old behavior may be restored by
returning SSL_TLSEXT_ERR_NOACK, though see the documentation for new
recommendations on return values.
Change-Id: Ib7917b5f8a098571bed764c79aa7a4ce0f728297
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45504
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This is largely some cleanup so the three features follow the same
patterns and is hopefully cleaner (no more separate static and
non-static paths). The practical impact is probably nil. (Linux-based
ARM builds with crypto extensions as a baseline, if any exist, save
binary size.)
Change-Id: I2214b1a54e2074024b8eeb51799a08b94646cbf3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45485
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
When a feature is enabled statically in the build config, the compiler
defines __ARM_NEON and also considers itself free to emit NEON code.
In this case, there is no need to check for NEON support at runtime
since the binary will not work without NEON anyway. Moving the check to
compile time lets us drop unused code.
Chrome has required NEON on Android for nearly five years now. However,
historically there was a bad CPU which broke on some NEON code, but not
others. See https://crbug.com/341598 and https://crbug.com/606629. We
worked around that CPU by parsing /proc/cpuinfo and intentionally
dropping the optimization. This is not a stable situation, however, as
we're hoping the compiler is not good enough at emitting NEON to trigger
this bug.
Since then, the number of affected devices has dropped, and Chrome has
raised the minimum Android requirement to L. The Net.HasBrokenNEON
metric from Chrome is now well in the noise.
This CL stops short of removing the workaround altogether because some
consumers of Cronet are unsure whether they needed this workaround.
Those consumers also build without __ARM_NEON, so gating on that works
out. We'll decide what to do with it pending metrics from them.
Update-Note: Builds with __ARM_NEON (-mfpu=neon) will now drop about
30KiB of dead code, but no longer work (if they even did before) on a
particular buggy CPU. Builds without __ARM_NEON are not affected.
Change-Id: Id8f7bccfb75afe0a1594572ea20c51d275b0a256
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45484
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
test_fips probably needs to exercise everything that we have self-tests
for.
(The following change will eliminate the duplication of the code to
create the FFDH group. For reasons, that can't be done in this change.)
Change-Id: Ia72064db77381e7cf396a34b4723b2607f26f00b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45404
Reviewed-by: Adam Langley <alangley@gmail.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Our use-case for this does not require optimisation at the current time,
so a clean C implementation is fine.
Change-Id: I8f29572c33e8dbcc37961c099c71c14aafc8d0a3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45164
Reviewed-by: David Benjamin <davidben@google.com>
QUICHE currently does not know to call
SSL_set_quic_use_legacy_codepoint, picking up the current default of the
legacy code point. It then assumes that the
TLSEXT_TYPE_quic_transport_parameters constant may be used to extract
transport parameters, so after
https://boringssl-review.googlesource.com/c/boringssl/+/44704, it
breaks.
To smooth over the transition, we now define three constants:
TLSEXT_TYPE_quic_transport_parameters_legacy,
TLSEXT_TYPE_quic_transport_parameters_standard, and the old constant.
The old constant will match whatever the default is (for now, legacy) so
the default is self-consistent. Then plan is then:
1. BoringSSL switches to the state in this CL: the default code point
and constant are the legacy one, but there are APIs to specify the
code point. This will not affect QUICHE, which only uses the
defaults.
2. QUICHE calls SSL_set_quic_use_legacy_codepoint and uses the
corresponding _legacy or _standard constant. It should *not* use the
unsuffixed constant at this point.
3. BoringSSL switches the default setting and the constant to the
standard code point. This will not affect QUICHE, which explicitly
configures the code point it wants.
4. Optional: BoringSSL won't switch the default back to legacy, so
QUICHE can switch _standard to unsuffixed and BoringSSL
can remove the _standard alias (but not the function) early.
5. When QUICHE no longer needs both code points, it unwinds the
SSL_set_quic_use_legacy_codepoint code and switches back to the
unsuffixed constant.
6. BoringSSL removes all this scaffolding now that it's no longer
needed.
Update-Note: This this fixes a compatibility issue with
https://boringssl-review.googlesource.com/c/boringssl/+/44704.
Change-Id: I9f75845aba58ba93e9665cd6f05bcd080eb5f139
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45124
Reviewed-by: David Schinazi <dschinazi@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
OpenSSL has a fixed-width version of DH_compute_key nowadays. Searching
around callers of DH_compute_key, many of them go back and re-pad the
secret anyway. Uses of DH should migrate to modern primitives but, in
the meantime, DH_compute_key_padded seems worthwhile for OpenSSL
compatibility and giving fixed-width users a function to avoid the
timing leak.
Bump BORINGSSL_API_VERSION since one of the uses is in wpa_supplicant
and they like to compile against a wide range of Android revisions.
Update-Note: No compatibility impact, but callers that use
DH_compute_key and then fix up the removed leading zeros can switch to
this function. Then they should migrate to something else.
Change-Id: Icf8b2ace3972fa174a0f08ece39710f7599f96f2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45004
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
David Benjamin
Daniel McArdle
Adam Langley
Bradley Hess
Adam Langley
Yuchen Dai