Similarly, add EVP_AEAD_CTX_tag_len which computes the exact tag length
for required by EVP_AEAD_CTX_seal_scatter.
Change-Id: I069b0ad16fab314fd42f6048a3c1dc45e8376f7f
Reviewed-on: https://boringssl-review.googlesource.com/18324
Reviewed-by: Adam Langley <agl@google.com>
I'm not that fast when debugging.
Change-Id: I37a120a77e9a35ac5255ad760513b983f83d9bd7
Reviewed-on: https://boringssl-review.googlesource.com/18605
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>
Pushing entries onto a stack when handling malloc failures is a
nuisance. sk_push only takes ownership on success. PushToStack smooths
that over with a UniquePtr.
Bug: 132
Change-Id: I4f0a9eee86dda7453f128c33d3a71b550beb25e9
Reviewed-on: https://boringssl-review.googlesource.com/18468
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
My original plan here was to make STACK_OF(T) expand to a template so
the inner type were extractable. Unfortunately, we cannot sanely make
STACK_OF(T) expand to a different type in C and C++ even across
compilation units because UBSan sometimes explodes. This is nuts, but so
it goes.
Instead, use StackTraits to extract the STACK_OF(T) parameters and
define an iterator type.
Bug: 189
Change-Id: I64f5173b34b723ec471f7a355ff46b04f161386a
Reviewed-on: https://boringssl-review.googlesource.com/18467
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
It returns false for incomplete types (or is undefined prior to C++14),
so other instantiations can get confused. Instead, require an explicit
kAllowUniquePtr toggle.
I tried using sizeof(T) to SFINAE-detect an incomplete type but ran into
MSVC issues, I think
https://connect.microsoft.com/VisualStudio/feedback/details/820390/vc-sizeof-doesnt-work-as-expected-in-sfinae-context
Though it seems this also may cause ODR violations if different
compilation units disagree on whether a type is complete. This is all a
mess, so just do the boring thing.
Bug: 132
Change-Id: I6f2d47499f16e75f62629c76f43a5329e91c6daf
Reviewed-on: https://boringssl-review.googlesource.com/18464
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
OpenSSL allows spaces, commas and semi-colons to be used as separators
in cipher strings, in addition to the usual colons.
This change documents that spaces cannot be used in equal-preference
groups and forbids these alternative separators in strict mode.
Change-Id: I3879e25aed54539c281511627e6a282e9463bdc3
Reviewed-on: https://boringssl-review.googlesource.com/18424
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This allows us to avoid omitting all the silly abort() flags in
reasonable downstreams like Chromium, while the holdouts are fixed. It
also means that we still get the compiler checking that we've
implemented all pure virtuals in some build configurations, which we'll
put on a bot somewhere.
Bug: 132
Change-Id: If500749f7100bb22bb8e828e8ecf38a992ae9fe5
Reviewed-on: https://boringssl-review.googlesource.com/18406
Reviewed-by: Steven Valdez <svaldez@google.com>
SSL_get0_peer_certificates is documented to return NULL if the peer was
anonymous, but it actually returns a non-NULL empty list (except in SSL
3.0 where the Certificate message and thus ssl_parse_cert_chain is
skipped).
Make the implementation match the documentation.
Change-Id: Ib3e25d2155f316cc5e9eb3ab7f74b78e08b8a86b
Reviewed-on: https://boringssl-review.googlesource.com/18226
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>
Looks like they're using the pool now.
Change-Id: Ieeb1cacb9cb039d35ff091bc9742262f0fc5b146
Reviewed-on: https://boringssl-review.googlesource.com/18364
Reviewed-by: Adam Langley <agl@google.com>
This is a C++ interface for encrypting and decrypting TLS application
data records in-place, wrapping the existing C API in tls_record.cc.
Also add bssl::Span, a non-owning reference to a contiguous array of
elements which can be used as a common interface over contiguous
container types (like std::vector), pointer-length-pairs, arrays, etc.
Change-Id: Iaa2ca4957cde511cb734b997db38f54e103b0d92
Reviewed-on: https://boringssl-review.googlesource.com/18104
Commit-Queue: Martin Kreichgauer <martinkr@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Short-term, we will need to use these macros and build without RTTI when
defining any virtual base class. Long-term, it would be good to remove
these constraints, but it will require some downstream work.
Bug: 132
Change-Id: I3bc65bb12d7653978612b7d1bf06f772a2f3b1cd
Reviewed-on: https://boringssl-review.googlesource.com/18344
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
SSLECDHContext has the acronyms problem, so I went with SSLKeyShare to
match the TLS 1.3 terminology. It's also a little shorter. Accept and
Finish, for now, take raw output pointers in anticipation of some
bssl::Array and maybe bssl::CleansedArray types.
Bug: 132
Change-Id: I427c7c0eac95704f3ad093676c504c2848f5acb9
Reviewed-on: https://boringssl-review.googlesource.com/18265
Reviewed-by: Steven Valdez <svaldez@google.com>
Originally GREASE was a client-only thing but, in TLS 1.3, we send some
bogus extensions in NewSessionTicket and CertificateRequest. Sampling
from the client_random works fine, but better to use our own entropy
rather than the peer's.
Change-Id: Ic7317eb75a9024c677fcde8e62c73aff380294e4
Reviewed-on: https://boringssl-review.googlesource.com/18144
Reviewed-by: Steven Valdez <svaldez@google.com>
I started by switching a couple fields to SSL_HANDSHAKE and then kept
following transitive bits.
Bug: 132
Change-Id: I640dadd3558615fa38c7e8498d4efe7449b0658f
Reviewed-on: https://boringssl-review.googlesource.com/18245
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
SSL_HANDSHAKE is large so I have not attempted to fully switch it to
scopers in this CL. This is just a preparatory step so that we can start
switching its fields to scopers.
(I also anticipate we'll want a bssl::Array<uint8_t> to replace the
pointer/length pairs.)
Bug: 132
Change-Id: I1538d3fc7f9c7385cd8c44a7b99b5c76e8a8768c
Reviewed-on: https://boringssl-review.googlesource.com/18244
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
The previous attempt around the 'struct ssl_st' compatibility mess
offended OSS-Fuzz and UBSan because one compilation unit passed a
function pointer with ssl_st* and another called it with
bssl::SSLConnection*.
Linkers don't retain such types, of course, but to silence this alert,
instead make C-visible types be separate from the implementation and
subclass the public type. This does mean we risk polluting the symbol
namespace, but hopefully the compiler is smart enough to inline the
visible struct's constructor and destructor.
Bug: 132
Change-Id: Ia75a89b3a22a202883ad671a630b72d0aeef680e
Reviewed-on: https://boringssl-review.googlesource.com/18224
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Clear out some of the easy cases.
Bug: 132
Change-Id: Icd5c246cb6bec4a96c72eccd6569235c3d030ebd
Reviewed-on: https://boringssl-review.googlesource.com/18204
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 several utilities as replacements for new and delete and makes
bssl::UniquePtr work with our private types.
Later work can convert more incrementally. I did this one more
aggressively to see how it'd work. Unfortunately, in doing so, I needed
to remove the NULL SSL_AEAD_CTX "method" receiver trick to appease
clang. The null cipher is now represented by a concrete SSL_AEAD_CTX.
The long-lived references to SSL_AEAD_CTX are not yet in types with
constructors, so they still bare Delete rather than UniquePtr for now.
Though this does mean we may be able to move the sequence number into
SSLAEADContext later which is one less object for DTLS to carry around.
Bug: 132
Change-Id: I506b404addafb692055d5709b0ca6d5439a4e6be
Reviewed-on: https://boringssl-review.googlesource.com/18164
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This is horrible, but everything else I tried was worse. The goal with
this CL is to take the extern "C" out of ssl/internal.h and move most
symbols to namespace bssl, so we can start using C++ helpers and
destructors without worry.
Complications:
- Public API functions must be extern "C" and match their declaration in
ssl.h, which is unnamespaced. C++ really does not want you to
interleave namespaced and unnamespaced things. One can actually write
a namespaced extern "C" function, but this means, from C++'s
perspective, the function is namespaced. Trying to namespace the
public header would worked but ended up too deep a rabbithole.
- Our STACK_OF macros do not work right in namespaces.
- The typedefs for our exposed but opaque types are visible in the
header files and copied into consuming projects as forward
declarations. We ultimately want to give SSL a destructor, but
clobbering an unnamespaced ssl_st::~ssl_st seems bad manners.
- MSVC complains about ambiguous names if one typedefs SSL to bssl::SSL.
This CL opts for:
- ssl/*.cc must begin with #define BORINGSSL_INTERNAL_CXX_TYPES. This
informs the public headers to create forward declarations which are
compatible with our namespaces.
- For now, C++-defined type FOO ends up at bssl::FOO with a typedef
outside. Later I imagine we'll rename many of them.
- Internal functions get namespace bssl, so we stop worrying about
stomping the tls1_prf symbol. Exported C functions are stuck as they
are. Rather than try anything weird, bite the bullet and reorder files
which have a mix of public and private functions. I expect that over
time, the public functions will become fairly small as we move logic
to more idiomatic C++.
Files without any public C functions can just be written normally.
- To avoid MSVC troubles, some bssl types are renamed to CPlusPlusStyle
in advance of them being made idiomatic C++.
Bug: 132
Change-Id: Ic931895e117c38b14ff8d6e5a273e868796c7581
Reviewed-on: https://boringssl-review.googlesource.com/18124
Reviewed-by: David Benjamin <davidben@google.com>
This is needed to switch Chromium's SSLServerSocket and parts of
Conscrypt to CRYPTO_BUFFER.
Bug: 54
Change-Id: Iacd417970607bc1a162057676b576956a3bdfa3f
Reviewed-on: https://boringssl-review.googlesource.com/17965
Reviewed-by: Adam Langley <agl@google.com>
This also serves as a certificate verification callback for
CRYPTO_BUFFER-based consumers. Remove the silly
SSL_CTX_i_promise_to_verify_certs_after_the_handshake placeholder.
Bug: 54, chromium:347402
Change-Id: I4c6b445cb9cd7204218acb2e5d1625e6f37aff6f
Reviewed-on: https://boringssl-review.googlesource.com/17964
Reviewed-by: David Benjamin <davidben@google.com>
In some configurations, Clang will warn about all unannotated
fall-throughs in C++. This change adds the needed annotation for Clang
in the single place where we appear to have this.
Change-Id: I25a9069e659ce278d3cd24bf46f667324b3d5146
Reviewed-on: https://boringssl-review.googlesource.com/18024
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Record splitting is a send-side only behaviour and supporting it in
fuzzer mode was messy.
Change-Id: I406d2cc77f1d83ed2039a85b95acdfbc815f5a44
Reviewed-on: https://boringssl-review.googlesource.com/17944
Reviewed-by: Adam Langley <agl@google.com>
Clang for Windows does not like OPENSSL_COMPILE_ASSERT inside a function
in C++. It complains that the struct is unused. I think we worked around
this in C previously by making it expand to C11 _Static_assert when
available.
But libssl is now C++ and assumes a C++11-capable compiler. Use real
static_assert.
Bug: 132
Change-Id: I6aceb95360244bd2c80d194b80676483abb60519
Reviewed-on: https://boringssl-review.googlesource.com/17924
Reviewed-by: Adam Langley <agl@google.com>
This plumbs EVP_AEAD_CTX_seal_scatter all the way through to
tls_record.c, so we can add a new zero-copy record sealing method on top
of the existing code.
Change-Id: I01fdd88abef5442dc16605ea31b29b4b1231c073
Reviewed-on: https://boringssl-review.googlesource.com/17684
Reviewed-by: Adam Langley <agl@google.com>
Due to SSL 3.0 legacy, TLS 1.0 through 1.2 allow ClientHello and
ServerHello messages to omit the extensions field altogether, rather
than write an empty field. We broke this in
https://boringssl-review.googlesource.com/c/17704/ when we needed to a
second ServerHello parsing path.
Fix this and add some regression tests to explicitly test both the
omitted and empty extensions ClientHello and ServerHello cases.
Bug: chromium:743218
Change-Id: I8297ba608570238e19f12ea44a9fe2fe9d881d28
Reviewed-on: https://boringssl-review.googlesource.com/17904
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This is in an attempt to debug the Mac flakiness. The timestamps will
hopefully help narrow down the order of operations here.
Bug: 199
Change-Id: I8b8dd7222e3a57a8b055b8bc1b7731334e0fcdf0
Reviewed-on: https://boringssl-review.googlesource.com/17886
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 was broken when we added the API to SSL.
Change-Id: I92d4330b0d70f655c9a9ad33898d6b84704e915c
Reviewed-on: https://boringssl-review.googlesource.com/17884
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This implements PR #1051
(https://github.com/tlswg/tls13-spec/pull/1051).
Local experiments were not able to replicate the claims in the PR, but
implement this anyway for comparison purposes.
Change-Id: Ic9baf5e671f9a44565020466a553dd08f5ec0f1b
Reviewed-on: https://boringssl-review.googlesource.com/17844
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>
I suspect this won't actually tell us much useful w.r.t. the Mac test
flakes, but we may as well print what we can get.
Change-Id: I4931f6000648c4bd955a132b54351ff83d6b6273
Reviewed-on: https://boringssl-review.googlesource.com/17804
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>
And, with that, stage one is complete. ssl/internal.h may include C++.
Bug: 132
Change-Id: I0cb89f0ed5f4be36632a50744a80321595dc921c
Reviewed-on: https://boringssl-review.googlesource.com/17768
Reviewed-by: Steven Valdez <svaldez@google.com>
This leaves just the TLS 1.3 handshake code.
Bug: 132
Change-Id: I2bd87b0ecd0ae7d6ea1302bc62c67aec5ca1dccb
Reviewed-on: https://boringssl-review.googlesource.com/17767
Reviewed-by: Steven Valdez <svaldez@google.com>
Bug: 132
Change-Id: I2b0c87262a5a529ea264ea8ce2d11c2dba0ec1c8
Reviewed-on: https://boringssl-review.googlesource.com/17766
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
In the process, merge the old canary function back in.
Bug: 132
Change-Id: Ib455320ecea67c839d0b4ac3882669d24f832b74
Reviewed-on: https://boringssl-review.googlesource.com/17765
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Bug: 132
Change-Id: I0b83bb05082aa6dad8c15f906cebc2d4f2d5216b
Reviewed-on: https://boringssl-review.googlesource.com/17764
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
The EC_POINT munging is sufficiently heavy on the goto err that I went
ahead and tidied it up.
Bug: 132
Change-Id: I7a3b3b3f166e39e4559acec834dd8e1ea9ac8620
Reviewed-on: https://boringssl-review.googlesource.com/17747
Reviewed-by: 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>
ssl_cipher required fixing the types of the cipher masks.
Bug: 132
Change-Id: I0428d853b25fe4674ac3cad87a8eb92c6c8659e3
Reviewed-on: https://boringssl-review.googlesource.com/17746
Reviewed-by: 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>
Bug: 132
Change-Id: Ic68252de7b3a8f90d60f052a3cb707730d5a2b16
Reviewed-on: https://boringssl-review.googlesource.com/17744
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
http://i1.kym-cdn.com/photos/images/original/000/242/631/382.gif
In the first step, switch C files to C++ individually, keeping
everything in internal.h C-compatible. We'll make minimal changes needed
to get things compiling (notably a lot of goto errs will need to turn to
bssl::UniquePtr right away), but more aggressive changes will happen in
later steps.
(To avoid a rebase, I'm intentionally avoiding files that would conflict
with CLs in flight right now.)
Bug: 132
Change-Id: Id4cfd722e7b57d1df11f27236b4658b5d39b5fd2
Reviewed-on: https://boringssl-review.googlesource.com/17667
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: I3de3c48a1de59c2b8de348253ce62a648aa6d6eb
Reviewed-on: https://boringssl-review.googlesource.com/17724
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: 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>
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>
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 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>
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>
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>
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>
These broke at some point. Add a test for them.
Change-Id: Ie45869e07d9615ae33aae4613f6d9b996af39528
Reviewed-on: https://boringssl-review.googlesource.com/17330
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>
WatchGuard's bug is very distinctive. Report a dedicated error code out
of BoringSSL so we can better track this.
Bug: chromium:733223
Change-Id: Ia42abd8654e7987b1d43c63a4f454f35f6aa873b
Reviewed-on: https://boringssl-review.googlesource.com/17328
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>
Both Conscrypt and Netty have a lot of logic to map between the two
kinds of names. WebRTC needed an SSL_CIPHER_get_rfc_name for something.
Just have both in the library. Also deprecate SSL_CIPHER_get_rfc_name
in favor of SSL_CIPHER_standard_name, which matches upstream if built
with enable-ssl-trace. And, unlike SSL_CIPHER_get_rfc_name, this does
not require dealing with the malloc.
(Strangely this decreases bssl's binary size, even though we're carrying
more strings around. It seems the old SSL_CIPHER_get_rfc_name was
somewhat large in comparison. Regardless, a consumer that disliked 30
short strings probably also disliked the OpenSSL names. That would be
better solved by opaquifying SSL_CIPHER and adding a less stringy API
for configuring cipher lists. That's something we can explore later if
needed.)
I also made the command-line tool print out the standard names since
they're more standard. May as well push folks towards those going
forward.
Change-Id: Ieeb3d63e67ef4da87458e68d130166a4c1090596
Reviewed-on: https://boringssl-review.googlesource.com/17324
Reviewed-by: Robert Sloan <varomodt@google.com>
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>
The pointer and length fields should always be kept in sync. Other code
already assumes this anyway.
Change-Id: I62bc77b805cd4d81f2caa4aa49ad3e9d96faa25e
Reviewed-on: https://boringssl-review.googlesource.com/17306
Reviewed-by: 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>
786793411a only got applied to one of the
setters way back.
Change-Id: Ib798002d5ab7a3d0599b6520af25897949fb0071
Reviewed-on: https://boringssl-review.googlesource.com/17305
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>
Avoid dealing with that function call everywhere.
Change-Id: I7de64b59c8d17e8286c18a6b20c704e8ba8b9ebe
Reviewed-on: https://boringssl-review.googlesource.com/17267
Reviewed-by: Steven Valdez <svaldez@google.com>
These are not the true version filters due to SSL_OP_NO_* filters.
Change-Id: I4c2db967d885f7c1875a3e052c5b02ea8d612fe1
Reviewed-on: https://boringssl-review.googlesource.com/17266
Reviewed-by: Steven Valdez <svaldez@google.com>
The original motivation behind the sign/complete split was to avoid
needlessly hashing the input on each pass through the state machine, but
we're payload-based now and, in all cases, the payload is either cheap
to compute or readily available. (Even the hashing worry was probably
unnecessary.)
Tweak ssl_private_key_{sign,decrypt} to automatically call
ssl_private_key_complete as needed and take advantage of this in the
handshake state machines:
- TLS 1.3 signing now computes the payload each pass. The payload is
small and we're already allocating a comparable-sized buffer each
iteration to hold the signature. This shouldn't be a big deal.
- TLS 1.2 decryption code still needs two states due to reading the
message (fixed in new state machine style), but otherwise it just
performs cheap idempotent tasks again. The PSK code is reshuffled to
guarantee the callback is not called twice (though this was impossible
anyway because we don't support RSA_PSK).
- TLS 1.2 CertificateVerify signing is easy as the transcript is readily
available. The buffer is released very slightly later, but it
shouldn't matter.
- TLS 1.2 ServerKeyExchange signing required some reshuffling.
Assembling the ServerKeyExchange parameters is moved to the previous
state. The signing payload has some randoms prepended. This is cheap
enough, but a nuisance in C. Pre-prepend the randoms in
hs->server_params.
With this change, we are *nearly* rid of the A/B => same function
pattern.
BUG=128
Change-Id: Iec4fe0be7cfc88a6de027ba2760fae70794ea810
Reviewed-on: https://boringssl-review.googlesource.com/17265
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
It does not appear removing support for these is feasible right now. :-(
Change-Id: I99521ba6c141855b5140d98bce445d7e62415661
Reviewed-on: https://boringssl-review.googlesource.com/17251
Reviewed-by: David Benjamin <davidben@google.com>
We've got an asynchronous ServerKeyExchange state in the middle that
complicates things a bit, but this is still a little tighter.
BUG=128
Change-Id: I4ee2e3b85e677c9555d2fbddd387c12d41ab2b54
Reviewed-on: https://boringssl-review.googlesource.com/17250
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 can take advantage of our flight-by-flight model.
BUG=128
Change-Id: If27a5b6d88055da71199ef672d9c71969925aca9
Reviewed-on: https://boringssl-review.googlesource.com/17249
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Free code coverage. Also rename things in SSL_select_next_proto so it
works for NPN and ALPN. (I found some code which uses it for ALPN.)
Change-Id: I8d06b768f9484dc3eda1a20506ec84ec3ddbc883
Reviewed-on: https://boringssl-review.googlesource.com/17206
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>
Change-Id: Ice03a4e8378da8ab94f1aa0545615c8aee6982d7
Reviewed-on: https://boringssl-review.googlesource.com/17204
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=76
Change-Id: If58a73da38e46549fd55f84a9104e2dfebfda43f
Reviewed-on: https://boringssl-review.googlesource.com/14164
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 doesn't hugely matter, but I noticed it was some missing coverage.
Change-Id: I3e425d47fbbeaacd9da2ae883f34e89b4562ec11
Reviewed-on: https://boringssl-review.googlesource.com/17184
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>
Rather than adding a new mode to EVP_PKEY_CTX, upstream chose to tie
single-shot signing to EVP_MD_CTX, adding functions which combine
EVP_Digest*Update and EVP_Digest*Final. This adds a weird vestigial
EVP_MD_CTX and makes the signing digest parameter non-uniform, slightly
complicating things. But it means APIs like X509_sign_ctx can work
without modification.
Align with upstream's APIs. This required a bit of fiddling around
evp_test.cc. For consistency and to avoid baking details of parameter
input order, I made it eagerly read all inputs before calling
SetupContext. Otherwise which attributes are present depend a lot on the
shape of the API we use---notably the NO_DEFAULT_DIGEST tests for RSA
switch to failing before consuming an input, which is odd.
(This only matters because we have some tests which expect the operation
to abort the operation early with parameter errors and match against
Error. Those probably should not use FileTest to begin with, but I'll
tease that apart a later time.)
Upstream also named NID_Ed25519 as NID_ED25519, even though the
algorithm is normally stylized as "Ed25519". Switch it to match.
Change-Id: Id6c8f5715930038e754de50338924d044e908045
Reviewed-on: https://boringssl-review.googlesource.com/17044
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>
Change-Id: I1a17860245b7726a24576f5e1bddb0645171f28e
Reviewed-on: https://boringssl-review.googlesource.com/16486
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>
The only place it is used is EC_KEY_{dup,copy} and no one calls that
function on an EC_KEY with ex_data. This aligns with functions like
RSAPublicKey_dup which do not copy ex_data. The logic is also somewhat
subtle in the face of malloc errors (upstream's PR 3323).
In fact, we'd even changed the function pointer signature from upstream,
so BoringSSL-only code is needed to pass this pointer in anyway. (I
haven't switched it to CRYPTO_EX_unused because there are some callers
which pass in an implementation anyway.)
Note, in upstream, the dup hook is also used for SSL_SESSIONs when those
are duplicated (for TLS 1.2 ticket renewal or TLS 1.3 resumption). Our
interpretation is that callers should treat those SSL_SESSIONs
equivalently to newly-established ones. This avoids every consumer
providing a dup hook and simplifies the interface.
(I've gone ahead and removed the TODO(fork). I don't think we'll be able
to change this API. Maybe introduce a new one, but it may not be worth
it? Then again, this API is atrocious... I've never seen anyone use argl
and argp even.)
BUG=21
Change-Id: I6c9e9d5a02347cb229d4c084c1e85125bd741d2b
Reviewed-on: https://boringssl-review.googlesource.com/16344
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>
Instead of a script which generates macros, emit static inlines in
individual header (or C files). This solves a few issues with the
original setup:
- The documentation was off. We match the documentation now.
- The stack macros did not check constness; see some of the fixes in
crypto/x509.
- Type errors did not look like usual type errors.
- Any type which participated in STACK_OF had to be made partially
public. This allows stack types to be defined an internal header or
even an individual file.
- One could not pass sk_FOO_free into something which expects a function
pointer.
Thanks to upstream's 411abf2dd37974a5baa54859c1abcd287b3c1181 for the
idea.
Change-Id: Ie5431390ccad761c17596b0e93941b0d7a68f904
Reviewed-on: https://boringssl-review.googlesource.com/16087
Reviewed-by: Adam Langley <agl@google.com>
We returned the wrong type, but with a typedef which made it void*. In
C++, void* to T* doesn't implicitly convert, so it doesn't quite work
right. Notably, Node passes it into sk_SSL_COMP_zero. The sk_* macros
only weakly typecheck right now, but a pending CL converts them to
proper functions.
Change-Id: I635d1e39e4f4f11b2b7bf350115a7f1b1be30e4f
Reviewed-on: https://boringssl-review.googlesource.com/16447
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I7d8f9098038a82b29ab0eff8a3258975d8804a68
Reviewed-on: https://boringssl-review.googlesource.com/16264
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>
I think I've finally cleared this out. Everything should be using
upstream's longer 'proto' names now.
Change-Id: I6ab283dca845fdc184f3764223d027acba59ca91
Reviewed-on: https://boringssl-review.googlesource.com/16086
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>
https://build.chromium.org/p/client.boringssl/builders/linux_fips_rel/builds/115
appears to have failed because we were hanging on Accept() forever.
Impose a timeout on that and waiting for the process to return so we at
least can see what stdout/stderr was received so far.
Change-Id: Ief7f7759d02a3fbfc504d2f214b742672b0fe9e6
Reviewed-on: https://boringssl-review.googlesource.com/16005
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>
The C side no longer supports DHE, so there is no longer a need for the
Go side to anymore.
Change-Id: I5084177becd369779a4008a41f4838cb31adcfde
Reviewed-on: https://boringssl-review.googlesource.com/15664
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 doesn't actually measure what we need(*) and, because of that, it's
way more noisy than expected.
(*) We want to know whether the pool has been initialised, not whether
it currently thinks it has a lot of bits, but we can't get what we want
without getrandom() support in the kernel.
Change-Id: I20accb99a592739c786a25c1656aeea050ae81a3
Reviewed-on: https://boringssl-review.googlesource.com/15624
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 done in three different places.
Change-Id: I1e55a14c464b1953b3d4de22b50688082ea65129
Reviewed-on: https://boringssl-review.googlesource.com/15306
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>
In FIPS mode we may print a message when we're waiting for additional
entropy. These warnings should not cause runner tests to fail.
Change-Id: I2beff64344fd2fce444576181f4234c4231de444
Reviewed-on: https://boringssl-review.googlesource.com/15266
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=76
Change-Id: I8b754ba17b3e0beee425929e4b53785b2e95f0ae
Reviewed-on: https://boringssl-review.googlesource.com/15164
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 writing tests and BoGo isn't available, it is useful to be able to
configure the set of signature algorithms accepted on the verify side.
Add an API for this.
Change-Id: Ic873189da7f8853e412acd68614df9d9a872a0c8
Reviewed-on: https://boringssl-review.googlesource.com/15125
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>
DHE ciphers no longer exist!
Change-Id: Id3826ae49164cc1071bc40ea4cf1c5aa451245d6
Reviewed-on: https://boringssl-review.googlesource.com/15124
Reviewed-by: 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>
DHE ciphers are gone, so we no longer need to clear drop the "group_id"
field there. That leaves static RSA, but:
- We mass-invalidated every serialized client session in
364f7a6d21, long after we stopped
filling in key_exchange_info on the client.
- Server sessions were not mass-invalidated, but static RSA
key_exchange_info never worked on the server.
This means it is safe to remove this logic.
Change-Id: Id43b233cca066a81686be7c056c530ba8e89f761
Reviewed-on: https://boringssl-review.googlesource.com/15005
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>
This follows up on cedc6f18 by removing support for the
-DBORINGSSL_ENABLE_DHE_TLS compile flag, and the code needed to
support it.
Change-Id: I53b6aa7a0eddd23ace8b770edb2a31b18ba2ce26
Reviewed-on: https://boringssl-review.googlesource.com/14886
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>
As a precursor to removing the code entirely later, disable the protocol
by default. Callers must use SSL_CTX_set_min_version to enable it.
This change also makes SSLv3_method *not* enable SSL 3.0. Normally
version-specific methods set the minimum and maximum version to their
version. SSLv3_method leaves the minimum at the default, so we will
treat it as all versions disabled. To help debugging, the error code is
switched from WRONG_SSL_VERSION to a new NO_SUPPORTED_VERSIONS_ENABLED.
This also defines OPENSSL_NO_SSL3 and OPENSSL_NO_SSL3_METHOD to kick in
any no-ssl3 build paths in consumers which should provide a convenient
hook for any upstreaming changes that may be needed. (OPENSSL_NO_SSL3
existed in older versions of OpenSSL, so in principle one may encounter
an OpenSSL with the same settings.)
Change-Id: I96a8f2f568eb77b2537b3a774b2f7108bd67dd0c
Reviewed-on: https://boringssl-review.googlesource.com/14031
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 remove TODO about post-handshake authentication. The only sensible
way to handle unexpected post-handshake authentication is a fatal error
(dropping them would cause a deadlock), and we treat all post-handshake
authentication as unexpected.
BUG=74
Change-Id: Ic92035b26ddcbcf25241262ce84bcc57b736b7a7
Reviewed-on: https://boringssl-review.googlesource.com/14744
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>
There was a case we were not covering.
Change-Id: Ia8bc1b73f5db3d18afc3cdcfa249867784c3dcd2
Reviewed-on: https://boringssl-review.googlesource.com/14824
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 function is particularly messy as it had a mix of goto err and
return -1, so if we added a cleanup, we may not have noticed a leak.
Change-Id: I7f363f69857b602c40f8d0f35ce6a83b07051e29
Reviewed-on: https://boringssl-review.googlesource.com/14825
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 only works at TLS 1.2 and above as, before TLS 1.2, there is no way
to advertise support for Ed25519 or negotiate the correct signature
algorithm. Add tests for this accordingly.
For now, this is disabled by default on the verifying side but may be
enabled per SSL_CTX. Notably, projects like Chromium which use an
external verifier may need changes elsewhere before they can enable it.
(On the signing side, we can assume that if the caller gave us an
Ed25519 certificate, they mean for us to use it.)
BUG=187
Change-Id: Id25b0a677dcbe205ddd26d8dbba11c04bb520756
Reviewed-on: https://boringssl-review.googlesource.com/14450
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
These will be used to test the C implementation.
BUG=187
Change-Id: If397eaa51885c8140a63c5f731ce58a8ad6949aa
Reviewed-on: https://boringssl-review.googlesource.com/14452
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This will be used for testing purposes.
BUG=187
Change-Id: I4a18c54c690921a4bbccf5bd03107c579a6e9393
Reviewed-on: https://boringssl-review.googlesource.com/14451
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We don't allow consumers to enable and disable RSA and ECDSA signature
algorithms but will filter client-sent cipher suites and server-sent
client certificate types based on this hard-coded list.
This is two less places to update for Ed25519.
BUG=187
Change-Id: I62836b6980acc6d03ee254f0a84e9826668e9e57
Reviewed-on: https://boringssl-review.googlesource.com/14567
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
With public keys reliably extractable from SSL_PRIVATE_KEY_METHOD keys,
we can share the pkey/sigalg check between signing and verifying.
BUG=188
Change-Id: Ieb9382807781e48ffed720b27f450847d3fca788
Reviewed-on: https://boringssl-review.googlesource.com/14566
Reviewed-by: Adam Langley <agl@google.com>
Instead, extract it from the certificate, which is what everyone was
doing anyway. A follow-up change will take advantage of this cleanup to
deduplicate code between signing and verifying for which keys are good
for which signature algorithms.
BUG=188
Change-Id: Ic3f83a6477e8fa53e5e7233f4545f4d2c4b58d01
Reviewed-on: https://boringssl-review.googlesource.com/14565
Reviewed-by: Adam Langley <agl@google.com>
This is an unhelpfully generic name. Rename it to match SSL_ECDH_CTX.
Unqualified "public key" is typically assumed to be the certificate.
Change-Id: I8ba8c3f2bb1343d1c006845a1110e833451c5a56
Reviewed-on: https://boringssl-review.googlesource.com/14564
Reviewed-by: Adam Langley <agl@google.com>
This allows us to share some of the is_ecdsa mess between signing and
verifying in a way that will generalize to Ed25519. This makes it a lot
shorter and gets us closer to Ed25519.
Later work will tidy this up further.
BUG=187
Change-Id: Ibf3c07c48824061389b8c86294225d9ef25dd82d
Reviewed-on: https://boringssl-review.googlesource.com/14448
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We received an external request to add an option to undo the check added
in 3e51757de2.
Change-Id: Ifdd4b07705f2fa3d781d775d5cd139ea72d36734
Reviewed-on: https://boringssl-review.googlesource.com/14644
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 moves the early data switch to CERT to make this
|SSL_set_SSL_CTX|-proof.
Change-Id: Icca96e76636d87578deb24b2d507cabee7e46a4a
Reviewed-on: https://boringssl-review.googlesource.com/14545
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>
Taken from revision 3cb07270c9455e8ad27956a70891c962d121a228 of
go-crypto. Some of the changes look like they might fix some of the
crashes we've been having on ARM bots?
Change-Id: I127fd358db553eae4805e777011a89124f595ff0
Reviewed-on: https://boringssl-review.googlesource.com/14544
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>
We've got to get a bot for this...
Change-Id: I6af0c466c10ec52bf2e67f1e6fa2513411aeb3c0
Reviewed-on: https://boringssl-review.googlesource.com/14524
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Clients or servers enabling both should not stop functioning.
Change-Id: I5cca09f8adfc8ff56b8943123847bbdaf8885cf4
Reviewed-on: https://boringssl-review.googlesource.com/14485
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>
Previously we only needed to be able to serve P-224 certificates, but
now we anticipate a need to be able to connect and validate them also.
Since this requires advertising support for P-224 in the handshake, we
need to support P-224 ECDHE too.
P-224 support is disabled by default and so clients need to both set the
enabled curves explicitly and set a maximum version of TLS 1.2.
Change-Id: Idc69580f47334e0912eb431a0db0e78ee2eb5bbe
Reviewed-on: https://boringssl-review.googlesource.com/14225
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>
Allow the fuzzers to treat this situation, if they ever discover it,
as a bug.
Change-Id: Ie6f1562e9b185d49463cf1a6db28d28780169b11
Reviewed-on: https://boringssl-review.googlesource.com/14424
Reviewed-by: David Benjamin <davidben@google.com>
Change-Id: Ied6b73fde61eb133c9871b42a56aa5a64131b67b
Reviewed-on: https://boringssl-review.googlesource.com/14328
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=185
Change-Id: I4ce6735ca78cd687538a8c0fdbd78ee97b93585c
Reviewed-on: https://boringssl-review.googlesource.com/14382
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 we refactored all the buffering logic, we retained upstream
OpenSSL's allocation patterns. In particular, we always allocated fixed
size write buffer, even though, unlike when reading, we trivially know a
tighter bound (namely however much we happen to be writing right now).
Since the cutoff for when Windows' malloc starts having a hard time is
just below the TLS maximum record size, do the more natural thing of
allocating what we need to hold outgoing ciphertext.
(This only does anything to the write half. Read half is a bit more
involved.)
BUG=chromium:524258
Change-Id: I0165f9ce822b9cc413f3c77e269e6154160537a7
Reviewed-on: https://boringssl-review.googlesource.com/14405
Reviewed-by: Steven Valdez <svaldez@chromium.org>
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>
Remove another remnant of the SSL3_PROTOCOL_METHOD hook.
Change-Id: If6bf055e2ee318420e4c5c40b8eb5356eadda68c
Reviewed-on: https://boringssl-review.googlesource.com/14381
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@chromium.org>
Reviewed-by: Steven Valdez <svaldez@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
BUG=76
Change-Id: Ie894ea5d327f88e66b234767de437dbe5c67c41d
Reviewed-on: https://boringssl-review.googlesource.com/12960
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=76
Change-Id: I43672ee82a50f8fe706a5d607ef774a6e96db252
Reviewed-on: https://boringssl-review.googlesource.com/14379
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 tests that the ticket age is measured from ticket issuance and not
the initial authentication. Specifically, that ssl_session_renew_timeout
also rebases the time.
Change-Id: Iba51efb49c691a44e6428d1cd35f0803ca3d396a
Reviewed-on: https://boringssl-review.googlesource.com/14375
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 is incompatible with 0-RTT, so we gracefully decline 0-RTT
as a server and forbid their combination as a client. We'll keep this
logic around until Channel ID is removed.
Channel ID will be replaced by tokbind which currently uses custom
extensions. Those will need additional logic to work with 0-RTT.
This is not implemented yet so, for now, fail if both are ever
configured together at all. A later change will allow the two to
combine.
BUG=183
Change-Id: I46c5ba883ccd47930349691fb08074a1fab13d5f
Reviewed-on: https://boringssl-review.googlesource.com/14370
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: I0e2e4166ad2c57e3192af058f23374f014a2fcf4
Reviewed-on: https://boringssl-review.googlesource.com/14377
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>
Once 0-RTT data is added to the current 0-RTT logic, the server will
trigger a write when processing incoming data via SSL_read. This means
SSL_read will block on transport write, which is something we've not
tried to avoid far (assuming no renegotiation).
The specification allows for tickets to be sent at half-RTT by
predicting the client Finished. By doing this we both get the tickets on
the wire sooner and avoid confusing I/O patterns. Moreover, we
anticipate we will need this mode for one of the QUIC stateless reject
patterns.
This is tested by always processing NewSessionTickets in the
ExpectHalfRTTData path on 0-RTT connections. As not other
implementations using BoGo may not do this, this is configurable via the
shim config.
BUG=76
Change-Id: Ia0f56ae63f15078ff1cacceba972d2b99001947f
Reviewed-on: https://boringssl-review.googlesource.com/14371
Reviewed-by: Steven Valdez <svaldez@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@chromium.org>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This is a remnant of before we made the handshake write
flight by flight.
Change-Id: I94c0105bb071ffca9ff5aa4c4bf43311c750b49a
Reviewed-on: https://boringssl-review.googlesource.com/14369
Reviewed-by: Steven Valdez <svaldez@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@chromium.org>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This will make it easier to test 0-RTT later on.
BUG=76
Change-Id: I4d60b77c14bc9143ca9785d0a6b8169653a1b120
Reviewed-on: https://boringssl-review.googlesource.com/14367
Reviewed-by: Steven Valdez <svaldez@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@chromium.org>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
It's not immediately obvious what's going on here.
Change-Id: Ibbba80a6ff9ace4d88e89a42efc270b77b4fad12
Reviewed-on: https://boringssl-review.googlesource.com/14368
Reviewed-by: Steven Valdez <svaldez@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@chromium.org>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
The tests all work fine under it except for tests where the shim shuts
down. (In those the shim calls SSL_shutdown as the first function, so it
wouldn't do anything useful.)
Change-Id: Ia2e811bb3c553a690df38d1fd7d3107ae7c9aa12
Reviewed-on: https://boringssl-review.googlesource.com/14366
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've never allowed this as no good can come of it. Add a test for this.
Change-Id: I4b92372f58c1fe2054e33007adbe496d153a9251
Reviewed-on: https://boringssl-review.googlesource.com/14266
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 adds support on the server and client to accept data-less early
data. The server will still fail to parse early data with any
contents, so this should remain disabled.
BUG=76
Change-Id: Id85d192d8e0360b8de4b6971511b5e8a0e8012f7
Reviewed-on: https://boringssl-review.googlesource.com/12921
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>
The |select_certificate_cb| return values are somewhat confusing due
to the fact that they don't match the |cert_cb| ones, despite the
similarities between the two callbacks (they both have "certificate" in
the name! well, sort of).
This also documents the error return value (-1) which was previously
undocumented, and it expands the |SSL_CTX_set_select_certificate_cb|
documentation regarding retrial (by shamelessly copying from
|SSL_CTX_set_ticket_aead_method|).
Also updates other scattered documentation that was missed by previous
changes.
Change-Id: Ib962b31d08e6475e09954cbc3c939988b0ba13f7
Reviewed-on: https://boringssl-review.googlesource.com/14245
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>
They can be restored by compiling with -DBORINGSSL_ENABLE_DHE_TLS.
This is similar to 9c8c4188 for RC4 ciphers.
Change-Id: I7cd3421b108a024f1ee11f13a6df881c2d0de3c3
Reviewed-on: https://boringssl-review.googlesource.com/14284
Commit-Queue: Matt Braithwaite <mab@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>
Static RSA key exchange in SSLv3 does not have a length prefix. We were
checking the ClientHello version rather than the final version.
Change-Id: I2d0e9d3b5a368a7caf8b1ca69f1631400a847f52
Reviewed-on: https://boringssl-review.googlesource.com/14314
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Matt Braithwaite <mab@google.com>
Reviewed-by: Matt Braithwaite <mab@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Based on elements of the Bugs structure, runner will tweak a ClientHello
message after parsing. However, unless the same tweaks are made to a
second ClientHello in a TLS 1.3 connection, it might appear that they
don't match.
Change-Id: I4467c8ece12dc75c7c7b0fad9e622e6783c55f21
Reviewed-on: https://boringssl-review.googlesource.com/14224
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 shuffles a bit of the code around session resumption in TLS 1.3 to
make the async point cleaner to inject. It also fills in cipher and
tlsext_hostname more uniformly.
Filling in the cipher on resumption is a no-op as SSL_SESSION_dup
already copies it, but avoids confusion should we ever implement TLS
1.3's laxer cipher matching on the server. Not filling in
tlsext_hostname on resumption was an oversight; the relevant check isn't
whether we are resuming but whether we have a fresh SSL_SESSION to fill
things into.
Change-Id: Ic02eb079ff228ce4a4d3e0de7445e18cd367e8b2
Reviewed-on: https://boringssl-review.googlesource.com/14205
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This change adds support for setting an |SSL_TICKET_AEAD_METHOD| which
allows a caller to control ticket encryption and decryption to a greater
extent than previously possible and also permits asynchronous ticket
decryption.
This change only includes partial support: TLS 1.3 work remains to be
done.
Change-Id: Ia2e10ebb3257e1a119630c463b6bf389cf20ef18
Reviewed-on: https://boringssl-review.googlesource.com/14144
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This makes its purpose clearer. That the session cache is based on the
initial SSL_CTX is confusing (it's a remnant of OpenSSL's backwards
session resumption ordering), but we're probably stuck with it.
Relatedly, document SSL_set_SSL_CTX better.
Change-Id: I2832efc63f6c959c5424271b365825afc7eec5e4
Reviewed-on: https://boringssl-review.googlesource.com/14204
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Although it returns failure, the cipher list should still be updated.
Conscrypt relies on this behavior to support a Java API edge case.
Change-Id: If58efafc6a4a81e85a0e2ee2c38873a7a4938123
Reviewed-on: https://boringssl-review.googlesource.com/14165
Reviewed-by: Kenny Root <kroot@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>
It's more consistent to have the helper function do the check that
its every caller already performs. This removes the error code
SSL_R_LIBRARY_HAS_NO_CIPHERS in favor of SSL_R_NO_CIPHER_MATCH.
Change-Id: I522239770dcb881d33d54616af386142ae41b29f
Reviewed-on: https://boringssl-review.googlesource.com/13964
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 in preparation of 0-RTT which needs the AEAD version as part of
early data, before the full version negotiation.
BUG=76
Change-Id: Ief68bc69d794da6e55bb9208977b35f3b947273b
Reviewed-on: https://boringssl-review.googlesource.com/14104
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 allows a caller to configure a serving chain without dealing with
crypto/x509.
Change-Id: Ib42bb2ab9227d32071cf13ab07f92d029643a9a6
Reviewed-on: https://boringssl-review.googlesource.com/14126
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>
We'll measure this value to guide what tolerance to use in the 0-RTT
anti-replay mechanism. This also fixes a bug where we were previously
minting ticket_age_add-less tickets on the server. Add a check to reject
all those tickets.
BUG=113
Change-Id: I68e690c0794234234e0d0500b4b9a7f79aea641e
Reviewed-on: https://boringssl-review.googlesource.com/14068
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>
Previously, the |CRYPTO_BUFFER|-based methods always rejected
certificate chains because none of the current callbacks is suitable to
use. In the medium-term, we want an async callback for this but, for
now, we would like to get Chromium working. Chromium already installs a
no-op callback (except for the logic that was moved into BoringSSL in
a58baaf9e6) and so this hack will suffice
for Chromium.
Change-Id: Ie44b7b32b9e42f503c47b072e958507754136d72
Reviewed-on: https://boringssl-review.googlesource.com/14125
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>
(Otherwise it's a pretty opaque failure.)
Change-Id: I164b237eebe2641f2148bb705966da74b399a618
Reviewed-on: https://boringssl-review.googlesource.com/14124
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>
It's only called from within that file.
Change-Id: I281c9eb1ea25d9cfbec492ba8a4d007f45ae2635
Reviewed-on: https://boringssl-review.googlesource.com/14027
Reviewed-by: Adam Langley <agl@google.com>
There are still a few x509.h includes outside ssl_x509.c and ssl_file.c
due to referencing X509_V_* values, but otherwise these includes are no
longer needed.
Change-Id: Ide458e01358dc2ddb6838277d074ad249e599040
Reviewed-on: https://boringssl-review.googlesource.com/14026
Reviewed-by: Adam Langley <agl@google.com>
This is an API from OpenSSL 1.1.0 which is a little risky to add ahead
of bumping OPENSSL_VERSION_NUMBER, but anything which currently builds
against BoringSSL already had an #ifdef due to the
ssl_cipher_preference_list_st business anyway.
Bump BORINGSSL_API_VERSION to make it easier to patch envoy for this.
BUG=6
Change-Id: If8307e30eb069bbd7dc4b8447b6e48e83899d584
Reviewed-on: https://boringssl-review.googlesource.com/14067
Reviewed-by: 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>
Everything has been updated to return the ECDSA curve.
Change-Id: Iee8fafb576c0ff92d9a47304d59cc607b5faa112
Reviewed-on: https://boringssl-review.googlesource.com/14066
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 a CRYPTO_BUFFER getter for the peer certificate chain. Other
things we need for Chromium:
- Verification callback. Ultimately, we want an asynchronous one, but a
synchronous one will do for now.
- Configure client cert chain without X509
I've also removed the historical note about SSL_SESSION serialization.
That was years ago and we've since invalidated all serialized client
sessions.
BUG=671420
Change-Id: I2b3bb010f9182e751fc791cdfd7db44a4ec348e6
Reviewed-on: https://boringssl-review.googlesource.com/14065
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>
Due to middlebox and ecosystem intolerance, short record headers are going to
be unsustainable to deploy.
BUG=119
Change-Id: I20fee79dd85bff229eafc6aeb72e4f33cac96d82
Reviewed-on: https://boringssl-review.googlesource.com/14044
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>
This function is a |CRYPTO_BUFFER|-based method for getting the X.509
names from a CertificateRequest.
Change-Id: Ife26f726d3c1a055b332656678c2bc560b5a66ec
Reviewed-on: https://boringssl-review.googlesource.com/14013
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 allows us to move the code from Chrome into BoringSSL itself.
BUG=126
Change-Id: I04b4f63008a6de0a58dd6c685c78e9edd06deda6
Reviewed-on: https://boringssl-review.googlesource.com/14028
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 the first part to fixing the SSL stack to be 2038-clean.
Internal structures and functions are switched to use OPENSSL_timeval
which, unlike timeval and long, are suitable for timestamps on all
platforms.
It is generally accepted that the year is now sometime after 1970, so
use uint64_t for the timestamps to avoid worrying about serializing
negative numbers in SSL_SESSION.
A follow-up change will fix SSL_CTX_set_current_time_cb to use
OPENSSL_timeval. This will require some coordinating with WebRTC.
DTLSv1_get_timeout is left alone for compatibility and because it stores
time remaining rather than an absolute time.
BUG=155
Change-Id: I1a5054813300874b6f29e348f9cd8ca80f6b9729
Reviewed-on: https://boringssl-review.googlesource.com/13944
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>
The DTLS stack has two very different APIs for handling timeouts. In
non-blocking mode, timeouts are driven externally by the caller with
DTLSv1_get_timeout. In blocking mode, timeouts are driven by the BIO by
calling a BIO_ctrl with BIO_CTRL_DGRAM_SET_NEXT_TIMEOUT.
The latter is never used by consumers, so remove support for it.
BIO_CTRL_DGRAM_SET_NEXT_TIMEOUT implicitly depends on struct timeval
being used for timestamps, which we would like to remove. Without this,
the only public API which relies on this is the testing-only
SSL_CTX_set_current_time_cb which is BoringSSL-only and we can change at
our leisure.
BUG=155
Change-Id: Ic68fa70afab2fa9e6286b84d010eac8ddc9d2ef4
Reviewed-on: https://boringssl-review.googlesource.com/13945
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 allows a caller to get an |SSL_METHOD| that is free of crypto/x509.
Change-Id: I088e78310fd3ff5db453844784e7890659a633bf
Reviewed-on: https://boringssl-review.googlesource.com/14009
Reviewed-by: Adam Langley <agl@google.com>
All the other |X509_METHOD| functions have their type in the name. The
|CERT|-based functions happened not to because they were first, but
that's not a good reason.
Change-Id: I5bcd8a5fb1d1db6966686700e293d8b1361c0095
Reviewed-on: https://boringssl-review.googlesource.com/14007
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 don't have a way to create an X509-less |SSL| yet but, when we do,
it'll be bad to call any X509-related functions on it. This change adds
an assert to every X509-related call to catch this.
Change-Id: Iec1bdf13baa587ee3487a7cfdc8a105bee20f5ca
Reviewed-on: https://boringssl-review.googlesource.com/13970
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>
Rather than store CA names and only find out that they're unparsable
when we're asked for a |STACK_OF(X509_NAME)|, check that we can parse
them all during the handshake. This avoids changing the semantics with
the previous change that kept CA names as |CRYPTO_BUFFER|s.
Change-Id: I0fc7a4e6ab01685347e7a5be0d0579f45b8a4818
Reviewed-on: https://boringssl-review.googlesource.com/13969
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>
This change converts the CA names that are parsed from a server's
CertificateRequest, as well as the CA names that are configured for
sending to clients in the same, to use |CRYPTO_BUFFER|.
The |X509_NAME|-based interfaces are turned into compatibility wrappers.
Change-Id: I95304ecc988ee39320499739a0866c7f8ff5ed98
Reviewed-on: https://boringssl-review.googlesource.com/13585
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>
Change-Id: I3bc1e46fb94104c4ae31c1c98fa0d5a931e5f954
Reviewed-on: https://boringssl-review.googlesource.com/13974
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>
It has no more callers.
Change-Id: I587ccb3b63810ed167febf7a65ba85106d17a300
Reviewed-on: https://boringssl-review.googlesource.com/13911
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>
The new APIs are SSL_CTX_set_strict_cipher_list() and
SSL_set_strict_cipher_list(). They have two motivations:
First, typos in cipher lists can go undetected for a long time, and
can have surprising consequences when silently ignored.
Second, there is a tendency to use superstition in the construction of
cipher lists, for example by "turning off" things that do not actually
exist. This leads to the corrosive belief that DEFAULT and ALL ought
not to be trusted. This belief is false.
Change-Id: I42909b69186e0b4cf45457e5c0bc968f6bbf231a
Reviewed-on: https://boringssl-review.googlesource.com/13925
Commit-Queue: Matt Braithwaite <mab@google.com>
Reviewed-by: Matt Braithwaite <mab@google.com>
The two non-trivial changes are:
1. The public API now queries it out of the session. There is a long
comment over the old field explaining why the state was separate, but
this predates EMS being forbidden from changing across resumption. It
is not possible for established_session and the socket to disagree on
EMS.
2. Since SSL_HANDSHAKE gets reset on each handshake, the check that EMS
does not change on renego looks different. I've reworked that function a
bit, but it should have the same effect.
Change-Id: If72e5291f79681381cf4d8ceab267f76618b7c3d
Reviewed-on: https://boringssl-review.googlesource.com/13910
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 lets us trim another two pointers of per-connection state.
Change-Id: I2145d529bc25b7e24a921d01e82ee99f2c98867c
Reviewed-on: https://boringssl-review.googlesource.com/13804
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 effectively reverts b9824e2417. This
error seems to have mostly just caused confusion in logs and the
occasional bug around failing to ERR_clear_error. Consumers tend to
blindly call SSL_shutdown when tearing down an SSL (to avoid
invalidating sessions). This means handshake failures trigger two
errors, which is screwy.
Go back to the old behavior where SSL_shutdown while SSL_in_init
silently succeeds.
Change-Id: I1fcfc92d481b97c840847dc39afe59679cd995f2
Reviewed-on: https://boringssl-review.googlesource.com/13909
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 reduces us from seven different configuration patterns to six (see
comment #2 of linked bug). I do not believe there is any behavior change
here as SSL_set_SSL_CTX already manually copied the field. It now gives
us a nice invariant: SSL_set_SSL_CTX overrides all and only the
dual-SSL/SSL_CTX options hanging off of CERT.
BUG=123
Change-Id: I1ae06b791fb869917a6503cee41afb2d9be53d89
Reviewed-on: https://boringssl-review.googlesource.com/13865
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>
I'm not sure why the SSL versions of these functions return int while
the SSL_CTX version returns void. It looks like this dates to
https://boringssl-review.googlesource.com/c/1491/, of which the initial
upload was an SSL_ctrl macro. I guess one of the ints got accidentally
preserved in conversion.
(No existing caller, aside from bssl_shim, checks the result.)
Change-Id: Id54309c1aa03462d520b9a45cdfdefdd2cdd1298
Reviewed-on: https://boringssl-review.googlesource.com/13866
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>
0-RTT requires matching the selected ALPN parameters against those in
the session. Stash the ALPN value in the session in TLS 1.3, so we can
recover it.
BUG=76
Change-Id: I8668b287651ae4deb0bf540c0885a02d189adee0
Reviewed-on: https://boringssl-review.googlesource.com/13845
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>
Recent changes added SSL-level setters to these APIs. Unfortunately,
this has the side effect of breaking SSL_set_SSL_CTX, which is how SNI
is typically handled. SSL_set_SSL_CTX is kind of a weird function in
that it's very sensitive to which of the hodge-podge of config styles is
in use. I previously listed out all the config styles here, but it was
long and unhelpful. (I counted up to 7.)
Of the various SSL_set_SSL_CTX-visible config styles, the sanest seems
to be to move it to CERT. In this case, it's actually quite reasonable
since they're very certificate-related.
Later we may wish to think about whether we can cut down all 7 kinds of
config styles because this is kinda nuts. I'm wondering we should do
CERT => SSL_CONFIG, move everything there, and make that be the same
structure that is dropped post-handshake (supposing the caller has
disavowed SSL_clear and renego). Fruit for later thought. (Note though
that comes with a behavior change for all the existing config.)
Change-Id: I9aa47d8bd37bf2847869e0b577739d4d579ee4ae
Reviewed-on: https://boringssl-review.googlesource.com/13864
Reviewed-by: Martin Kreichgauer <martinkr@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>
All the business with rewinding hs->state back or skipping states based
on reuse_message or a skip parameter isn't really worth the trouble for
a debugging callback. With SSL_state no longer exposed, we don't have to
worry about breaking things.
BUG=177
Change-Id: I9a0421f01c8b2f24c80a6b3e44de9138ea023f58
Reviewed-on: https://boringssl-review.googlesource.com/13829
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>
The split was there out of paranoia that some caller may notice the
change in initial state. Now that SSL_state is neutered, simplify.
BUG=177
Change-Id: I7e2138c2b56821b0c79eec98bb09a82fc28238e8
Reviewed-on: https://boringssl-review.googlesource.com/13828
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>
I doubt this matters, but this seems a little odd. In particular, this
avoids info_callback seeing the SSL_ST_OK once we stop switching
hs->state back and forth.
BUG=177
Change-Id: Ied39c0e94c242af9d5d0f26795d6e0f2f0b12406
Reviewed-on: https://boringssl-review.googlesource.com/13827
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>
Code which manages to constrain itself on this will limit our ability to
rework the handshake. I believe, at this point, we only need to expose
one bit of information (there's some code that compares SSL_state to
SSL_ST_OK), if even that.
BUG=177
Change-Id: Ie1c43006737db0b974811f1819755c629ae68e7b
Reviewed-on: https://boringssl-review.googlesource.com/13826
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 makes sense to do if we are a client and initiate a renegotiation
at the same time as the server requesting one. Since we will never
initiate a renegotiation, this should not be necessary.
Change-Id: I5835944291fdb8dfcc4fed2ebf1064e91ccdbe6a
Reviewed-on: https://boringssl-review.googlesource.com/13825
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>
We compare pointer/length pairs constantly. To avoid needing to type it
everywhere and get GTest's output, add a StringPiece-alike for byte
slices which supports ==, !=, and std::ostream.
BUG=129
Change-Id: I108342cbd2c6a58fec0b9cb87ebdf50364bda099
Reviewed-on: https://boringssl-review.googlesource.com/13625
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_SESSION_from_bytes| now takes an |SSL_CTX*|, from which it uses the
|X509_METHOD| and buffer pool. This is our API so we can do this.
This also requires adding an |SSL_CTX*| argument to |SSL_SESSION_new|
for the same reason. However, |SSL_SESSION_new| already has very few
callers (and none in third-party code that I can see) so I think we can
get away with this.
Change-Id: I1337cd2bd8cff03d4b9405ea3146b3b59584aa72
Reviewed-on: https://boringssl-review.googlesource.com/13584
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>
We sized the post-handshake message limit for the older zero-length
KeyUpdate and forgot to update it when it got larger.
Thanks to Matt Caswell for catching this.
Change-Id: I7d2189479e9516fbfb6c195dfa367794d383582c
Reviewed-on: https://boringssl-review.googlesource.com/13805
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: I98903df561bbf8c5739f892d2ad5e89ac0eb8e6f
Reviewed-on: https://boringssl-review.googlesource.com/13369
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>
In honor of CVE-2016-9244. Although that particular bug BoGo was already
testing since it uses 16 bytes here.
The empty session ID case is particularly worth testing to make sure we
don't get confused somewhere. RFC 5077 allows clients to offer tickets
with no session ID. This is absurd since the client then has no way of
detecting resumption except by lookahead. We'll never do this as a
client, but should handle it correctly as a server.
Change-Id: I49695d19f03c4efdef43749c07372d590a010cda
Reviewed-on: https://boringssl-review.googlesource.com/13740
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
ssl_rsa.c now basically deals with private-key functions, so rename to
reflect that.
Change-Id: Ia87ed4c0f9b34af134844e2eeb270fc45ff3f23f
Reviewed-on: https://boringssl-review.googlesource.com/13583
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>
I even made a note to update my change in light of this but still
managed to forget. With this, grep tells me that all |alert| values have
the correct default value now.
Change-Id: If37c4f2f6b36cf69e53303a3924a8eda4cfffed8
Reviewed-on: https://boringssl-review.googlesource.com/13721
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>
We already have some cases where the default is DECODE_ERROR and, rather
than have two defaults, just harmonise on that. (INTERNAL_ERROR might
make more sense in some cases, but we don't want to have to remember
what the default is in each case and nobody really cares what the actual
value is anyway.)
Change-Id: I28007898e8d6e7415219145eb9f43ea875028ab2
Reviewed-on: https://boringssl-review.googlesource.com/13720
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: If97da565155292d5f0de5c6a8b0fd8508398768a
Reviewed-on: https://boringssl-review.googlesource.com/13564
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This ABCD thing with multiple ways to enter the same function is
confusing. ClientHello processing is the most egregious of these, so
split it up ahead of time as an intermediate step.
States remain named as-is due to them being exposed as public API. We
should have a story for which subset of states we need to promise as
public API and to intentionally break all other cases (map to some
generic value) before we go too far there.
BUG=128
Change-Id: Id9d28c6de14bd53c3294552691cebe705748f489
Reviewed-on: https://boringssl-review.googlesource.com/13563
Reviewed-by: Adam Langley <agl@google.com>
Previously, the alert was uninitialised.
(Thanks to Robert Swiecki and honggfuzz.)
Change-Id: I2d4eb96b0126f3eb502672b2600ad43ae140acec
Reviewed-on: https://boringssl-review.googlesource.com/13700
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>
The Go side (thankfully not the C side) was not fully updated for the
exporter secret derivation being earlier at some point. Also TLS 1.2
upgrades the PRF hash for pre-1.2 ciphers to SHA-256, so make sure we
cover that.
Change-Id: Ibdf50ef500e7e48a52799ac75577822bc304a613
Reviewed-on: https://boringssl-review.googlesource.com/13663
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: I471880d785c38123e038279f67348bf02b47d091
Reviewed-on: https://boringssl-review.googlesource.com/13662
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>
Replicate the logic in the AllTests targets to dump the error queue on
failure. GTest seems to print to stdout, so we do here too.
BUG=129
Change-Id: I623b695fb9a474945834c3653728f54e5b122187
Reviewed-on: https://boringssl-review.googlesource.com/13623
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>
The more complex ones will want a TEST_P, but here are a few easy ones
to start with.
BUG=129
Change-Id: I2e341d04910c0b05a5bc7afec961c4541ca7db41
Reviewed-on: https://boringssl-review.googlesource.com/13622
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>
Right now the only way to set an SCT list is the per-context function
SSL_CTX_set_signed_cert_timestamp_list. However this assumes that all the
SSLs generated from a SSL_CTX share the same SCT list, which is wrong.
In order to avoid memory duplication in case SSL_CTX has its own list, a
CRYPTO_BUFFER is used for both SSL_CTX and SSL.
Change-Id: Id20e6f128c33cf3e5bff1be390645441be6518c6
Reviewed-on: https://boringssl-review.googlesource.com/13642
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>
As previously discussed, it turns out we don't actually need this, so
there's no point in keeping it.
Change-Id: If549c917b6bd818cd36948e37cb7839c8d122b1a
Reviewed-on: https://boringssl-review.googlesource.com/13641
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>
The SNI extension may be ACKed by the server. This is kind of pointless,
but make sure we cover these codepaths.
Change-Id: I14b25ab865dd6e35a30f11ebc9027a1518bbeed9
Reviewed-on: https://boringssl-review.googlesource.com/13633
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: I878dfb9f5d3736c3ec0d5fa39052cca58932dbb7
Reviewed-on: https://boringssl-review.googlesource.com/12981
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: I38cd04fa40edde4e4dd31fdc16bbf92985430198
Reviewed-on: https://boringssl-review.googlesource.com/12702
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_get_new_session would stash a copy of the configured hostname
into the SSL_SESSION on the server. Servers have no reason to
configuring that anyway, but, if one did, we'd leak when filling in
the client-supplied SNI later.
Remove this code and guard against this by remembering to OPENSSL_free
when overwriting that field (although it should always be NULL).
Reported-By: Robert Swiecki <swiecki@google.com>
Change-Id: Ib901b5f82e5cf818060ef47a9585363e05dd9932
Reviewed-on: https://boringssl-review.googlesource.com/13631
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>
With the CRYPTO_BUFFER stuff, this API is now slightly more complex. Add
some tests as a sanity-check.
Change-Id: I9da20e3eb6391fc86ed215c5fabec71aa32ef56f
Reviewed-on: https://boringssl-review.googlesource.com/13620
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 purely to support curl, which now has HTTPS proxy support that,
sadly, uses the BIO SSL. Don't use the BIO SSL for anything else.
Change-Id: I9ef6c9773ec87a11e0b5a93968386ac4b351986d
Reviewed-on: https://boringssl-review.googlesource.com/13600
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>
The TLS 1.2 and 1.3 state machines do the exact same thing at the
beginning. Let them process the ClientHello extensions, etc., and
finalize the certificate in common code. Once we start picking
parameters, we begin to diverge. Everything before this point is
arguably part of setting up the configuration, which is
version-agnostic.
BUG=128
Change-Id: I293ea3087ecbc3267bd8cdaa011c98d26a699789
Reviewed-on: https://boringssl-review.googlesource.com/13562
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The version negotiation logic was a little bizarrely wedged in the
middle of the state machine. (We don't support server renegotiation, so
have_version is always false here.)
BUG=128
Change-Id: I9448dce374004b92e8bd5172c36a4e0eea51619c
Reviewed-on: https://boringssl-review.googlesource.com/13561
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
It has no other callers, now that the handshake is written elsewhere.
Change-Id: Ib04bbdc4a54fc7d01405d9b3f765fa9f186244de
Reviewed-on: https://boringssl-review.googlesource.com/13540
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>
In TLS 1.2, resumption's benefits are more-or-less subsumed by False
Start. TLS 1.2 resumption lifetime is bounded by how much traffic we are
willing to encrypt without fresh key material, so the lifetime is short.
Renewal uses the same key, so we do not allow it to increase lifetimes.
In TLS 1.3, resumption unlocks 0-RTT. We do not implement psk_ke, so
resumption incorporates fresh key material into both encrypted traffic
(except for early data) and renewed tickets. Thus we are both more
willing to and more interested in longer lifetimes for tickets. Renewal
is also not useless. Thus in TLS 1.3, lifetime is bound separately by
the lifetime of a given secret as a psk_dhe_ke authenticator and the
lifetime of the online signature which authenticated the initial
handshake.
This change maintains two lifetimes on an SSL_SESSION: timeout which is
the renewable lifetime of this ticket, and auth_timeout which is the
non-renewable cliff. It also separates the TLS 1.2 and TLS 1.3 timeouts.
The old session timeout defaults and configuration apply to TLS 1.3, and
we define new ones for TLS 1.3.
Finally, this makes us honor the NewSessionTicket timeout in TLS 1.3.
It's no longer a "hint" in 1.3 and there's probably value in avoiding
known-useless 0-RTT offers.
BUG=120
Change-Id: Iac46d56e5a6a377d8b88b8fa31f492d534cb1b85
Reviewed-on: https://boringssl-review.googlesource.com/13503
Reviewed-by: Adam Langley <agl@google.com>
This special-case is almost unexposed (the timeout is initialized to the
default) except if the caller calls SSL_CTX_set_timeout(0). Preserve
that behavior by mapping 0 to SSL_DEFAULT_SESSION_TIMEOUT in
SSL_CTX_set_timeout but simplify the internal state.
Change-Id: Ice03a519c25284b925f1e0cf485f2d8c54dc5038
Reviewed-on: https://boringssl-review.googlesource.com/13502
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
It is impossible to have to call dispatch_alert when writing application
data. Now that we don't send warning alerts through ssl3_send_alert, all
alerts are closure alerts, which means attempts to write will fail.
This prunes a lot of dead code, avoiding the re-entrancy in the write
path. With that gone, tracking alert_dispatch is much more
straightforward.
BUG=146
Change-Id: Ie5fe677daee71e463d79562f3d2cea822a92581d
Reviewed-on: https://boringssl-review.googlesource.com/13500
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>
Fix this and add a test. Otherwise enabling TLS 1.3 will cause a server
to blow through its session cache.
Change-Id: I67edbc468faedfd94a6c30cf842af085a6543b50
Reviewed-on: https://boringssl-review.googlesource.com/13501
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 change moves the interface between |X509| and |CRYPTO_BUFFER| a
little further out, towards the API.
Change-Id: I1c014d20f12ad83427575843ca0b3bb22de1a694
Reviewed-on: https://boringssl-review.googlesource.com/13365
Reviewed-by: Adam Langley <agl@google.com>
The recent CRYPTO_BUFFER changes meant that |X509| objects passed to
SSL_CTX_add_extra_chain_cert would be |free|ed immediately. However,
some third-party code (at least serf and curl) continue to use the
|X509| even after handing over ownership.
In order to unblock things, keep the past |X509| around for a while to
paper over the issues with those libraries while we try and upstream
changes.
Change-Id: I832b458af9b265749fed964658c5c34c84d518df
Reviewed-on: https://boringssl-review.googlesource.com/13480
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>
Change-Id: I44202457841f06a899e140f78ae8afa7ac720283
Reviewed-on: https://boringssl-review.googlesource.com/12600
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>
Move to explicit hashing everywhere, matching TLS 1.2 with TLS 1.3. The
ssl_get_message calls between all the handshake states are now all
uniform so, when we're ready, we can rewire the TLS 1.2 state machine to
look like the TLS 1.3 one. (ssl_get_message calls become an
ssl_hs_read_message transition, reuse_message becomes an ssl_hs_ok
transition.)
This avoids some nuisance in processing the ServerHello at the 1.2 / 1.3
transition.
The downside of explicit hashing is we may forget to hash something, but
this will fail to interop with our tests and anyone else, so we should
be able to catch it.
BUG=128
Change-Id: I01393943b14dfaa98eec2a78f62c3a41c29b3a0e
Reviewed-on: https://boringssl-review.googlesource.com/13266
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 kind of annoying (even new state is needed to keep the layering
right). As part of aligning the read paths of the TLS 1.2 and TLS 1.3
state machine, we'll want to move to states calling
ssl_hash_current_message when the process the message, rather than when
the message is read. Right now the TLS 1.2 optional message story
(reuse_message) depends on all messages preceded by an optional message
using ssl_hash_message. For instance, if TLS 1.2 decided to place
CertificateStatus before ServerKeyExchange, we would not be able to
handle it.
However, V2ClientHello, by being handled in the message layer, relies on
ssl_get_message-driven hashing to replace the usual ClientHello hash
with a hash of something custom. This switches things so rather than
ClientHellos being always pre-hashed by the message layer, simulated
ClientHellos no-op ssl_hash_current_message.
This just replaces one hack with another (V2ClientHello is inherently
nasty), but this hack should be more compatible with future plans.
BUG=128
Change-Id: If807ea749d91e306a37bb2362ecc69b84bf224c9
Reviewed-on: https://boringssl-review.googlesource.com/13265
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 aligns the TLS 1.2 state machine closer with the TLS 1.3 state
machine. This is more work for the handshake, but ultimately the
plan is to take the ssl_get_message call out of the handshake (so it is
just the state machine rather than calling into BIO), so the parameters
need to be folded out as in TLS 1.3.
The WrongMessageType-* family of tests should make sure we don't miss
one of these.
BUG=128
Change-Id: I17a1e6177c52a7540b2bc6b0b3f926ab386c4950
Reviewed-on: https://boringssl-review.googlesource.com/13264
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>
If an existing chain had a NULL placeholder for a leaf we could end up
trying to increment its reference count. That results in a crash at
configuration time. Found via the SSL_CTX API fuzzer.
BUG=oss-fuzz:480
Change-Id: I0ddc2cbde2e625015768f1bdc8da625e8a4f05fd
Reviewed-on: https://boringssl-review.googlesource.com/13383
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 was originally changed so that flush_flight could forward BIO_write
errors as-is, but we can and probably should still map BIO_flush errors.
This is unlikely to matter (every relevant BIO likely just has a no-op
flush which returns one), but, e.g., our file BIO returns 0, not -1, on
error.
We possibly should also be mapping BIO_write errors, but I'll leave that
alone for now. It's primarily BIO_read where the BIO return value must
be preserved due to error vs. EOF.
(We probably can just remove the BIO_flush calls altogether, but since
the buffer BIO forwarded the flush signal it would be a user-visible
behavior change to confirm.)
Change-Id: Ib495cc5d043867cf964f99b7ee4535114f7b2230
Reviewed-on: https://boringssl-review.googlesource.com/13367
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
(I split this change off to minimise the noise in future diffs that
actually do something meaningful.)
Change-Id: I7a054dcfc90a44ab5bb89b8f46704e5e3410e524
Reviewed-on: https://boringssl-review.googlesource.com/13364
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This change converts the |CERT| struct to holding certificates as binary
blobs, rather than in parsed form. The members for holding the parsed
form are still there, however, but are only used as a cache for the
event that someone asks us for a non-owning pointer to the parsed leaf
or chain.
Next steps:
* Move more functions in to ssl_x509.c
* Create an X509_OPS struct of function pointers that will hang off
the |SSL_METHOD| to abstract out the current calls to crypto/x509
operations.
BUG=chromium:671420
Change-Id: Ifa05d88c49a987fd561b349705c9c48f106ec868
Reviewed-on: https://boringssl-review.googlesource.com/13280
Reviewed-by: Adam Langley <agl@google.com>
This resolves a TODO, trims per-connection memory, and makes more sense.
These masks have nothing to do with certificate configuration.
Change-Id: I783e6158e51f58cce88e3e68dfa0ed965bdc894c
Reviewed-on: https://boringssl-review.googlesource.com/13368
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>
Until we've gotten it fully working, we should not mint any of these
SSL_SESSIONs, to avoid constraining future versions of our client code.
Notably, if any of our TLS 1.3 clients today serialized sessions, we
would need to rev the serialization format. Without opting into 0-RTT, a
TLS 1.3 client will create SSL_SESSIONs tagged as 0-RTT-capable but
missing important fields (ALPN, etc.). When that serialized session
makes its way to a future version of our client code, it would disagree
with the server about the ALPN value stored in the ticket and cause
interop failures.
I believe the only client code enabling TLS 1.3 right now is Chrome, and
the window is small, so it should be fine. But fix this now before it
becomes a problem.
Change-Id: Ie2b109f8d158017a6f3b4cb6169050d38a66b31c
Reviewed-on: https://boringssl-review.googlesource.com/13342
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: I324743e7d1864fbbb9653209ff93e4da872c8d31
Reviewed-on: https://boringssl-review.googlesource.com/13340
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: Idc93fdca2f1c5c23e4ba48c4efed2edbad1e857b
Reviewed-on: https://boringssl-review.googlesource.com/12521
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>
The TLS 1.2 state machine now looks actually much closer to the TLS 1.3
one on the write side. Although the write states still have a BIO-style
return, they don't actually send anything anymore. Only the BIO flush
state does. Reads are still integrated into the states themselves
though, so I haven't made it match TLS 1.3 yet.
BUG=72
Change-Id: I7708162efca13cd335723efa5080718a5f2808ab
Reviewed-on: https://boringssl-review.googlesource.com/13228
Reviewed-by: Adam Langley <agl@google.com>
The SSL code suffers from needing too many verbs for variations on
writing things without actually writing them. We used to have queuing
the message up to be written to the buffer BIO, writing to the buffer
BIO, and flushing the buffer BIO. (Reading, conversely, has a similar
mess of verbs.)
Now we just have adding to the pending flight and flushing the pending
flight, match the SSL_PROTOCOL_METHOD naming.
BUG=72
Change-Id: I332966928bf13f03dfb8eddd519c2fefdd7f24d4
Reviewed-on: https://boringssl-review.googlesource.com/13227
Reviewed-by: Adam Langley <agl@google.com>
Large chunks of contiguous messages can now be sent in a row. Notably,
the ServerHello flight involves a number of optional messages which can
now be collapsed into straight-line code.
BUG=72
Change-Id: I1429d22a12401aa0f811a04e495bd5d754c084a4
Reviewed-on: https://boringssl-review.googlesource.com/13226
Reviewed-by: Adam Langley <agl@google.com>
On the TLS side, we introduce a running buffer of ciphertext. Queuing up
pending data consists of encrypting the record into the buffer. This
effectively reimplements what the buffer BIO was doing previously, but
this resizes to fit the whole flight.
As part of this, rename all the functions to add to the pending flight
to be more uniform. This CL proposes "add_foo" to add to the pending
flight and "flush_flight" to drain it.
We add an add_alert hook for alerts but, for now, only the SSL 3.0
warning alert (sent mid-handshake) uses this mechanism. Later work will
push this down to the rest of the write path so closure alerts use it
too, as in DTLS. The intended end state is that all the ssl_buffer.c and
wpend_ret logic will only be used for application data and eventually
optionally replaced by the in-place API, while all "incidental" data
will be handled internally.
For now, the two buffers are mutually exclusive. Moving closure alerts
to "incidentals" will change this, but flushing application data early
is tricky due to wpend_ret. (If we call ssl_write_buffer_flush,
do_ssl3_write doesn't realize it still has a wpend_ret to replay.) That
too is all left alone in this change.
To keep the diff down, write_message is retained for now and will be
removed from the state machines in a follow-up change.
BUG=72
Change-Id: Ibce882f5f7196880648f25d5005322ca4055c71d
Reviewed-on: https://boringssl-review.googlesource.com/13224
Reviewed-by: Adam Langley <agl@google.com>
Instead, "writing" a message merely adds it to the outgoing_messages
structure. The code to write the flight then loops over it all and now
shares code with retransmission. The verbs here are all a little odd,
but they'll be fixed in later commits.
In doing so, this fixes a slight miscalculation of the record-layer
overhead when retransmitting a flight that spans two epochs. (We'd use
the encrypted epoch's overhead for the unencrypted epoch.)
BUG=72
Change-Id: I8ac897c955cc74799f8b5ca6923906e97d6dad17
Reviewed-on: https://boringssl-review.googlesource.com/13223
Reviewed-by: Adam Langley <agl@google.com>
This was replaced by the more general CLIENT_RANDOM scheme that records
the master secret. Support was added in Wireshark 1.8.0, released in
June 2012. At this point, ECDHE is sufficiently widely deployed that
anyone that cares about this feature must have upgraded their Wireshark
by now.
Change-Id: I9b708f245ec8728c1999daf91aca663be7d25661
Reviewed-on: https://boringssl-review.googlesource.com/13263
Reviewed-by: David Benjamin <davidben@google.com>
This will let us avoid a scratch buffer when assembling DTLS handshake
packets in the write_message-less flow.
BUG=72
Change-Id: I15e78efe3a9e3933c307e599f0043427330f4a9e
Reviewed-on: https://boringssl-review.googlesource.com/13262
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We need to suppress a few tests on the system Android build until
RSA-PSS is shipped there.
Change-Id: I5843997aae9fa499ec08d76f44fdf3b523599e1c
Reviewed-on: https://boringssl-review.googlesource.com/13267
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: Ifc28887cbf91c7a80bdaf56e3bf80b2f8cfa7d53
Reviewed-on: https://boringssl-review.googlesource.com/13260
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
