Unlike the Scoped* types, bssl::UniquePtr is available to C++ users, and
offered for a large variety of types. The 'extern "C++"' trick is used
to make the C++ bits digestible to C callers that wrap header files in
'extern "C"'.
Change-Id: Ifbca4c2997d6628e33028c7d7620c72aff0f862e
Reviewed-on: https://boringssl-review.googlesource.com/10521
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>
Add a test that RSA-PSS is available in TLS 1.2 by default, both for
signing and verifying. Note that if a custom SSL_PRIVATE_KEY_METHOD is
used and it sets signing preferences, it won't use RSA-PSS if it doesn't
know about it. (See *-Sign-Negotiate-* tests.)
Change-Id: I3776a0c95480188a135795f7ebf31f2b0e0626cc
Reviewed-on: https://boringssl-review.googlesource.com/10723
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 early callback needs to run before even version negotiation has been
resolved.
Change-Id: Ibb449ccec07dedef19b7827400ef318fa2f422c0
Reviewed-on: https://boringssl-review.googlesource.com/10722
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>
Changing parameters on renegotiation makes all our APIs confusing. This
one has no reason to change, so lock it down. In particular, our
preference to forbid Token Binding + renego may be overridden at the
IETF, even though it's insane. Loosening it will be a bit less of a
headache if EMS can't change.
https://www.ietf.org/mail-archive/web/unbearable/current/msg00690.html
claims that this is already in the specification and enforced by NSS. I
can't find anything to this effect in the specification. It just says
the client MUST disable renegotiation when EMS is missing, which is
wishful thinking. At a glance, NSS doesn't seem to check, though I could
be misunderstanding the code.
Nonetheless, locking this down is a good idea anyway. Accurate or not,
take the email as an implicit endorsement of this from Mozilla.
Change-Id: I236b05991d28bed199763dcf2f47bbfb9d0322d7
Reviewed-on: https://boringssl-review.googlesource.com/10721
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>
For now, they can be restored by compiling with -DBORINGSSL_RC4_TLS.
Of note, this means that `MEDIUM' is now empty.
Change-Id: Ic77308e7bd4849bdb2b4882c6b34af85089fe3cc
Reviewed-on: https://boringssl-review.googlesource.com/10580
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Matt Braithwaite <mab@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Matt Braithwaite <mab@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
If code tries to inspect the verify result in the case of a failure then
it seems reasonable that the error code should be in there.
Change-Id: Ic32ac9d340c2c10a405a7b6580f22a06427f041d
Reviewed-on: https://boringssl-review.googlesource.com/10641
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>
4aa154e08f changed the code to assume that
a session callback will zero the |copy| out-arg before returning NULL.
In practice this doesn't always happen and we should be robust against
it.
Change-Id: I0fd14969df836e0fa4f68ded8648fea8094ff9d7
Reviewed-on: https://boringssl-review.googlesource.com/10640
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
To ease the removal of RC4, use 3DES in cases where RC4 is not required,
but is just a placeholder for "ciphersuite that works in SSLv3."
Change-Id: Ib459173e68a662986235b556f330a7e0e02759d7
Reviewed-on: https://boringssl-review.googlesource.com/10523
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>
nginx consumes these error codes without #ifdefs. Continue to define
them for compatibility, even though we never emit them.
BUG=95
Change-Id: I1e991987ce25fc4952cc85b98ffa050a8beab92e
Reviewed-on: https://boringssl-review.googlesource.com/10446
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>
peer_sigalgs should live on SSL_HANDSHAKE. This both releases a little
bit of memory after the handshake is over and also avoids the bug where
the sigalgs get dropped if SSL_set_SSL_CTX is called at a bad time. See
also upstream's 14e14bf6964965d02ce89805d9de867f000095aa.
This only affects consumers using the old SNI callback and not
select_certificate_cb.
Add a test that the SNI callback works as expected. In doing so, add an
SSL_CTX version of the signing preferences API. This is a property of
the cert/key pair (really just the key) and should be tied to that. This
makes it a bit easier to have the regression test work with TLS 1.2 too.
I thought we'd fixed this already, but apparently not... :-/
BUG=95
Change-Id: I75b02fad4059e6aa46c3b05183a07d72880711b3
Reviewed-on: https://boringssl-review.googlesource.com/10445
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>
None of these extensions may be negotiated in TLS 1.3 and are otherwise
on by default. Make the future QUIC/TLS1.3 ClientHello a hair smaller.
Change-Id: I613c339d95470676c78f21fd29e888b7701692c6
Reviewed-on: https://boringssl-review.googlesource.com/10504
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>
Apparently we forgot to do this.
Change-Id: I348cf6d716ae888fddce69ba4801bf09446f5a72
Reviewed-on: https://boringssl-review.googlesource.com/10503
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>
Chromium has switched to better APIs.
Change-Id: I26209b3a03c6a0db1ddce2f1fc99c8750cf6e56a
Reviewed-on: https://boringssl-review.googlesource.com/10501
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: Ie60744761f5aa434a71a998f5ca98a8f8b1c25d5
Reviewed-on: https://boringssl-review.googlesource.com/10447
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'll hold on regenerating the transcripts until either the protocol has
stablized more or we're ready to start actually deploying some of this,
but we can get this in now.
Confirmed these #ifdef points are covered by tests:
- BadFinished-*-TLS13
- *-InvalidSignature-*-TLS13
BUG=79
Change-Id: I5f6b9d0f50ac33d5cc79688928fb3fdf6df845ae
Reviewed-on: https://boringssl-review.googlesource.com/10500
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>
However, for now, we will only enable it if TLS 1.3 is offered.
BUG=85
Change-Id: I958ae0adeafee553dbffb966a6fa41f8a81cef96
Reviewed-on: https://boringssl-review.googlesource.com/10342
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Having two copies of this is confusing. This field is inherently tied to
the certificate chain, which lives on SSL_SESSION, so this should live
there too. This also wasn't getting reset correctly on SSL_clear, but
this is now resolved.
Change-Id: I22b1734a93320bb0bf0dc31faa74d77a8e1de906
Reviewed-on: https://boringssl-review.googlesource.com/10283
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 documented by OpenSSL, it does not interact with session resumption
correctly:
https://www.openssl.org/docs/manmaster/ssl/SSL_set_verify_result.html
Sadly, netty-tcnative calls it, but we should be able to get them to
take it out because it doesn't do anything. Two of the three calls are
immediately after SSL_new. In OpenSSL and BoringSSL as of the previous
commit, this does nothing.
The final call is in verify_callback (see SSL_set_verify). This callback
is called in X509_verify_cert by way of X509_STORE_CTX_set_verify_cb.
As soon as X509_verify_cert returns, ssl->verify_result is clobbered
anyway, so it doesn't do anything.
Within OpenSSL, it's used in testdane.c. As far as I can tell, it does
not actually do a handshake and just uses this function to fake having
done one. (Regardless, we don't need to build against that.)
This is done in preparation for removing ssl->verify_result in favor of
session->verify_result.
Change-Id: I7e32d7f26c44f70136c72e58be05a3a43e62582b
Reviewed-on: https://boringssl-review.googlesource.com/10485
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
In TLS 1.3 draft 14, due to resumption using a different cipher, this
is actually not too hard to mess up. (In fact BoGo didn't quite get it
right.)
Fortunately, the new cipher suite negotiation in draft 15 should make
this reasonable again once we implement it. In the meantime, test it.
Change-Id: I2eb948eeaaa051ecacaa9095b66ff149582ea11d
Reviewed-on: https://boringssl-review.googlesource.com/10442
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: I2e1ee319bb9852b9c686f2f297c470db54f72279
Reviewed-on: https://boringssl-review.googlesource.com/10370
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>
Per Piotr, all caps is the proper rendering.
Change-Id: I783016a6ed7e29f49369fabbcfa49b66910e4954
Reviewed-on: https://boringssl-review.googlesource.com/10486
Reviewed-by: Piotr Sikora <piotrsikora@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>
BUG=84
Change-Id: Ie5eaefddd161488996033de28c0ebd1064bb793d
Reviewed-on: https://boringssl-review.googlesource.com/10484
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
9498e74 changed the default value of verify_result to an error. This
tripped up NGINX, which depends on a bug[1] in OpenSSL. netty-tcnative
also uses this behavior, though it currently isn't tripped up by 9498e74
because it calls |SSL_set_verify_result|. However, we would like to
remove |SSL_set_verify_result| and with two data points, it seems this
is behavior we must preserve.
This change sets |verify_result| to |X509_V_OK| when a) no client
certificate is requested or b) none is given and it's optional.
[1] See BUGS in https://www.openssl.org/docs/manmaster/ssl/SSL_get_verify_result.html
Change-Id: Ibd33660ae409bfe272963a8c39b7e9aa83c3d635
Reviewed-on: https://boringssl-review.googlesource.com/9067
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>
s3_both.c does a few too many things right now, but SSL_HANDSHAKE is not
only for TLS 1.3.
Change-Id: Ieac17c592a1271d4d5c9cee005eaf5642772b8f5
Reviewed-on: https://boringssl-review.googlesource.com/10443
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 fix up those tests as they were a little confused. It is always the
shim that signs and has a configured certificate in these tests.
BUG=95
Change-Id: I57a6b1bad19986c79cd30aaa6cf3b8ca307ef8b2
Reviewed-on: https://boringssl-review.googlesource.com/10444
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>
One less thing to keep track of.
https://github.com/tlswg/tls13-spec/pull/549 got merged.
Change-Id: Ide66e547140f8122a3b8013281be5215c11b6de0
Reviewed-on: https://boringssl-review.googlesource.com/10482
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>
The TLS 1.3 state machine is actually less in need of the aggressive
state machine coverage tests, but nonetheless, we should cover all
handshake shapes. PSK resumption and HelloRetryRequest were missing.
We were also accidentally running "DTLS" versions of the TLS 1.3 tests
but silently running TLS 1.2.
Change-Id: I65db4052b89d770db7e47738e73aaadde9634236
Reviewed-on: https://boringssl-review.googlesource.com/10441
Reviewed-by: Nick Harper <nharper@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>
Right now the logic happens twice which is a nuisance.
Change-Id: Ia8155ada0b4479b2ca4be06152b8cd99816e14e8
Reviewed-on: https://boringssl-review.googlesource.com/10440
Reviewed-by: Nick Harper <nharper@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>
Some version mismatch cases were not being covered due to TLS 1.2 and
TLS 1.3 having very different spellings for tickets resumption. Also
explicitly test that TLS 1.2 tickets aren't offered in the TLS 1.3 slot
and vice versa.
Change-Id: Ibe58386ea2004fb3c1af19342b8d808f13f737a9
Reviewed-on: https://boringssl-review.googlesource.com/10183
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=75
Change-Id: Ied864cfccbc0e68d71c55c5ab563da27b7253463
Reviewed-on: https://boringssl-review.googlesource.com/9043
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>
Much of the ClientHello logic queries hello.vers. To avoid it getting
confused, do all modifications right at the end, otherwise
SendClientVersion also affects whether the key share is sent.
Change-Id: I8be2a4a9807ef9ad88af03971ea1c37e4ba36b9c
Reviewed-on: https://boringssl-review.googlesource.com/10341
Reviewed-by: Nick Harper <nharper@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>
In TLS 1.2 and below, the server is not supposed to echo it, but I just
came across a BigIP server which does. Document this so we know to take
care before trying to flip it in the future.
(It's actually kind of odd that it wasn't allowed to be sent given TLS
1.2 makes supported_groups interact with ECDSA client certificates. Ah
well.)
Change-Id: I4b97266f461e85bb1ad9bb935470e027f926d4df
Reviewed-on: https://boringssl-review.googlesource.com/10320
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
The server should not be allowed select a protocol that wasn't
advertised. Callers tend to not really notice and act as if some default
were chosen which is unlikely to work very well.
Change-Id: Ib6388db72f05386f854d275bab762ca79e8174e6
Reviewed-on: https://boringssl-review.googlesource.com/10284
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>
Since we are eliminating DHE support in TLS, this is just a waste of
bytes.
Change-Id: I3a23ece564e43f7e8874d1ec797def132ba59504
Reviewed-on: https://boringssl-review.googlesource.com/10260
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>
These are probably a good idea to ship so long as we have the PSK
callbacks at all, but they're not *completely* standard yet and Android
tests otherwise need updating to know about them. We don't care enough
about PSK to be in a rush to ship them, and taking them out is an easier
default action until then.
Change-Id: Ic646053d29b69a114e2efea61d593d5e912bdcd0
Reviewed-on: https://boringssl-review.googlesource.com/10225
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 cert_cb runs asynchronously, we end up repeating a large part of very
stateful ClientHello processing. This seems to be mostly fine and there
are few users of server-side cert_cb (it's a new API in 1.0.2), but it's
a little scary.
This is also visible to external consumers because some callbacks get
called multiple times. We especially should try to avoid that as there
is no guarantee that these callbacks are idempotent and give the same
answer each time.
Change-Id: I212b2325eae2cfca0fb423dace101e466c5e5d4e
Reviewed-on: https://boringssl-review.googlesource.com/10224
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>
Now that ssl_bytes_to_cipher_list is uninteresting, it can be an
implementation detail of ssl3_choose_cipher. This removes a tiny amount
of duplicated TLS 1.2 / TLS 1.3 code.
Change-Id: I116a6bb08bbc43da573d4b7b5626c556e1a7452d
Reviewed-on: https://boringssl-review.googlesource.com/10221
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
It's odd that a function like ssl_bytes_to_cipher_list secretly has side
effects all over the place. This removes the need for the TLS 1.3 code
to re-query the version range, and it removes the requirement that the
RI extension be first.
Change-Id: Ic9af549db3aaa8880f3c591b8a13ba9ae91d6a46
Reviewed-on: https://boringssl-review.googlesource.com/10220
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Between TLS 1.2, TLS 1.3, and the early callback, we've got a lot of
ClientHello parsers. Unify everything on the early callback's parser. As
a side effect, this means we can parse a ClientHello fairly succinctly
from any function which will let us split up ClientHello states where
appropriate.
Change-Id: I2359b75f80926cc7d827570cf33f93029b39e525
Reviewed-on: https://boringssl-review.googlesource.com/10184
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 is more progress in letting other stacks use the test runner.
You can provide a per-shim configuration file that includes:
- A list of test patterns to be suppressed (presumably because
they don't work). This setting is ignored if -test is used.
- A translation table of expected errors to shim-specific errors.
BUG=92
Change-Id: I3c31d136e35c282e05d4919e18ba41d44ea9cf2a
Reviewed-on: https://boringssl-review.googlesource.com/9161
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 was renamed to ticket_liftetime_hint in
1e6f11a7ff, which breaks Qt.
Change-Id: I9c6d3097fe96e669f06a4e0880bd4d7d82b03ba8
Reviewed-on: https://boringssl-review.googlesource.com/10181
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>
We handle this correctly but never wrote a test for it. Noticed this in
chatting about the second ClientHello.version bug workaround with Eric
Rescorla.
Change-Id: I09bc6c995d07c0f2c9936031b52c3c639ed3695e
Reviewed-on: https://boringssl-review.googlesource.com/9154
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>
Only X509_up_ref left (it's still waiting on a few external callers).
BUG=89
Change-Id: Ia2aec2bb0a944356cb1ce29f3b58a26bdb8a9977
Reviewed-on: https://boringssl-review.googlesource.com/9141
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Inch towards OpenSSL 1.1.0 compatibility.
BUG=91
Change-Id: Ia45b6bdb5114d0891fdffdef0b5868920324ecec
Reviewed-on: https://boringssl-review.googlesource.com/9140
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
tls13_process_certificate can take a boolean for whether anonymous is
allowed. This does change the error on the client slightly, but I think
this is correct anyway. It is not a syntax error for the server to send
no certificates in so far as the Certificate message allows it. It's
just illegal.
Change-Id: I1af80dacf23f50aad0b1fbd884bc068a40714399
Reviewed-on: https://boringssl-review.googlesource.com/9072
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>
We have tests for this as a server, but none as a client. Extend the
certificate verification tests here. This is in preparation for ensuring
that TLS 1.3 session resumption works correctly.
Change-Id: I9ab9f42838ffd69f73fbd877b0cdfaf31caea707
Reviewed-on: https://boringssl-review.googlesource.com/9111
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>
No sense in having it in both the 1.2 and 1.3 code.
Change-Id: Ib3854714afed24253af7f4bcee26d25e95a10211
Reviewed-on: https://boringssl-review.googlesource.com/9071
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>
While the sanity check isn't insane (one should arrange for sessions to
be invalidated once client auth settings change, and a sid_ctx is one
way to do it), this check lives in a poor place to enforce configuration
mistakes. To be effective, it needs to happen at the start of the
handshake, independent of the ClientHello from the peer.
But the benefit this check gives is low compared to the trouble it will
be to continually maintain this difference from OpenSSL (our own
ssl_test and bssl_shim forget to set a dummy sid_ctx). Instead, remove
it so we don't have to duplicate it across TLS 1.2 and TLS 1.3. Also so
we don't have weird failures which only manifest once a resuming client
connects.
Change-Id: Ia7f88711701afde5e26b7782c2264ce78dccc89b
Reviewed-on: https://boringssl-review.googlesource.com/9112
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>
Extend the DTLS mock clock to apply to sessions too and test that
resumption behaves as expected.
Change-Id: Ib8fdec91b36e11cfa032872b63cf589f93b3da13
Reviewed-on: https://boringssl-review.googlesource.com/9110
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>
We almost forgot to handle this in TLS 1.3, so add a test for it.
Change-Id: I28600325d8fb6c09365e909db607cbace12ecac7
Reviewed-on: https://boringssl-review.googlesource.com/9093
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>
We broke this to varying degrees ages ago.
This is the logic to implement the variations of rules in TLS to discard
sessions after a failed connection, where a failed connection could be
one of:
- A connection that was not cleanly shut down.
- A connection that received a fatal alert.
The first one is nonsense since close_notify does not actually work in
the real world. The second is a vaguely more plausible but...
- A stateless ticket-based server can't drop sessions anyway.
- In TLS 1.3, a client may receive many tickets over the lifetime of a
single connection. With an external session cache like ours which may,
in theory, but multithreaded, this will be a huge hassle to track.
- A client may well attempt to establish a connection and reuse the
session before we receive the fatal alert, so any application state we
hope to manage won't really work.
- An attacker can always close the connection before the fatal alert, so
whatever security policy clearing the session gave is easily
bypassable.
Implementation-wise, this has basically never worked. The
ssl_clear_bad_session logic called into SSL_CTX_remove_session which
relied on the internal session cache. (Sessions not in the internal
session cache don't get removed.) The internal session cache was only
useful for a server, where tickets prevent this mechanism from doing
anything. For a client, we since removed the internal session cache, so
nothing got removed. The API for a client also did not work as it gave
the SSL_SESSION, not the SSL, so a consumer would not know the key to
invalidate anyway.
The recent session state splitting change further broke this.
Moreover, calling into SSL_CTX_remove_session logic like that is
extremely dubious because it mutates the not_resumable flag on the
SSL_SESSION which isn't thread-safe.
Spec-wise, TLS 1.3 has downgraded the MUST to a SHOULD.
Given all that mess, just remove this code. It is no longer necessary to
call SSL_shutdown just to make session caching work.
Change-Id: Ib601937bfc5f6b40436941e1c86566906bb3165d
Reviewed-on: https://boringssl-review.googlesource.com/9091
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>
Save a little bit of typing at the call site.
Change-Id: I818535409b57a694e5e0ea0e9741d89f2be89375
Reviewed-on: https://boringssl-review.googlesource.com/9090
Reviewed-by: Adam Langley <agl@google.com>
We will now send tickets as a server and accept them as a
client. Correctly offering and resuming them in the handshake will be
implemented in a follow-up.
Now that we're actually processing draft 14 tickets, bump the draft
version.
Change-Id: I304320a29c4ffe564fa9c00642a4ace96ff8d871
Reviewed-on: https://boringssl-review.googlesource.com/8982
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 of https://github.com/tlswg/tls13-spec/pull/530, they're gone.
They're still allowed just before the ClientHello or ServerHello, which
is kind of odd, but so it goes.
BUG=86
Change-Id: I3d556ab45e42d0755d23566e006c0db9af35b7b6
Reviewed-on: https://boringssl-review.googlesource.com/9114
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: Id6a7443246479c62cbe0024e2131a2013959e21e
Reviewed-on: https://boringssl-review.googlesource.com/9078
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: I057e19a9547a14b3950395db4318eaf0da01ec13
Reviewed-on: https://boringssl-review.googlesource.com/9079
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>
OpenSSL 1.1.0 added a function to tell if an SSL* is DTLS or not. This
is probably a good idea, especially since SSL_version returns
non-normalized versions.
BUG=91
Change-Id: I25c6cf08b2ebabf0c610c74691de103399f729bc
Reviewed-on: https://boringssl-review.googlesource.com/9077
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>
None of the SSL_VERIFY_FAIL_IF_NO_PEER_CERT codepaths will ever be
reached if SSL_VERIFY_PEER is unset. If we've gotten as far as getting a
Certificate message, consider SSL_VERIFY_FAIL_IF_NO_PEER_CERT alone
significant grounds for rejecting no peer certificate.
Change-Id: I2c6be4269d65b2467b86b1fc7d76ac47ca735553
Reviewed-on: https://boringssl-review.googlesource.com/9070
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: I998f69269cdf813da19ccccc208b476f3501c8c4
Reviewed-on: https://boringssl-review.googlesource.com/8991
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'll need to update it on occasion, but we should not update our
default ClientHello without noticing.
Change-Id: I19ca52fdbe10e3ac14413fecd16be2e58af5a1f6
Reviewed-on: https://boringssl-review.googlesource.com/9075
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>
Where we can move uncommon logic to the caller, we probably ought to.
Change-Id: I54a09fffffc20290be05295137ccb605d562cad0
Reviewed-on: https://boringssl-review.googlesource.com/9069
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>
SSL_set_bio is a nightmare.
In f715c42322, we noticed that, among
other problems, SSL_set_bio's actual behavior did not match how
SSL_set_rfd was calling it due to an asymmetry in the rbio/wbio
handling. This resulted in SSL_set_fd/SSL_set_rfd calls to crash. We
decided that SSL_set_rfd's believed semantics were definitive and
changed SSL_set_bio.
Upstream, in 65e2d672548e7c4bcb28f1c5c835362830b1745b, decided that
SSL_set_bio's behavior, asymmetry and all, was definitive and that the
SSL_set_rfd crash was a bug in SSL_set_rfd. Accordingly, they switched
the fd callers to use the side-specific setters, new in 1.1.0.
Align with upstream's behavior and add tests for all of SSL_set_bio's
insanity. Also export the new side-specific setters in anticipation of
wanting to be mostly compatible with OpenSSL 1.1.0.
Change-Id: Iceac9508711f79750a3cc2ded081b2bb2cbf54d8
Reviewed-on: https://boringssl-review.googlesource.com/9064
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: Idf9db184348140972e57b2a8fa30dc9cb8b2e0f2
Reviewed-on: https://boringssl-review.googlesource.com/9065
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, this was allowed to be empty for the weird SHA-1 fallback
logic. In TLS 1.3, not only is the fallback logic gone, but omitting
them is a syntactic error.
struct {
opaque certificate_request_context<0..2^8-1>;
SignatureScheme
supported_signature_algorithms<2..2^16-2>;
DistinguishedName certificate_authorities<0..2^16-1>;
CertificateExtension certificate_extensions<0..2^16-1>;
} CertificateRequest;
Thanks to Eric Rescorla for pointing this out.
Change-Id: I4991e59bc4647bb665aaf920ed4836191cea3a5a
Reviewed-on: https://boringssl-review.googlesource.com/9062
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 were sending decode_error, but the spec explicitly says (RFC 5246):
unsupported_extension
sent by clients that receive an extended server hello containing
an extension that they did not put in the corresponding client
hello. This message is always fatal.
Also add a test for this when it's a known but unoffered extension. We
actually end up putting these in different codepaths now due to the
custom extensions stuff.
Thanks to Eric Rescorla for pointing this out.
Change-Id: If6c8033d4cfe69ef8af5678b873b25e0dbadfc4f
Reviewed-on: https://boringssl-review.googlesource.com/9061
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 seems much safer for the default value of |verify_result| to be an
error value.
Change-Id: I372ec19c41d77516ed12d0169969994f7d23ed70
Reviewed-on: https://boringssl-review.googlesource.com/9063
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>
We managed to mix two comment styles in the Go license headers and
copy-and-paste it throughout the project.
Change-Id: Iec1611002a795368b478e1cae0b53127782210b1
Reviewed-on: https://boringssl-review.googlesource.com/9060
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>
BUG=74
Change-Id: I72d52c1fbc3413e940dddbc0b20c7f22459da693
Reviewed-on: https://boringssl-review.googlesource.com/8981
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: I5cc194fc0a3ba8283049078e5671c924ee23036c
Reviewed-on: https://boringssl-review.googlesource.com/8980
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>
To prevent configuration/established session confusion, the handshake
session state is separated into the configured session (ssl->session)
and the newly created session (ssl->s3->new_session). Upon conclusion of
the handshake, the finalized session is stored
in (ssl->s3->established_session). During the handshake, any requests
for the session (SSL_get_session) return a non-resumable session, to
prevent resumption of a partially filled session. Sessions should only
be cached upon the completion of the full handshake, using the resulting
established_session. The semantics of accessors on the session are
maintained mid-renego.
Change-Id: I4358aecb71fce4fe14a6746c5af1416a69935078
Reviewed-on: https://boringssl-review.googlesource.com/8612
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 finishes getting rid of ssl_read_bytes! Now we have separate
entry-points for the various cases. For now, I've kept TLS handshake
consuming records partially. When we do the BIO-less API, I expect that
will need to change, since we won't have the record buffer available.
(Instead, the ssl3_read_handshake_bytes and extend_handshake_buffer pair
will look more like the DTLS side or Go and pull the entire record into
init_buf.)
This change opts to make read_app_data drive the message to completion
in anticipation of DTLS 1.3. That hasn't been specified, but
NewSessionTicket certainly will exist. Knowing that DTLS necessarily has
interleave seems something better suited for the SSL_PROTOCOL_METHOD
internals to drive.
It needs refining, but SSL_PROTOCOL_METHOD is now actually a half-decent
abstraction boundary between the higher-level protocol logic and
DTLS/TLS-specific record-layer and message dispatchy bits.
BUG=83
Change-Id: I9b4626bb8a29d9cb30174d9e6912bb420ed45aff
Reviewed-on: https://boringssl-review.googlesource.com/9001
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>
Regression tests for upstream's
https://github.com/openssl/openssl/issues/1298.
Also, given that we're now on our third generation of V2ClientHello
handling, I'm sure we'll have a fourth and fifth and one of these days
I'm going to mess this one up. :-)
Change-Id: I6fd8f311ed0939fbbfd370448b637ccc06145021
Reviewed-on: https://boringssl-review.googlesource.com/9040
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: I7e85a2677fe28a22103a975d517bbee900c44ac3
Reviewed-on: https://boringssl-review.googlesource.com/9050
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>
There are many cases where we need |BN_rand_range| but with a minimum
value other than 0. |BN_rand_range_ex| provides that.
Change-Id: I564326c9206bf4e20a37414bdbce16a951c148ce
Reviewed-on: https://boringssl-review.googlesource.com/8921
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 already forbid renego/app-data interleave. Forbid it within a
HelloRequest too because that's nonsense. No one would ever send:
[hs:HelloReq-] [app:Hello world] [hs:-uest]
Add tests for this case.
This is in preparation for our more complex TLS 1.3 post-handshake logic
which is going to go through the usual handshake reassembly logic and,
for sanity, will want to enforce this anyway.
BUG=83
Change-Id: I80eb9f3333da3d751f98f25d9469860d1993a97a
Reviewed-on: https://boringssl-review.googlesource.com/9000
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>
Per request from EKR. Also we have a lot of long test names, so this
seems generally a good idea.
Change-Id: Ie463f5367ec7d33005137534836005b571c8f424
Reviewed-on: https://boringssl-review.googlesource.com/9021
Reviewed-by: Adam Langley <agl@google.com>
With the previous DTLS change, the dispatch layer only cares about the
end of the handshake to know when to drop the current message. TLS 1.3
post-handshake messages will need a similar hook, so convert it to this
lower-level one.
BUG=83
Change-Id: I4c8c3ba55ba793afa065bf261a7bccac8816c348
Reviewed-on: https://boringssl-review.googlesource.com/8989
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 is in preparation for switching finish_handshake to a
release_current_message hook. finish_handshake in DTLS is also
responsible for releasing any memory associated with extra messages in
the handshake.
Except that's not right and we need to make it an error anyway. Given
that the rest of the DTLS dispatch layer already strongly assumes there
is only one message in epoch one, putting the check in the fragment
processing works fine enough. Add tests for this.
This will certainly need revising when DTLS 1.3 happens (perhaps just a
version check, perhaps bringing finish_handshake back as a function that
can fail... which means we need a state just before SSL_ST_OK), but DTLS
1.3 post-handshake messages haven't really been written down, so let's
do the easy thing for now and add a test for when it gets more
interesting.
This removes the sequence number reset in the DTLS code. That reset
never did anything becase we don't and never will renego. We should make
sure DTLS 1.3 does not bring the reset back for post-handshake stuff.
(It was wrong in 1.2 too. Penultimate-flight retransmits and renego
requests are ambiguous in DTLS.)
BUG=83
Change-Id: I33d645a8550f73e74606030b9815fdac0c9fb682
Reviewed-on: https://boringssl-review.googlesource.com/8988
Reviewed-by: Adam Langley <agl@google.com>
This was only used so we knew when we had a current message to discard
and when we didn't. With init_msg being tracked better, we can use that
instead.
As part of this, switch the V2ClientHello hack to not using
reuse_message. Otherwise we have to fill in init_msg and friends in two
places.
The next change will require that we have a better handle on the "is
there a current message" boolean.
BUG=83
Change-Id: I917efacbad10806d492bbe51eda74c0779084d60
Reviewed-on: https://boringssl-review.googlesource.com/8987
Reviewed-by: Adam Langley <agl@google.com>
Somewhat clearer what it's for than just 4.
Change-Id: Ie7bb89ccdce188d61741da203acd624b49b69058
Reviewed-on: https://boringssl-review.googlesource.com/8986
Reviewed-by: Adam Langley <agl@google.com>
For TLS 1.3, we will need to process more complex post-handshake
messages. It is simplest if we use the same mechanism. In preparation,
allow ssl3_get_message to be called at any point.
Note that this stops reserving SSL3_RT_MAX_PLAIN_LENGTH in init_buf
right off the bat. Instead it will grow as-needed to accomodate the
handshake. SSL3_RT_MAX_PLAIN_LENGTH is rather larger than we probably
need to receive, particularly as a server, so this seems a good plan.
BUG=83
Change-Id: Id7f4024afc4c8a713b46b0d1625432315594350e
Reviewed-on: https://boringssl-review.googlesource.com/8985
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>
Right now they're RSA PRIVATE KEY or EC PRIVATE KEY which requires a bit
more effort to parse. It means the PEM header is necessary to parse
these. OpenSSL and Go automagically convert the format, but other shims
(namely NSS) may not.
Change-Id: I9fa2767dcf1fe6ceeea546390759e1c364a8f16f
Reviewed-on: https://boringssl-review.googlesource.com/9020
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This API needs to be improved but, for the time being, keep the
invariant reasonable.
Change-Id: If94d41e7e7936e44de5ecb36da45f89f80df7784
Reviewed-on: https://boringssl-review.googlesource.com/8984
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>
Implemented in preparation for testing the C implementation. Tested
against itself.
BUG=74
Change-Id: Iec1b9ad22e09711fa4e67c97cc3eb257585c3ae5
Reviewed-on: https://boringssl-review.googlesource.com/8873
Reviewed-by: Nick Harper <nharper@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>
We still don't do anything useful with them, but we know not to put them
in the session ticket field.
In doing so, fix a bug in the CorruptTicket option where it would crash
if tickets are exactly 40 byets in length.
BUG=75
Change-Id: Id1039a58ed314a67d0af4f2c7e0617987c2bd6b5
Reviewed-on: https://boringssl-review.googlesource.com/8872
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 parse out the ticket lifetime which was previously ignored.
BUG=75
Change-Id: I6ba92017bd4f1b31da55fd85d2af529fd592de11
Reviewed-on: https://boringssl-review.googlesource.com/8871
Reviewed-by: Nick Harper <nharper@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>
We have no intention of implementing FFDHE and the DHE ciphers currently
don't work in the 1.3 handshake anyway. Cipher suite negotiation is to
be refactored in the spec so these cipher values won't be used for FFDHE
anyway.
Change-Id: I51547761d70a397dc3dd0391b71db98189f1a844
Reviewed-on: https://boringssl-review.googlesource.com/8874
Reviewed-by: Nick Harper <nharper@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>
This change allows the shim to return a magic error code (89) to
indicate that it doesn't implement some of the given flags for a test.
Unimplemented tests are, by default, an error. The --allow-unimplemented
flag to the test runner causes them to be ignored.
This is done in preparation for non-BoringSSL shims.
Change-Id: Iecfd545b9cf44df5e25b719bfd06275c8149311a
Reviewed-on: https://boringssl-review.googlesource.com/8970
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>
WebRTC want to be able to send a random alert. Add an API for this.
Change-Id: Id3113d68f25748729fd9e9a91dbbfa93eead12c3
Reviewed-on: https://boringssl-review.googlesource.com/8950
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
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>
Ridiculous as it is, the protocol does not forbid packing HelloRequest
and Finished into the same record. Add a test for this case.
Change-Id: I8e1455b261f56169309070bf44d14d40a63eae50
Reviewed-on: https://boringssl-review.googlesource.com/8901
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This doesn't do anything since they're for DTLS, but we ought to satisfy
the API nonetheless. expect_flight is easy with
ssl_hs_flush_and_read_message. received_flight I think basically needs
to get sprinkled into the state machine.
Change-Id: I406c7f776ad8e5e3cbcafcac6b26a688c6d3caf1
Reviewed-on: https://boringssl-review.googlesource.com/8883
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
It used to give a sensible answer ("no") before version negotiation.
Change-Id: I85b778a48cca7a4b66a81384eb18c447982875d1
Reviewed-on: https://boringssl-review.googlesource.com/8900
Reviewed-by: Matt Braithwaite <mab@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Alas, we will need a version fallback for TLS 1.3 again.
This deprecates SSL_MODE_SEND_FALLBACK_SCSV. Rather than supplying a
boolean, have BoringSSL be aware of the real maximum version so we can
change the TLS 1.3 anti-downgrade logic to kick in, even when
max_version is set to 1.2.
The fallback version replaces the maximum version when it is set for
almost all purposes, except for downgrade protection purposes.
BUG=chromium:630165
Change-Id: I4c841dcbc6e55a282b223dfe169ac89c83c8a01f
Reviewed-on: https://boringssl-review.googlesource.com/8882
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
It really should take a few more parameters and save a bit of
long-winded initialization work.
Change-Id: I2823f0aa82be39914a156323f6f32b470b6d6a3b
Reviewed-on: https://boringssl-review.googlesource.com/8876
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>
