Change-Id: Ie8216ab9de2edf37ae3240a5cb97d974e8252d93
Reviewed-on: https://boringssl-review.googlesource.com/17709
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>
Adding it to tlsVersions is sort of pointless when we don't test it.
Change-Id: Ie0c0167cef887aee54e5be90bf7fc98619c1a6fb
Reviewed-on: https://boringssl-review.googlesource.com/17708
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This isn't all of our pointer games by far, but for any code which
doesn't run on armv6, memcpy and pointer cast compile to the same code.
For code with does care about armv6 (do we care?), it'll need a bit more
work. armv6 makes memcpy into a function call.
Ironically, the one platform where C needs its alignment rules is the
one platform that makes it hard to honor C's alignment rules.
Change-Id: Ib9775aa4d9df9381995df8698bd11eb260aac58c
Reviewed-on: https://boringssl-review.googlesource.com/17707
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 tag doesn't actually do anything, except cause UBSan to point out
that malloc doesn't align that tightly. malloc does, however, appear to
align up to 16-bytes, which is the actual alignment requirement of that
code. So just replace 64 with 16.
When we're juggling less things, it'd be nice to see what toolchain
support for the various aligned allocators looks like. Or maybe someday
we can use C++ new which one hopes is smart enough to deal with all
this.
Change-Id: Idbdde66852d5dad25a044d4c68ffa3b3f213025a
Reviewed-on: https://boringssl-review.googlesource.com/17706
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>
This will require changes in downstream builds, but hopefully very
obvious ones (delete some code).
Bug: 129
Change-Id: Iedbae5d921d0c3979c340ed3106a63b6aa55f3bd
Reviewed-on: https://boringssl-review.googlesource.com/17670
Reviewed-by: Adam Langley <agl@google.com>
This is the last of the non-GTest tests. We never did end up writing
example files or doc.go tooling for them. And probably examples should
be in C++ at this point.
Bug: 129
Change-Id: Icbc43c9639cfed7423df20df1cdcb8c35f23fc1a
Reviewed-on: https://boringssl-review.googlesource.com/17669
Reviewed-by: Adam Langley <agl@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 deployment is currently blocked by buggy middleboxes
throughout the ecosystem. As an experiment to better understand these bugs
and the problems they are causing, implement TLS 1.3 variants with
alternate encodings. These are still the same protocol, only encoded
slightly differently. We will use what we learn from these experiments to
guide the TLS 1.3 deployment strategy and proposals to the IETF, if any.
These experiments only target the basic 1-RTT TLS 1.3 handshake. Based on
what we learn from this experiment, we may try future variations to
explore 0-RTT and HelloRetryRequest.
When enabled, the server supports all TLS 1.3 variants while the client
is configured to use a particular variant.
Change-Id: I532411d1abc41314dc76acce0246879b754b4c61
Reviewed-on: https://boringssl-review.googlesource.com/17327
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>
Not sure why it was expanded out like that.
Change-Id: I6899dbd23130ed7196c45c2784330b2a4fe9bdba
Reviewed-on: https://boringssl-review.googlesource.com/17666
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
This is a bit verbose, but this API is goofy and causes a lot of
confusion. This may be clearer.
Change-Id: I9affff99b838958058e56ee3062521421c9accc5
Reviewed-on: https://boringssl-review.googlesource.com/17645
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
For testing purposes.
Change-Id: Ied1b130e805bcf8cc5d1bd30a1ba5049d6f13a6d
Reviewed-on: https://boringssl-review.googlesource.com/17665
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Like other handshake properties, when in 0-RTT on the client,
SSL_version should report the predicted version. This used to work on
accident because of how ssl->version got set in handshake_client.c early
(and that TLS 1.4 does not exist), but we no longer do that.
Change-Id: Ifb63a22b795fe8964ac553844a46040acd5d7323
Reviewed-on: https://boringssl-review.googlesource.com/17664
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
We've got three versions of DATA_TOO_LARGE and two versions of
DATA_TOO_SMALL with no apparent distinction between them.
Change-Id: I18ca2cb71ffc31b04c8fd0be316c362da4d7daf9
Reviewed-on: https://boringssl-review.googlesource.com/17529
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>
When tree_calculate_user_set() fails, a jump to error failed to
deallocate a possibly allocated |auth_nodes|.
(Imported from upstream's 58314197b54cc1417cfa62d1987462f72a2559e0.)
Also sync up a couple of comments from that revision. Upstream's
reformat script mangled them and we never did the manual fixup.
Change-Id: I1ed896d13ec94d122d71df72af5a3be4eb0eb9d1
Reviewed-on: https://boringssl-review.googlesource.com/17644
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
-shim-config, not -shim-path.
Change-Id: I338085b5b5b533f9d511e1b9d82dc44d1161bd26
Reviewed-on: https://boringssl-review.googlesource.com/17604
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This adds sections on running CAVP tests, breaking FIPS tests and the
RNG design.
Change-Id: I859290e8e2e6ab087aa2b6570a30176b42b01073
Reviewed-on: https://boringssl-review.googlesource.com/17585
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I683481b12e66966729297466748f1869de0b913b
Reviewed-on: https://boringssl-review.googlesource.com/17584
Commit-Queue: Adam Langley <agl@google.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 would be unfamiliar to anyone coming from Chromium.
Change-Id: If9fbdbbadfd874c25dc6ff447ab4af36de0dcd22
Reviewed-on: https://boringssl-review.googlesource.com/17544
Reviewed-by: Adam Langley <agl@google.com>
We were missing AES256 and 3DES. Though this test dates to the old
record-splitting code which was much scarier than the new one.
Change-Id: Ia84a8c1a2bbd79fa70941f80cf6393013e4f13d5
Reviewed-on: https://boringssl-review.googlesource.com/17543
Reviewed-by: David Benjamin <davidben@google.com>
The in_group check is redundant and test an extremely absurd corner of
the syntax.
Change-Id: Ia54bcd7cda7ba05415d3a250ee93e1acedcc43d6
Reviewed-on: https://boringssl-review.googlesource.com/17542
Reviewed-by: David Benjamin <davidben@google.com>
This was a workaround for triple handshake put in way back, before
extended master secret.
Change-Id: Ie0112fa6323522b17c90a833d558f7182586d2c3
Reviewed-on: https://boringssl-review.googlesource.com/17541
Reviewed-by: David Benjamin <davidben@google.com>
Each of these cases should be rejected before we get to negotiating
anything. Save us a little bit of trouble.
Change-Id: I18cb66be1040dff7f25532da7e4c7d9c5ecd2748
Reviewed-on: https://boringssl-review.googlesource.com/17540
Reviewed-by: David Benjamin <davidben@google.com>
Also mirror the structure of the TLS 1.2 and TLS 1.3 code a bit.
Change-Id: I7b34bf30de63fa0bd47a39a90570846fb2314ad5
Reviewed-on: https://boringssl-review.googlesource.com/17539
Reviewed-by: David Benjamin <davidben@google.com>
We've never actually written tests for equipreference groups at the
BoringSSL level.
Change-Id: I571c081534efbfa8e7b84846fafed0b772721da1
Reviewed-on: https://boringssl-review.googlesource.com/17538
Reviewed-by: David Benjamin <davidben@google.com>
This function isn't used in TLS 1.3.
Change-Id: Icb6209396a36f243a84f0675b8f0c2435b08ad6c
Reviewed-on: https://boringssl-review.googlesource.com/17537
Reviewed-by: David Benjamin <davidben@google.com>
Change-Id: I90286da596d5822d4cfedf40995d80cf76adaf97
Reviewed-on: https://boringssl-review.googlesource.com/17536
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
These are re-recorded with the new fuzzer format.
Bug: 104
Change-Id: I00798f8f2026ae4570ffdcdae4a47999fd277212
Reviewed-on: https://boringssl-review.googlesource.com/17535
Reviewed-by: David Benjamin <davidben@google.com>
This was done by prepending each file with kDataTag, or 0x0000. This
causes them to behave as they did before the fuzzer updates.
Bug: 104
Change-Id: Ic768606911e1310fb59bed647990c237fe15776b
Reviewed-on: https://boringssl-review.googlesource.com/17534
Reviewed-by: David Benjamin <davidben@google.com>
So long as the code is there, it should be fuzzed.
Bug: 104
Change-Id: Iffaa832cc50c2d3c064eb511ba3a133d7f5758f2
Reviewed-on: https://boringssl-review.googlesource.com/17533
Reviewed-by: David Benjamin <davidben@google.com>
Otherwise the fuzzer gets stuck at renegotiations.
Bug: 104
Change-Id: If37f9ab165d06e37bfc5c423fba35edaabed293b
Reviewed-on: https://boringssl-review.googlesource.com/17532
Reviewed-by: David Benjamin <davidben@google.com>
This allows us to fill in holes in our fuzzer coverage, notably client
resumption (and thus early data) and server client certificates. The
corpora are not refreshed yet. This will be done in upcoming changes.
Also add an option for debugging fuzzers. It's very useful to test it on
transcripts and make sure that fuzzer mode successfully makes things
compatible.
Bug: 104
Change-Id: I02f0be4045d1baf68efc9a4157f573df1429575d
Reviewed-on: https://boringssl-review.googlesource.com/17531
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 has come up a few times and our docs aren't great. This hopefully
describes the sharp edges better.
Change-Id: I5d4044449f74ec116838fd1bba629cd90dc0d1ac
Reviewed-on: https://boringssl-review.googlesource.com/17504
Reviewed-by: Adam Langley <agl@google.com>
This imports bf5b8ff17dd7039b15cbc6468cd865cbc219581d and
a696708ae6bbe42f409748b3e31bb2f3034edbf3 from upstream. I missed them at
some point.
Change-Id: I882d995868e4c0461b7ca51a854691cf4faa7260
Reviewed-on: https://boringssl-review.googlesource.com/17384
Reviewed-by: Adam Langley <agl@google.com>
Once passed to the outside world, an SSL_SESSION is immutable. It is not
thread-safe to set not_resumable. In most cases, the session is already
expired anyway. In other cases, making all this remove session be unlink rather than
destroy is sound and consistent with how we treat sessions elsewhere.
In particular, SSL_CTX_free calls SSL_CTX_flush_sessions(0), and
bulk-invalidating everything like this is interfering with some
follow-up changes to improve the fuzzer.
Change-Id: I2a19b8ce32d9effc1efaa72e934e015ebbbfbf9a
Reviewed-on: https://boringssl-review.googlesource.com/17530
Reviewed-by: David Benjamin <davidben@google.com>
This is in preparation for supporting multiple TLS 1.3 variants.
Change-Id: Ia2caf984f576f1b9e5915bdaf6ff952c8be10417
Reviewed-on: https://boringssl-review.googlesource.com/17526
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
SSL_set_max_proto_version(TLS1_3_DRAFT_VERSION) worked unintentionally.
Fix that. Also add an error when it fails.
Change-Id: I1048fede7b163e1c170e17bf4370b468221a7077
Reviewed-on: https://boringssl-review.googlesource.com/17525
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 is in preparation for upcoming experiments which will require
supporting multiple experimental versions of TLS 1.3 with, on the
server, the ability to enable multiple variants at once. This means the
version <-> wire bijection no longer exists, even when limiting to a
single SSL*. Thus version_to_wire is removed and instead we treat the
wire version as the canonical version value.
There is a mapping from valid wire versions to protocol versions which
describe the high-level handshake protocol in use. This mapping is not
injective, so uses of version_from_wire are rewritten differently.
All the version-munging logic is moved to ssl_versions.c with a master
preference list of all TLS and DTLS versions. The legacy version
negotiation is converted to the new scheme. The version lists and
negotiation are driven by the preference lists and a
ssl_supports_version API.
To simplify the mess around SSL_SESSION and versions, version_from_wire
is now DTLS/TLS-agnostic, with any filtering being done by
ssl_supports_version. This is screwy but allows parsing SSL_SESSIONs to
sanity-check it and reject all bogus versions in SSL_SESSION. This
reduces a mess of error cases.
As part of this, the weird logic where ssl->version is set early when
sending the ClientHello is removed. The one place where we were relying
on this behavior is tweaked to query hs->max_version instead.
Change-Id: Ic91b348481ceba94d9ae06d6781187c11adc15b0
Reviewed-on: https://boringssl-review.googlesource.com/17524
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Change-Id: I819a5b565e4380f3d816a2e4a68572935c612eae
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Reviewed-on: https://boringssl-review.googlesource.com/17564
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>
Also document what versions of everything we're using as the .sha1 files
don't say.
Change-Id: I2d496c86761f6df6acd20e1af62094b7d89e5c1d
Reviewed-on: https://boringssl-review.googlesource.com/17485
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
efa4339adde7e627370ed7c46ed00fed5d23310007ef0334ae17510d00e22b8d sde-external-8.5.0-2017-06-08-lin.tar.bz2
Change-Id: I201ca78cbbb3c769ed45705f87b6013758b68349
Reviewed-on: https://boringssl-review.googlesource.com/17484
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
When testing against a browser, multiple connections will be made in
parallel. Keeping the same listening socket lets the other connections
queue up at least rather than fail with ECONNREFUSED. Of course, this is
still far from a realistic server.
Change-Id: I984fb29da4bf8808eb40938b12782dc1730f2e19
Reviewed-on: https://boringssl-review.googlesource.com/17405
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
The __clang__-guarded #defines cause gas to complain if clang is passed
-fno-integrated-as. Emitting .syntax unified when those are used fixes
this. This matches the change made to ghash-armv4.pl in upstream's
6cf412c473d8145562b76219ce3da73b201b3255.
See also https://github.com/openssl/openssl/pull/3694. This fixes the
build with the latest Android NDK (use the NDK-supplied toolchain file)
with the armeabi ABI.
Bug: chromium:732066
Change-Id: Ic6ca633a58edbe8ae8c7d501bd9515c2476fd7c2
Reviewed-on: https://boringssl-review.googlesource.com/17404
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
There's a |tag_len| in the generic AEAD context now so keeping a second
copy only invites confusion.
Change-Id: I029d8a8ee366e3af7f61408177c950d5b1a740a9
Reviewed-on: https://boringssl-review.googlesource.com/17424
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Like the write half, rather than allocating the maximum size needed and
relying on the malloc implementation to pool this sanely, allocate the
size the TLS record-layer code believes it needs.
As currently arranged, this will cause us to alternate from a small
allocation (for the record header) and then an allocation sized to the
record itself. Windows is reportedly bad at pooling large allocations,
so, *if the server sends us smaller records*, this will avoid hitting
the problem cases.
If the server sends us size 16k records, the maximum allowed by ther
protocol, we simply must buffer up to that amount and will continue to
allocate similar sizes as before (although slightly smaller; this CL
also fixes small double-counting we did on the allocation sizes).
Separately, we'll gather some metrics in Chromium to see what common
record sizes are to determine if this optimization is sufficient. This
is intended as an easy optimization we can do now, in advance of ongoing
work to fix the extra layer of buffering between Chromium and BoringSSL
with an in-place decrypt API.
Bug: chromium:524258
Change-Id: I233df29df1212154c49fee4285ccc37be12f81dc
Reviewed-on: https://boringssl-review.googlesource.com/17329
Reviewed-by: Adam Langley <agl@google.com>
