Otherwise adding it to the handshake hash doesn't work right.
Change-Id: I2fabae72e8b088a5df26bbeac946f19144d58733
Reviewed-on: https://boringssl-review.googlesource.com/8762
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 enable them once we've gotten it working. For now, our TLS 1.3
believes there is no PSK.
Change-Id: I5ae51266927c8469c671844da9a0f7387c297050
Reviewed-on: https://boringssl-review.googlesource.com/8760
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>
RSASSA-PSS with SHA-512 is slightly too large for 1024-bit RSA. One
should not be using 1024-bit RSA, but it's common enough for tests
(including our own in runner before they were regenerated), that we
should probably do the size check and avoid unnecessary turbulence to
everyone else's test setups.
Change-Id: If0c7e401d7d05404755cba4cbff76de3bc65c138
Reviewed-on: https://boringssl-review.googlesource.com/8746
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>
Tested by having client and server talk to each other. This adds the
certificate_extensions field to CertificateRequest which I'd previously
missed. (We completely ignore the field, with the expectation that the C
code won't have anything useful to do with it either.)
Change-Id: I74f96acd36747d4b6a6f533535e36ea8e94d2be8
Reviewed-on: https://boringssl-review.googlesource.com/8710
Reviewed-by: David Benjamin <davidben@google.com>
[Originally written by nharper, revised by davidben.]
Change-Id: If1d45c33994476f4bc9cd69831b6bbed40f792d0
Reviewed-on: https://boringssl-review.googlesource.com/8599
Reviewed-by: David Benjamin <davidben@google.com>
For now, skip the 1.2 -> 1.1 signal since that will affect shipping
code. We may as well enable it too, but wait until things have settled
down. This implements the version in draft-14 since draft-13's isn't
backwards-compatible.
Change-Id: I46be43e6f4c5203eb4ae006d1c6a2fe7d7a949ec
Reviewed-on: https://boringssl-review.googlesource.com/8724
Reviewed-by: David Benjamin <davidben@google.com>
Now that the odd client/server split (a remnant from the original
crypto/tls code not handling signing-hash/PRF mismatches) is gone, it
can just be pulled from the config.
Change-Id: Idb46c026d6529a2afc2b43d4afedc0aa950614db
Reviewed-on: https://boringssl-review.googlesource.com/8723
Reviewed-by: David Benjamin <davidben@google.com>
Saves worrying about forgetting it. (And indeed I forgot it in the TLS
1.3 code.)
Change-Id: Ibb55a83eddba675da64b7cf2c45eac6348c97784
Reviewed-on: https://boringssl-review.googlesource.com/8722
Reviewed-by: David Benjamin <davidben@google.com>
This way we can test failing client auth without having to worry about
first getting through server auth.
Change-Id: Iaf996d87ac3df702a17e76c26006ca9b2a5bdd1f
Reviewed-on: https://boringssl-review.googlesource.com/8721
Reviewed-by: David Benjamin <davidben@google.com>
[Rebased and tests added by davidben.]
In doing so, regenerate the test RSA certificate to be 2048-bit RSA.
RSA-PSS with SHA-512 is actually too large for 1024-bit RSA. Also make
the sigalg test loop test versions that do and don't work which subsumes
the ecdsa_sha1 TLS 1.3 test.
For now, RSA-PKCS1 is still allowed because NSS has yet to implement
RSA-PSS and we'd like to avoid complicated interop testing.
Change-Id: I686b003ef7042ff757bdaab8d5838b7a4d6edd87
Reviewed-on: https://boringssl-review.googlesource.com/8613
Reviewed-by: David Benjamin <davidben@google.com>
(Of course, it's still signing ServerKeyExchange messages since the
handshake's the old one.)
Change-Id: I35844a329d983f61ed0b5be20b333487406fe7e4
Reviewed-on: https://boringssl-review.googlesource.com/8614
Reviewed-by: David Benjamin <davidben@google.com>
Implement in both C and Go. To test this, route config into all the
sign.go functions so we can expose bugs to skip the check.
Unfortunately, custom private keys are going to be a little weird since
we can't check their curve type. We may need to muse on what to do here.
Perhaps the key type bit should return an enum that includes the curve?
It's weird because, going forward, hopefully all new key types have
exactly one kind of signature so key type == sig alg == sig alg prefs.
Change-Id: I1f487ec143512ead931e3392e8be2a3172abe3d2
Reviewed-on: https://boringssl-review.googlesource.com/8701
Reviewed-by: David Benjamin <davidben@google.com>
That instead happens via signature algorithms, which will be done in a
follow-up commit.
Change-Id: I97bc4646319dddbff62552244b0dd7e9bb2650ef
Reviewed-on: https://boringssl-review.googlesource.com/8700
Reviewed-by: David Benjamin <davidben@google.com>
This is in preparation for TLS 1.3 enforcing curve matches in signature
algorithms.
Change-Id: I82c3a1862703a15e4e36ceb7ec40e27235b620c3
Reviewed-on: https://boringssl-review.googlesource.com/8699
Reviewed-by: David Benjamin <davidben@google.com>
{sha256,ecdsa} should not be silently accepted for an RSA key.
Change-Id: I0c0eea5071f7a59f2707ca0ea023a16cc4126d6a
Reviewed-on: https://boringssl-review.googlesource.com/8697
Reviewed-by: David Benjamin <davidben@google.com>
TLS 1.3 also forbids signing SHA-1 digests, but this will be done as a
consequence of forbidding PKCS#1 in 1.3 altogether (rsa_sign_sha1) and
requiring a curve match in ECDSA (ecdsa_sha1).
Change-Id: I665971139ccef9e270fd5796c5e6a814a8f663b1
Reviewed-on: https://boringssl-review.googlesource.com/8696
Reviewed-by: David Benjamin <davidben@google.com>
Rather than blindly select SHA-1 if we can't find a matching one, act as
if the peer advertised rsa_pkcs1_sha1 and ecdsa_sha1. This means that we
will fail the handshake if no common algorithm may be found.
This is done in preparation for removing the SHA-1 default in TLS 1.3.
Change-Id: I3584947909d3d6988b940f9404044cace265b20d
Reviewed-on: https://boringssl-review.googlesource.com/8695
Reviewed-by: David Benjamin <davidben@google.com>
For when the PackHandshakeFlight tests get enabled.
Change-Id: Iee20fd27d88ed58f59af3b7e2dd92235d35af9ce
Reviewed-on: https://boringssl-review.googlesource.com/8663
Reviewed-by: David Benjamin <davidben@google.com>
Since they include an ECDHE exchange in them, they are equally-well
suited to False Start.
Change-Id: I75d31493a614a78ccbf337574c359271831d654d
Reviewed-on: https://boringssl-review.googlesource.com/8732
Reviewed-by: David Benjamin <davidben@google.com>
[Originally written by nharper, revised by davidben.]
When we add this in the real code, this will want ample tests and hooks
for bugs, but get the core logic in to start with.
Change-Id: I86cf0b6416c9077dbb6471a1802ae984b8fa6c72
Reviewed-on: https://boringssl-review.googlesource.com/8598
Reviewed-by: David Benjamin <davidben@google.com>
TLS 1.3 will use a different function from processClientHello.
Change-Id: I8b26a601cf553834b508feab051927d5986091ca
Reviewed-on: https://boringssl-review.googlesource.com/8597
Reviewed-by: David Benjamin <davidben@google.com>
As with the client, the logic around extensions in 1.3 will want to be
tweaked. readClientHello will probably shrink a bit. (We could probably
stuff 1.3 into the existing parameter negotiation logic, but I expect
it'll get a bit unwieldy once HelloRetryRequest, PSK resumption, and
0-RTT get in there, so I think it's best we leave them separate.)
Change-Id: Id8c323a06a1def6857a59accd9f87fb0b088385a
Reviewed-on: https://boringssl-review.googlesource.com/8596
Reviewed-by: David Benjamin <davidben@google.com>
While the random connection property extensions like ALPN and SRTP
remain largely unchanged in TLS 1.3 (but for interaction with 0-RTT),
authentication-related extensions change significantly and need
dedicated logic.
Change-Id: I2588935c2563a22e9879fb81478b8df5168b43de
Reviewed-on: https://boringssl-review.googlesource.com/8602
Reviewed-by: David Benjamin <davidben@google.com>
Test with and without PackHandshakeFlight enabled to cover when the
early post-CCS fragment will get packed into one of the pre-CCS
handshake records. Also test the resumption cases too to cover more
state transitions.
The various CCS-related tests (since CCS is kind of a mess) are pulled
into their own group.
Change-Id: I6384f2fb28d9885cd2b06d59e765e080e3822d8a
Reviewed-on: https://boringssl-review.googlesource.com/8661
Reviewed-by: David Benjamin <davidben@google.com>
[Originally written by nharper and then revised by davidben.]
Most features are missing, but it works for a start. To avoid breaking
the fake TLS 1.3 tests while the C code is still not landed, all the
logic is gated on a global boolean. When the C code gets in, we'll
set it to true and remove this boolean.
Change-Id: I6b3a369890864c26203fc9cda37c8250024ce91b
Reviewed-on: https://boringssl-review.googlesource.com/8601
Reviewed-by: David Benjamin <davidben@google.com>
I'm surprised we'd never tested this. In addition to splitting handshake
records up, one may pack multiple handshakes into a single record, as
they fit. Generalize the DTLS handshake flush hook to do this in TLS as
well.
Change-Id: Ia546d18c7c56ba45e50f489c5b53e1fcd6404f51
Reviewed-on: https://boringssl-review.googlesource.com/8650
Reviewed-by: David Benjamin <davidben@google.com>
TLS 1.2 and 1.3 will process more-or-less the same server extensions,
but at slightly different points in the handshake. In preparation for
that, split this out into its own function.
Change-Id: I5494dee4724295794dfd13c5e9f9f83eade6b20a
Reviewed-on: https://boringssl-review.googlesource.com/8586
Reviewed-by: Adam Langley <agl@google.com>
[Originally written by nharper, tweaked by davidben.]
For now, ignore them completely.
Change-Id: I28602f219d210a857aa80d6e735557b8d2d1c590
Reviewed-on: https://boringssl-review.googlesource.com/8585
Reviewed-by: Adam Langley <agl@google.com>
Also move them with the other version negotiation tests.
Change-Id: I8ea5777c131f8ab618de3c6d02038e802bd34dd0
Reviewed-on: https://boringssl-review.googlesource.com/8550
Reviewed-by: David Benjamin <davidben@google.com>
TLS 1.2 and 1.3 will both need to call it at different points.
Change-Id: Id62ec289213aa6c06ebe5fe65a57ca6c2b53d538
Reviewed-on: https://boringssl-review.googlesource.com/8600
Reviewed-by: David Benjamin <davidben@google.com>
TLS 1.3 will need to call it under different circumstances. We will also
wish to test TLS 1.3 post-handshake auth, so this function must work
without being passed handshake state.
In doing so, implement matching based on signature algorithms as 1.3
does away with the certificate type list.
Change-Id: Ibdee44bbbb589686fcbcd7412432100279bfac63
Reviewed-on: https://boringssl-review.googlesource.com/8589
Reviewed-by: David Benjamin <davidben@google.com>
[Originally written by nharper and then tweaked by davidben.]
TLS 1.3 tweaks them slightly, so being able to write them in one pass
rather than two will be somewhat more convenient.
Change-Id: Ib7e2d63e28cbae025c840bbb34e9e9c295b44dc6
Reviewed-on: https://boringssl-review.googlesource.com/8588
Reviewed-by: David Benjamin <davidben@google.com>
[Originally written by nharper. Test added by davidben.]
Test vectors taken from hkdf_test.c.
Change-Id: I214bcae325e9c7c242632a169ab5cf80a3178989
Reviewed-on: https://boringssl-review.googlesource.com/8587
Reviewed-by: David Benjamin <davidben@google.com>
[Originally written by nharper, tweaked by davidben.]
In TLS 1.3, every extension the server previously sent gets moved to a
separate EncryptedExtensions message. To be able to share code between
the two, parse those extensions separately. For now, the handshake reads
from serverHello.extensions.foo, though later much of the extensions
logic will probably handle serverExtensions independent of whether it
resides in ServerHello or EncryptedExtensions.
Change-Id: I07aaae6df3ef6fbac49e64661d14078d0dbeafb0
Reviewed-on: https://boringssl-review.googlesource.com/8584
Reviewed-by: David Benjamin <davidben@google.com>
[Originally written by nharper and tweaked by davidben.]
This will end up being split in two with most of the ServerHello
extensions being serializable in both ServerHello and
EncryptedExtensions depending on version.
Change-Id: Ida5876d55fbafb982bc2e5fdaf82872e733d6536
Reviewed-on: https://boringssl-review.googlesource.com/8580
Reviewed-by: David Benjamin <davidben@google.com>
[Originally written by nharper and then slightly tweaked by davidben.]
Between the new deeply nested extension (KeyShare) and most of
ServerHello extensions moving to a separate message, this is probably
long overdue.
Change-Id: Ia86e30f56b597471bb7e27d726a9ec92687b4d10
Reviewed-on: https://boringssl-review.googlesource.com/8569
Reviewed-by: David Benjamin <davidben@google.com>
TLS 1.3 defines its own EncryptedExtensions message. The existing one is
for Channel ID which probably should not have tried to generalize
itself.
Change-Id: I4f48bece98510eb54e64fbf3df6c2a7332bc0261
Reviewed-on: https://boringssl-review.googlesource.com/8566
Reviewed-by: David Benjamin <davidben@google.com>
Right now I believe we are testing against DTLS 1.3 ClientHellos. Fix
this in preparation for making VersionTLS13 go elsewhere in the Go code.
Unfortunately, I made the mistake of mapping DTLS 1.0 to TLS 1.0 rather
than 1.1 in Go. This does mean the names of the tests naturally work out
correctly, but we have to deal with this awkward DTLS-1.1-shaped hole in
our logic.
Change-Id: I8715582ed90acc1f08197831cae6de8d5442d028
Reviewed-on: https://boringssl-review.googlesource.com/8562
Reviewed-by: David Benjamin <davidben@google.com>
In preparation for TLS 1.3 using its actual handshake, switch most tests
to TLS 1.3 and add liberal TODOs for the tests which will need TLS 1.3
variants.
In doing so, move a few tests from basic tests into one of the groups.
Also rename BadECDSACurve to BadECDHECurve (it was never ECDSA) and add
a test to make sure FALLBACK_SCSV is correctly sensitive to the maximum
version.
Change-Id: Ifca6cf8f7a48d6f069483c0aab192ae691b1dd8e
Reviewed-on: https://boringssl-review.googlesource.com/8560
Reviewed-by: David Benjamin <davidben@google.com>
TLS 1.3 defines a new SignatureScheme uint16 enum that is backwards
compatible on the wire with TLS1.2's SignatureAndHashAlgorithm. This
change updates the go testing code to use a single signatureAlgorithm
enum (instead of 2 separate signature and hash enums) in preparation for
TLS 1.3. It also unifies all the signing around this new scheme,
effectively backporting the change to TLS 1.2.
For now, it does not distinguish signature algorithms between 1.2 and
1.3 (RSA-PSS instead of RSA-PKCS1, ECDSA must match curve types). When
the C code is ready make a similar change, the Go code will be updated
to match.
[Originally written by nharper, tweaked significantly by davidben.]
Change-Id: If9a315c4670755089ac061e4ec254ef3457a00de
Reviewed-on: https://boringssl-review.googlesource.com/8450
Reviewed-by: David Benjamin <davidben@google.com>
This replaces the old key_exchange_info APIs and does not require the
caller be aware of the mess around SSL_SESSION management. They
currently have the same bugs around renegotiation as before, but later
work to fix up SSL_SESSION tracking will fix their internals.
For consistency with the existing functions, I've kept the public API at
'curve' rather than 'group' for now. I think it's probably better to
have only one name with a single explanation in the section header
rather than half and half. (I also wouldn't be surprised if the IETF
ends up renaming 'group' again to 'key exchange' at some point. We'll
see what happens.)
Change-Id: I8e90a503bc4045d12f30835c86de64ef9f2d07c8
Reviewed-on: https://boringssl-review.googlesource.com/8565
Reviewed-by: Adam Langley <agl@google.com>
This isn't filled in on the client and Chromium no longer uses it for
plain RSA. It's redundant with existing APIs. This is part of removing
the need for callers to call SSL_get_session where possible.
SSL_get_session is ambiguous when it comes to renego. Some code wants
the current connection state which should not include the pending
handshake and some code wants the handshake scratch space which should.
Renego doesn't exist in TLS 1.3, but TLS 1.3 makes NewSessionTicket a
post-handshake message, so SSL_get_session is somewhat silly of an API
there too.
SSL_SESSION_get_key_exchange_info is a BoringSSL-only API, so we can
freely change it and replace it with APIs keyed on SSL. In doing so, I
think it is better to provide APIs like "SSL_get_dhe_group_size" and
"SSL_get_curve_id" rather than make the caller do the multi-step
SSL_get_current_cipher / SSL_CIPHER_is_ECDHE dance. To that end, RSA
key_exchange_info is pointless as it can already be determined from the
peer certificate.
Change-Id: Ie90523083d8649701c17934b7be0383502a0caa3
Reviewed-on: https://boringssl-review.googlesource.com/8564
Reviewed-by: Adam Langley <agl@google.com>
QUIC, in particular, will set min_version to TLS 1.3 and has no need to send
any legacy ciphers.
Note this requires changing some test expectations. Removing all of TLS 1.1 and
below's ciphers in TLS 1.3 has consequences for how a tripped minimum version
reads.
BUG=66
Change-Id: I695440ae78b95d9c7b5b921c3cb2eb43ea4cc50f
Reviewed-on: https://boringssl-review.googlesource.com/8514
Reviewed-by: David Benjamin <davidben@google.com>
Otherwise if the client's ClientHello logic is messed up and ServerHello is
fine, we won't notice.
Change-Id: I7f983cca45f7da1113ad4a72de1f991115e1b29a
Reviewed-on: https://boringssl-review.googlesource.com/8511
Reviewed-by: David Benjamin <davidben@google.com>
This also adds a missing check to the C half to ensure fake record types are
always correct, to keep implementations honest.
Change-Id: I1d65272e647ffa67018c721d52c639f8ba47d647
Reviewed-on: https://boringssl-review.googlesource.com/8510
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
