They will get very confused about which key they're using. Any caller
using exporters must either (a) leave renegotiation off or (b) be very
aware of when renegotiations happen anyway. (You need to somehow
coordinate with the peer about which epoch's exporter to use.)
Change-Id: I921ad01ac9bdc88f3fd0f8283757ce673a47ec75
Reviewed-on: https://boringssl-review.googlesource.com/12003
Reviewed-by: Adam Langley <agl@google.com>
The existing tests for this codepath require us to reconfigure the shim.
This will not work when TLS 1.3 cipher configuration is detached from
the old cipher language. It also doesn't hit codepaths like sessions
containing a TLS 1.3 version but TLS 1.2 cipher.
Instead, add some logic to the runner to rewrite tickets and build tests
out of that.
Change-Id: I57ac5d49c3069497ed9aaf430afc65c631014bf6
Reviewed-on: https://boringssl-review.googlesource.com/12024
Reviewed-by: Adam Langley <agl@google.com>
It is not ignored.
Change-Id: I2e607a6d6f7444838fc6fa65cd18e9aa142f139f
Reviewed-on: https://boringssl-review.googlesource.com/12023
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
HTTP/2 places requirements on the cipher suite. So that servers can
decline HTTP/2 when these requirements aren't met, defer ALPN
negotiation.
See also b/32553041.
Change-Id: Idbcf049f9c8bda06a8be52a0154fe76e84607268
Reviewed-on: https://boringssl-review.googlesource.com/11982
Reviewed-by: Adam Langley <agl@google.com>
We were only testing one side.
Change-Id: Ieb755e27b235aaf1317bd2c8e5fb374cb0ecfdb3
Reviewed-on: https://boringssl-review.googlesource.com/12001
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Change-Id: I87cbc12aeb399646c6426b7a099dbf13aafc2532
Reviewed-on: https://boringssl-review.googlesource.com/11983
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
d2i_X509_from_buffer parses an |X509| from a |CRYPTO_BUFFER| but ensures
that the |X509_CINF.enc| doesn't make a copy of the encoded
TBSCertificate. Rather the |X509| holds a reference to the given
|CRYPTO_BUFFER|.
Change-Id: I38a4e3d0ca69fc0fd0ef3e15b53181844080fcad
Reviewed-on: https://boringssl-review.googlesource.com/11920
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <alangley@gmail.com>
Commit-Queue: Adam Langley <alangley@gmail.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Trim a few more bytes from the future QUIC ClientHello.
Change-Id: If23c5cd078889a9a26cf2231b51b17c2615a38ea
Reviewed-on: https://boringssl-review.googlesource.com/12000
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Get some of the duplicate logic out of the way.
Change-Id: Iee7c64577e14d1ddfead7e1e32c42c5c9f2a310d
Reviewed-on: https://boringssl-review.googlesource.com/11981
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
TLS 1.3 also uses this extension and doesn't use any EC-based suites.
Always offering the extension is simpler. Also this gets an
SSL_get_ciphers call out of the way (that function is somewhat messy in
semantics).
Change-Id: I2091cb1046e0aea85caa76e73f50e8416e6ed94c
Reviewed-on: https://boringssl-review.googlesource.com/11980
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This change is based on interpreting TLS 1.3 draft 18.
Change-Id: I727961aff2f7318bcbbc8bf6d62b7d6ad3e62da9
Reviewed-on: https://boringssl-review.googlesource.com/11921
Reviewed-by: David Benjamin <davidben@google.com>
Bazel has moved their primary site to bazel.build.
(Thanks to Damien Martin-guillerez for the change.)
Change-Id: Ifb29dbb79f1e1d9611f40992a3e75e0fb5a3722a
Reviewed-on: https://boringssl-review.googlesource.com/11961
Reviewed-by: David Benjamin <davidben@google.com>
This should never happen, but the SSL_AEAD_CTX_new layer should enforce
key sizes as it's not locally obvious at the call site the caller didn't
get confused. There's still a mess of asserts below, but those should be
fixed by cutting the SSL_CIPHER/SSL_AEAD_CTX boundary differently.
(enc_key_len is validated by virtue of being passed into EVP_AEAD.)
BUG=chromium:659593
Change-Id: I8c91609bcef14ca1509c87aab981bbad6556975f
Reviewed-on: https://boringssl-review.googlesource.com/11940
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: I0aab9c94fcfa58b9cd46eaf716d9317f532f79a2
Reviewed-on: https://boringssl-review.googlesource.com/11850
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: Adam Langley <agl@google.com>
These were forward-declared for SSL3_STATE but with that hidden, it's no
longer necessary.
Change-Id: I8c548822f56f6172b4033b2fa89c038adcec2caa
Reviewed-on: https://boringssl-review.googlesource.com/11860
Reviewed-by: Adam Langley <agl@google.com>
Later work is going to cause some turbulence here.
Change-Id: Iba98bcf56e81492ec0dca54a381b38d1c115247a
Reviewed-on: https://boringssl-review.googlesource.com/11843
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Tagging non-pointer return types const doesn't do anything and makes
some compilers grumpy. Thanks to Daniel Hirche for the report.
Change-Id: I157ddefd8f7e604b4d8317ffa2caddb8f0dd89de
Reviewed-on: https://boringssl-review.googlesource.com/11849
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Neither branch of the |if| statement is expected to touch |data_len|.
Clarify this by moving |data_len| after the |if| statement.
Change-Id: Ibbc81e5b0c006882672df18442a6e7987064ca6d
Reviewed-on: https://boringssl-review.googlesource.com/11880
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This is still rather a mess with how it's tied to SSL_AEAD_CTX_new
(probably these should get encapsulated in an SSL_AEAD struct), but this
avoids running the TLS 1.3 nonce logic on fake AEADs. This is impossible
based on cipher version checks, but we shouldn't need to rely on it.
It's also a little tidier since out_mac_secret_len is purely a function
of algorithm_mac.
BUG=chromium:659593
Change-Id: Icc24d43c54a582bcd189d55958e2d232ca2db4dd
Reviewed-on: https://boringssl-review.googlesource.com/11842
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This patch changes the urandom PRNG to read one byte from the
getrandom(2) Linux syscall on initialization in order to find any
unexpected behavior.
Change-Id: I8ef676854dc361e4f77527b53d1a14fd14d449a8
Reviewed-on: https://boringssl-review.googlesource.com/8681
Reviewed-by: Adam Langley <alangley@gmail.com>
Commit-Queue: Adam Langley <alangley@gmail.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
These structures allow for blobs of data (e.g. certificates) to be
deduplicated in memory.
Change-Id: Iebfec90b85d55565848a178b6951562b4ccc083e
Reviewed-on: https://boringssl-review.googlesource.com/11820
Reviewed-by: Adam Langley <alangley@gmail.com>
Commit-Queue: Adam Langley <alangley@gmail.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This shouldn't happen, but it is good to check to avoid the potential
underflow in ssl_session_is_time_valid.
This required tweaking the mock clock in bssl_shim to stop going back in
time.
Change-Id: Id3ab8755139e989190d0b53d4bf90fe1ac203022
Reviewed-on: https://boringssl-review.googlesource.com/11841
Reviewed-by: David Benjamin <davidben@google.com>
BUG=chromium:659593
Change-Id: I73a4751609b85df7cd40f0f60dc3f3046a490940
Reviewed-on: https://boringssl-review.googlesource.com/11861
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
We currently preferentially sign the largest hash available and
advertise such a preference for signatures we accept. We're just as
happy with SHA-256 and, all else equal, a smaller hash would be epsilon
more performant. We also currently claim, in TLS 1.3, we prefer P-384
over P-256 which is off.
Instead order SHA-256 first, next the larger SHA-2 hashes, and leave
SHA-1 at the bottom. Within a hash, order ECDSA > RSA-PSS > RSA-PKCS1.
This has the added consequence that we will preferentially pair P-256
with SHA-256 in signatures we generate instead of larger hashes that get
truncated anyway.
Change-Id: If4aee068ba6829e8c0ef7948f56e67a5213e4c50
Reviewed-on: https://boringssl-review.googlesource.com/11821
Reviewed-by: Adam Langley <agl@google.com>
SSL_CTX_set1_curves was being called with the size of the input data in
bytes rather than in ints.
BUG=chromium:659361
Change-Id: I90da1c6d60e92423c6b7d9efd744ae70ff589172
Reviewed-on: https://boringssl-review.googlesource.com/11840
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
At some point, we'll forget to look in the commit message.
Change-Id: I3153aab679209f4f11f56cf3f883c4c74a17af1d
Reviewed-on: https://boringssl-review.googlesource.com/11800
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
clang-cl now supports enough of `#pragma intrinsic` that
it can use SecureZeroMemory() without an explicit intrin.h include.
This reverts https://boringssl-review.googlesource.com/#/c/8320/
BUG=chromium:592745
Change-Id: Ib766133f1713137bddd07654376a3b4888d4b0fb
Reviewed-on: https://boringssl-review.googlesource.com/11780
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
SSL_write has messy semantics around retries. As a sanity-check, it does
pointer and length checks and requires the original and retry SSL_write
pass the same buffer pointer.
In some cases, buffer addresses may change but still include the
original data as a prefix on the retry. Callers then set
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER to skip the pointer check. But, in
that case, the pointer may have been freed so doing a comparison is
undefined behavior.
Short-circuiting the pointer equality check avoids this problem.
Change-Id: I76cb8f7d45533504cd95287bc53897ca636af51d
Reviewed-on: https://boringssl-review.googlesource.com/11760
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
I missed these in the last round.
Change-Id: I9b47216eef87c662728e454670e9e516de71ca21
Reviewed-on: https://boringssl-review.googlesource.com/11740
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The EVP_PKEY attribute functions in x509.h are unimplemented.
Change-Id: Idcf2d81e58b04d0829d25567a145f87801a980d1
Reviewed-on: https://boringssl-review.googlesource.com/10343
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I51e5a7dac3ceffc41d3a7a57157a11258e65bc42
Reviewed-on: https://boringssl-review.googlesource.com/11721
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Unhandled critical CRL extensions were not detected if they appeared
after the handled ones. (Upstream GitHub issue 1757). Thanks to John
Chuah for reporting this.
(Imported from upstream's 3ade92e785bb3777c92332f88e23f6ce906ee260.)
This additionally adds a regression test for this issue, generated with
der-ascii. The signatures on the CRLs were repaired per notes in
https://github.com/google/der-ascii/blob/master/samples/certificates.md
Change-Id: I74a77f92710e6ef7f46dcde5cb6ae9350084ddcb
Reviewed-on: https://boringssl-review.googlesource.com/11720
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I4e61dc57d1ec65e892b1933f35663db164f017eb
Reviewed-on: https://boringssl-review.googlesource.com/11681
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
On the client we'll leave it off by default until the change has made it
through Chrome's release process. For TLS 1.3, there is no existing
breakage risk, so always do it. This saves us the trouble of having to
manually turn it on in servers.
See [0] for a data point of someone getting it wrong.
[0] https://hg.mozilla.org/projects/nss/rev/9dbc21b1c3cc
Change-Id: I74daad9e7efd2040e9d66d72d558b31f145e6c4c
Reviewed-on: https://boringssl-review.googlesource.com/11680
Reviewed-by: Adam Langley <agl@google.com>
It's possible that a BIO implementation could return a negative number
(say -1) for BIO_CTRL_PENDING or BIO_CTRL_WPENDING. Assert that this
doesn't happen and map it to zero if it happens anyway in NDEBUG builds.
Change-Id: Ie01214e80ff19acc1c7681a1125bbbf2038679c3
Reviewed-on: https://boringssl-review.googlesource.com/11700
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: Id41cf40b5087c6520c4d3c822d5a955b9fd32853
Reviewed-on: https://boringssl-review.googlesource.com/11684
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Nick Harper <nharper@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
Change-Id: I18cee423675d6a686f83b4ef4b38696cb618392c
Reviewed-on: https://boringssl-review.googlesource.com/11683
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Nick Harper <nharper@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
Change-Id: I0bd7fdd276e7461ef08b8055bf3d0387f756739f
Reviewed-on: https://boringssl-review.googlesource.com/11682
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
BUG=103
Change-Id: I9a49fbaf66af73978ce264d27926f483e1e44766
Reviewed-on: https://boringssl-review.googlesource.com/11620
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Channel ID for TLS 1.3 uses the same digest construction as
CertificateVerify. This message is signed with the Channel ID key and
put in the same handshake message (with the same format) as in TLS 1.2.
BUG=103
Change-Id: Ia5b2dffe5a39c39db0cecb0aa6bdc328e53accc2
Reviewed-on: https://boringssl-review.googlesource.com/11420
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Nodejs 6.9.0 calls this function.
Change-Id: I375f222cb819ebcb9fdce0a0d63df6817fa2dcae
Reviewed-on: https://boringssl-review.googlesource.com/11625
Commit-Queue: Adam Langley <alangley@gmail.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This code reportedly upsets VC++'s static analysis. Make it clear that,
yes, we want to count backwards.
Change-Id: I5caba219a2b87750d1a9d69b46d336a98c5824c9
Reviewed-on: https://boringssl-review.googlesource.com/11624
Commit-Queue: Adam Langley <alangley@gmail.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
{sha1, ecdsa} is virtually nonexistent. {sha512, ecdsa} is pointless
when we only accept P-256 and P-384. See Chromium Intent thread here:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/kWwLfeIQIBM/9chGZ40TCQAJ
This tweaks the signature algorithm logic slightly so that sign and
verify preferences are separate.
BUG=chromium:655318
Change-Id: I1097332600dcaa38e62e4dffa0194fb734c6df3f
Reviewed-on: https://boringssl-review.googlesource.com/11621
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Macros need a healthy dose of parentheses to avoid expression-level
misparses. Most of this comes from the clang-tidy CL here:
https://android-review.googlesource.com/c/235696/
Also switch most of the macros to use do { ... } while (0) to avoid all
the excessive comma operators and statement-level misparses.
Change-Id: I4c2ee51e347d2aa8c74a2d82de63838b03bbb0f9
Reviewed-on: https://boringssl-review.googlesource.com/11660
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
I missed this function, which was unfortunate.
Change-Id: I8bcea1738a50aa3297d09a59a86437351ff5f84a
Reviewed-on: https://boringssl-review.googlesource.com/11623
Commit-Queue: Adam Langley <alangley@gmail.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
Change-Id: I167d8ebfa7f2c08ba9f532df96ce5abd432c47c6
Reviewed-on: https://boringssl-review.googlesource.com/11622
Commit-Queue: Adam Langley <alangley@gmail.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
If SSL_CTX_set_signing_algorithm_prefs or
SSL_set_signing_algorithm_prefs are
called multiple times for the same cert, the
previous cert->sigalgs will leak.
Free the existing sigalgs before setting a new one.
Change-Id: I73cdb366a8f47d8cc0baae986fd0aa80b60300e2
Reviewed-on: https://boringssl-review.googlesource.com/11640
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
