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>
BUG=6
Change-Id: I463f5daa0bbf0f65269c52da25fa235ee2aa6ffb
Reviewed-on: https://boringssl-review.googlesource.com/11240
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
There were some logic errors that were revealed by testing at TLS 1.3.
Also explicitly test GetClientHelloLen at TLS 1.2 (rather than relying
on the default) since the TLS 1.3 ClientHello is too large.
Change-Id: I907cb6ac04b40f845e99593bad06739132ca56b2
Reviewed-on: https://boringssl-review.googlesource.com/11605
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 run with a few more arguments, we may as well pass them in.
Change-Id: Icd7196fc50983f77d500b96e0cc4f9bc583671bf
Reviewed-on: https://boringssl-review.googlesource.com/11603
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 have bool here. Also the comments were a mix of two styles.
Change-Id: I7eb6814b206efa960ae7e6e1abc14d64be6d61cf
Reviewed-on: https://boringssl-review.googlesource.com/11602
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>
This reverts commit 7b9bbd9639. This seems
to cause some problem linking with gold in Chromium:
../../third_party/binutils/Linux_x64/Release/bin/ld.gold: warning: Cannot export local symbol 'free'
../../third_party/binutils/Linux_x64/Release/bin/ld.gold: warning: Cannot export local symbol 'malloc'
../../third_party/binutils/Linux_x64/Release/bin/ld.gold: warning: Cannot export local symbol 'realloc'
../../third_party/binutils/Linux_x64/Release/bin/ld.gold: error: treating warnings as errors
The same error in https://crbug.com/368351 implies we're actually
causing the compiler to make some assumptions it shouldn't make. The
obvious fix of marking things as visible causes crashes when built with
ASan (ASan's malloc interceptors and ours are conflicting somehow).
Revert this for now. We should study how ASan's interceptors work and
figure out how to make these two coexist.
BUG=655938
Change-Id: Iaad245d1028c442bd924d46519b20115d37a57c4
Reviewed-on: https://boringssl-review.googlesource.com/11604
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>
Data allocated in one fuzzer iteration and then freed in the next
complicates the leak checker. Avoid this by dropping hidden global state
at the end of each run.
Change-Id: Ice79704f2754a6b1f40e288df9b97ddd5b3b97d5
Reviewed-on: https://boringssl-review.googlesource.com/11600
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I3476d3ba7cf90e023f6ad2ff9264a31c59a74e6a
Reviewed-on: https://boringssl-review.googlesource.com/11584
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Some new tests needed to be suppressed.
Change-Id: I4474d752c338a18440efb213e0795ae81ad754fb
Reviewed-on: https://boringssl-review.googlesource.com/11583
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This should land in the same group of revisions as the two parent
commits.
Change-Id: Id9d769b890b3308ea70b705e7241c73cb1930ede
Reviewed-on: https://boringssl-review.googlesource.com/11581
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
We'll never send cookies, but we'll echo them on request. Implement it
in runner as well and test.
BUG=98
Change-Id: Idd3799f1eaccd52ac42f5e2e5ae07c209318c270
Reviewed-on: https://boringssl-review.googlesource.com/11565
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This doesn't currently honor the required KeyUpdate response. That will
be done in a follow-up.
BUG=74
Change-Id: I750fc41278736cb24230303815e839c6f6967b6a
Reviewed-on: https://boringssl-review.googlesource.com/11412
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
They take a const pointer. See
http://llvm.org/docs/LibFuzzer.html#building
BUG=chromium:655016
Change-Id: Id6c7584c7a875e822b1fbff72163c888d02a9f44
Reviewed-on: https://boringssl-review.googlesource.com/11580
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>
These too must be rejected. Test both unknown extensions and extensions
in the wrong context.
Change-Id: I54d5a5060f9efc26e5e4d23a0bde3c0d4d302d09
Reviewed-on: https://boringssl-review.googlesource.com/11501
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>
This clears the last of Android's build warnings from BoringSSL. These
pragmas aren't actually no-ops, but it just means that MinGW consumers
(i.e. just Android) need to explicitly list the dependency (which they
do).
There may be something to be said for removing those and having everyone
list dependencies, but I don't really want to chase down every
consumer's build files. Probably not worth the trouble.
Change-Id: I8fcff954a6d5de9471f456db15c54a1b17cb937a
Reviewed-on: https://boringssl-review.googlesource.com/11573
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
MinGW has two different versions of printf. We want the format string
warnings to match. This silences some warnings in the Android build.
See:
https://sourceforge.net/p/mingw-w64/wiki2/gnu%20printf/
Note this assumes that, for external calls of these functions, the build
configuration of the consumer and BoringSSL match in this regard. (But
it doesn't actually matter because the issue is only on XP.)
Change-Id: I7f12ad2fc94130edd984feac5914f8ca6c88b8d4
Reviewed-on: https://boringssl-review.googlesource.com/11572
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
This was a remnant of the old cipher suite setup.
Change-Id: Ibc79b81200a52d45fbd69b9c04060c38ad4707f5
Reviewed-on: https://boringssl-review.googlesource.com/11564
Reviewed-by: David Benjamin <davidben@google.com>
This is part of TLS 1.3 draft 16 but isn't much of a wire format change,
so go ahead and add it now. When rolling into Chromium, we'll want to
add an entry to the error mapping.
Change-Id: I8fd7f461dca83b725a31ae19ef96c890d603ce53
Reviewed-on: https://boringssl-review.googlesource.com/11563
Reviewed-by: David Benjamin <davidben@google.com>
Change-Id: Id8099cc3a250e36e62b8a48e74706b75e5fa127c
Reviewed-on: https://boringssl-review.googlesource.com/11566
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We only save them at TLS 1.0 through 1.2. This saves 104 bytes of
per-connection memory.
Change-Id: If397bdc10e40f0194cba01024e0e9857d6b812f0
Reviewed-on: https://boringssl-review.googlesource.com/11571
Reviewed-by: Adam Langley <agl@google.com>
We need to retain a pair of Finished messages for renegotiation_info.
SSL 3.0's is actually larger than TLS 1.2's (always 12 bytes). Take
renegotiation out in preparation for trimming them to size.
Change-Id: I2e238c48aaf9be07dd696bc2a6af75e9b0ead299
Reviewed-on: https://boringssl-review.googlesource.com/11570
Reviewed-by: Adam Langley <agl@google.com>
We only need one copy, not two. This trims 130 bytes of per-connection
memory.
Change-Id: I334aa7b1f8608e72426986bfa68534d416f3bda9
Reviewed-on: https://boringssl-review.googlesource.com/11569
Reviewed-by: Adam Langley <agl@google.com>
tls-unique isn't defined at TLS 1.3 yet. (Given that it was too small in
1.2, they may just define a new one entirely?) SSL_get_(peer_)finished
doesn't work at 1.3 and is only used in lieu of computing tls-unique,
also undefined at SSL 3.0.
This is in preparation for trimming the copies of the Finished messages
we retain.
Change-Id: Iace99f2baea92c511c4041c592300dfbbe7226e2
Reviewed-on: https://boringssl-review.googlesource.com/11568
Reviewed-by: Adam Langley <agl@google.com>
SSL_HANDSHAKE is dropped after the handshake, so I've removed the logic
around smaller sizes. It's much simpler when we can use CBS_stow and
CBB_finish without extra bounds-checking.
Change-Id: Idafaa5d69e171aed9a8759f3d44e52cb01c40f39
Reviewed-on: https://boringssl-review.googlesource.com/11567
Reviewed-by: Adam Langley <agl@google.com>
