It's not even accurate. The term "master key" dates to SSL 2, which we
do not implement. (Starting SSL 3, "key" was replaced with "secret".)
The field stores, at various points, the TLS 1.2 master secret, the TLS
1.3 resumption master secret, and the TLS 1.3 resumption PSK. Simply
rename the field to 'secret', which is as descriptive of a name as we
can get at this point.
I've left SSL_SESSION_get_master_key alone for now, as it's there for
OpenSSL compatibility, as well as references to the various TLS secrets
since those refer to concepts in the spec. (When the dust settles a bit
on rfc8446bis, we can fix those.)
Change-Id: I3c1007eb7982788789cc5db851de8724c7f35baf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44144
Reviewed-by: Adam Langley <agl@google.com>
These APIs were used by Chromium to control the carve-out for the TLS
1.3 downgrade signal. As of
https://chromium-review.googlesource.com/c/chromium/src/+/2324170,
Chromium no longer uses them.
Update-Note: SSL_CTX_set_ignore_tls13_downgrade,
SSL_set_ignore_tls13_downgrade, and SSL_is_tls13_downgrade now do
nothing. Calls sites should be removed. (There are some copies of older
Chromium lying around, so I haven't removed the functions yet.) The
enforcement was already on by default, so this CL does not affect
callers that don't use those functions.
Change-Id: I016af8291cd92051472d239c4650602fe2a68f5b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44124
Reviewed-by: Adam Langley <agl@google.com>
I got that wrong. It passes ownership to the caller. It calls
X509_PUBKEY_get which bumps the refcount.
Change-Id: I46b7eabcf56f68bb1f745bc2f64091640e97c0bf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44084
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We have several implementations of this internally, so consolidate them.
Chromium also has a copy in net/der/parse_values.cc which could call
into this.
(I'm also hoping we can make c2i_ASN1_INTEGER call this and
further tighten up crypto/asn1's parser, but I see Chromium still has an
allow_invalid_serial_numbers option, so perhaps not quite yet.)
Update-Note: This CL does not change behavior, but I'm leaving a note to
myself to make net/der/parse_values.cc call the new functions.
Change-Id: If2aae6574ba6a30e343e1308da6af543616156ec
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44051
Reviewed-by: Adam Langley <agl@google.com>
This still needs some overall documentation describing ASN1_STRING's
relationship to all the other types, but start with the easy bits.
Change-Id: I968d4b1b3d57a9b543b3db489d14cf0789e30eb3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44049
Reviewed-by: Adam Langley <agl@google.com>
Not especially important, but leaving the input unchanged on malloc
failure is a little tidier.
Change-Id: Ia001260edcc8d75865d0d75ac0fe596205f83c48
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44048
Reviewed-by: Adam Langley <agl@google.com>
The free and dup macros are fine and can be replaced with their function
counterparts, but the new macros call ASN1_STRING_type_new with a
representative type in the CHOICE. This does not match what the
corresponding functions (e.g. ASN1_TIME_new) do.
The functions go through tasn_new.c and end up at ASN1_primitive_new.
That ends up creating an ASN1_STRING with type -1 and the
ASN1_STRING_FLAG_MSTRING flag set. X509_time_adj_ex uses the flag to
determine whether to trigger X.509's UTCTime vs GeneralizedTime
switching.
Confusingly, ASN1_TIME_adj, ASN1_UTCTIME_adj, and
ASN1_GENERALIZEDTIME_adj trigger this behavior based on the function
itself. That seems more robust (X509_set1_notBefore might accidentally
lose the flag), so maybe we can remove this flag. In the meantime, at
least remove the old macros so we don't create the wrong type.
Update-Note: Some M_ASN1 macros were removed. Code search says there
were no uses, and OpenSSL upstream removed all of them.
Change-Id: Iffa63f2624c38e64679207720c5ebd5241da644c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44047
Reviewed-by: Adam Langley <agl@google.com>
There is no ASN1_TIME_dup, so switch M_ASN1_TIME_dup to ASN1_STRING_dup
as upstream does. Switch M_ASN1_TIME_free to ASN1_TIME_free, also
matching upstream. This is a no-op, but less obviously so:
ASN1_TIME is an MSTRING defined in a_time.c. This defines an MSTRING
ASN1_ITEM. The new/free functions are then generated with
IMPLEMENT_ASN1_FUNCTIONS, which walks the ASN1_ITEM. ASN1_TIME_free then
goes through table-based free function, eventually running
ASN1_primitive_free, which calls ASN1_STRING_free on MSTRINGs.
Change-Id: I1765848a5301ecceeb74f91457351c969b741bb1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44046
Reviewed-by: Adam Langley <agl@google.com>
At one point in the SSLeay days, all the ASN1_STRING typedefs were
separate structs (but only in debug builds) and the M_ASN1_* macros
included type casts to handle this.
This is long gone, but we still have the M_ASN1_* macros. Remove the
casts and switch code within the library to call the macros. Some
subtleties:
- The "MSTRING" types (what OpenSSL calls its built-in CHOICEs
containing some set of string types) are weird because the M_FOO_new()
macro and the tasn_new.c FOO_new() function behave differently. I've
split those into a separate CL.
- ASN1_STRING_type, etc., call into the macro, which accesses the field
directly. This CL inverts the dependency.
- ASN1_INTEGER_new and ASN1_INTEGER_free, etc., are generated via
IMPLEMENT_ASN1_STRING_FUNCTIONS in tasn_typ.c. I've pointed
M_ASN1_INTEGER_new and M_ASN1_INTEGER_free to these fields. (The free
function is a no-op, but consistent.)
- The other macros like M_ASN1_BIT_STRING_dup largely do not have
corresponding functions. I've aligned with OpenSSL in just using the
generic ASN1_STRING_dup function. But some others, like
M_ASN1_OCTET_STRING_dup have a corresponding ASN1_OCTET_STRING_dup
function. OpenSSL retained these, so I have too.
Update-Note: Some external code uses the M_ASN1_* macros. This should
remain compatible, but some type errors may have gotten through
unnoticed. This CL restores type-checking.
Change-Id: I8656abc7d0f179192e05a852c97483c021ad9b20
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44045
Reviewed-by: Adam Langley <agl@google.com>
Some of the X509 functions are hard to document without first
documenting the ASN.1 types themselves. (ASN1_TYPE's goofy
representation is leaked everywhere.)
Change-Id: I0adcf055414925f9e39c8293cbd42d29f0db3143
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44044
Reviewed-by: Adam Langley <agl@google.com>
During the upstream review process a leading dot got removed by
accident. Missing this single character renders BoringSSL
Armv8.5-A BTI incompatible.
Also added two semicolons, just to be consistent.
Change-Id: I6c432d1c852129e9c273f6469a8b60e3983671ec
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44024
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
At the time, we hadn't taught clang-format how to handle STACK_OF
correctly.
Change-Id: Ia90c3bf443846a07eddaea5044b724027552ed30
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43964
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I77e08b88afa8a1f4e28449bf728eccc2c2f6f372
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43944
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
A few can be made static. Move the rest of asn1_locl.h.
Update-Note: Code search says these are unused. If someone's using them,
we can reexport them.
Change-Id: Ib41fd15792b59e7a1a41fa6b7ef5297dc19f3021
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43893
Reviewed-by: Adam Langley <agl@google.com>
This was used to register custom primitive types, namely some INTEGER
variations. We have since removed them all.
Change-Id: Id3f5b15058bc3be1cef5e0f989d2e7e6db392712
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43891
Reviewed-by: Adam Langley <agl@google.com>
Sadly we need to keep ASN1_put_eoc. Ruby uses it.
OpenSSL's PKCS#7 implementation generated an "ndef" variant of the
encoding functions, to request indefinite-length encoding. Remove the
support code for this.
Update-Note: Types that use one of the NDEF macros in asn1t.h will fail
to compile. This CL should not affect certificate parsing.
Change-Id: I6e03f6927ea4b7a6acd73ac58bf49512b39baab8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43889
Reviewed-by: Adam Langley <agl@google.com>
This is a remnant of an older incarnation of OpenSSL's ASN.1 code.
Update-Note: Types using IMPLEMENT_COMPAT_ASN1 from openssl/asn1t.h will
fail to compile. This CL should not affect certificate parsing.
Change-Id: I59e04f7ec219ae478119b77ce3f851a16b6c038f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43888
Reviewed-by: Adam Langley <agl@google.com>
This is never used. Remove the logic so we can gradually simply the
legacy ASN.1 code.
Update-Note: Types using ASN1_BROKEN_SEQUENCE from openssl/asn1t.h will
fail to compile. This CL should not affect certificate parsing.
Change-Id: I06b61ae2656a657aed81cd467051a494155b0963
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43887
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This entire function is assuming all the STACK_OF(T) types are secretly
the same type, but best to consistently use the sk_ASN1_VALUE_*
wrappers. The raw sk_foo functions are an implementation detail of the
macros and we probably should rename them to be better prefixed (as
upstream did).
Change-Id: I62d910b93ca6be5e1c83ae269c7df6a437ffb316
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43884
Reviewed-by: Adam Langley <agl@google.com>
The ACVP MCT tests involve a double loop where the inner loop iterates
1000 (AES) or 10000 (3DES) times. This change moves that inner loop
into the subprocess. This significantly reduces the amount of IPC
traffic at the cost of making the subprocesses more complex. The traffic
volume is unimportant when talking over a local pipe, but it's
significant when channels like serial links are used.
Change-Id: Ia9d51335f06b743791f7885d366c8fd2f0f7eaf6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43844
Commit-Queue: Adam Langley <alangley@gmail.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
x509_rsa_ctx_to_pss returns an error when trying to make an X509_ALGOR
for an arbitrary RSA-PSS salt length. This dates to the initial commit
and isn't in OpenSSL, so I imagine this was an attempt to ratchet down
on RSA-PSS parameter proliferation.
If the caller explicitly passes in md_size, rather than using the -1
convenience value, we currently fail. Allow those too and add an error
to the error queue so it is easier to diagnose.
Change-Id: Ia738142e48930ef5a916cad5326f15f64d766ba5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43824
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
These are a bit of a mess. Callers almost never handle the error
correctly.
Change-Id: I85ea6d4c03cca685f0be579459efb66fea996c9b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43804
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
When the handshaker fails to parse a config it currently exits. This
causes the two pipes to signal EOF to the shim, but the control channel
is a datagram socket in order to be atomic, thus doesn't signal an
error.
In the shim, EOF on the wfd pipe causes a short loop and thus a hang
forever. Catching the EOF and returning an error doesn't work because
some tests will close the pipe but still return information over the
control channel. We can start a timeout once wfd is closed, but that
seems like it might be flakey.
Thus this change makes the handshaker send an explicit error over the
control channel. It doesn't catch crashes, but it will catch config
errors, which are much more common in cross-version tests.
Change-Id: I4b1afed17694c57e4713d1b0fa4e9ecb12f09ec5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43865
Reviewed-by: David Benjamin <davidben@google.com>
In order to skip groups of tests in the cross-version testing (like
ALPS-*), it's useful to be able to match them by pattern.
Change-Id: Ic7e40c04a33b4bcbb08494fa04deb5e862f09d8f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43864
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
When generating a signature with some external signing process, the
caller needs to fill in the TBSCertificate (including the signature
algorithms), serialize the TBSCertificate, and then fill in the
signature.
We have i2d_re_X509_tbs (originally from CT I believe), but there are no
setters for the signature algorithms or the signature. Add
X509_set1_signature_algo, which mirrors upstream's
X509_REQ_set1_signature_algo, and X509_set1_signature_value, which is
new. Upstream has X509_REQ_set0_signature, but that requires the caller
manually assemble an ASN1_BIT_STRING. Taking the byte string seems less
error-prone.
Additionally, add i2d_X509_tbs and i2d_X509_CRL_tbs, for the non-"re"
variants of those APIs. Conscrypt needs to extract the TBS portion of a
certificate and a CRL, to implement X509Certificate.getTBSCertificate()
and X509CRL.getTBSCertList(). There, the aim is to get the data to
verify on an existing immutable certificate. OpenSSL has avoided
exporting the X509_CINF type, which I think is correct, so instead this
mirrors i2d_re_X509_tbs. (This does mean mirroring the confusing i2d
calling convention though.)
These new functions should unblock getting rid of a bunch of direct
struct accesses.
Later on, we should reorganize this header into immutable APIs for
verification and mutable APIs for generation. Even though we're stuck
the mistake of a common type for both use cases, I think splitting up
them up will let us rationalize the caches in the X509 objects a bit.
Change-Id: I96e6ab5cee3608e07b2ed7465c449a72ca10a393
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43784
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Chromium's VS toolchains now maintain JSON files with the expected
environment, so we don't need to pull in gyp to figure out the batch
file to run. This drops a long obsolete dependency and will make it
possible to handle other VS architectures. (gyp internally only handled
x86 and x64.)
Also trim away the logic in vs_toolchain.py to account for
non-depot_tools toolchains. Unlike Chromium, we don't use these scripts
outside of CI/CQ.
Change-Id: I2c9fddac52eef7b4895731d78c637fdcf9c85033
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43504
Reviewed-by: Adam Langley <agl@google.com>
For FIPS reasons, one might wish to ensure that a random AES-GCM nonce
was generated entirely within the FIPS module. If so, then these are the
AEADs for you.
Change-Id: Ic2b7864b089f446401f700d7d55bfa6336c61e23
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43686
Commit-Queue: Adam Langley <alangley@gmail.com>
Reviewed-by: David Benjamin <davidben@google.com>
We use this constant a lot in e_aes.c, but we write it out every time.
Change-Id: Iaa92efb391def6640349940c682d9f70ddaa23d5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43685
Reviewed-by: David Benjamin <davidben@google.com>
We already support this, but there wasn't a test for it.
Change-Id: I14304b99b312fcf729703cf175ec41e3e60db363
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43704
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
QUICHE has a switch-case converting ssl_early_data_reason_t to a string
for logging. This causes a lot of churn when we add a new value.
Instead, add a function for this. Bump BORINGSSL_API_VERSION so we can
easily land a CL in QUICHE to start using the function without
coordinating repositories.
Change-Id: I176ca07b4f75a3ea7153a387219459665062aad9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43724
Reviewed-by: Nick Harper <nharper@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
These booleans are a little hard to understand in context and adding
any more makes things even more complicated. Thus make them flags so
that the meaning is articulated locally.
Change-Id: I8cdb7fd5657bb12f28a73d7c6818d400c987ad3b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43684
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This is a looser reland of
https://boringssl-review.googlesource.com/c/boringssl/+/41804, which was
reverted in
https://boringssl-review.googlesource.com/c/boringssl/+/42804.
Enforcing that the ECDSA parameters were omitted rather than NULL hit
some compatibility issues, so instead allow either forms for now. To
align with the Chromium verifier, we'll probably want to later be
stricter with a quirks flag to allow the invalid form, and then add a
similar flag to Chromium. For now, at least try to reject the completely
invalid parameter values.
Update-Note: Some invalid certificates will now be rejected at
verification time. Parsing of certificates is unchanged.
Bug: b/167375496,342
Change-Id: I1cba44fd164660e82a7a27e26368609e2bf59955
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43664
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
David Benjamin
Tamas Petz
Adam Langley
Steven Valdez