This is the equivalent of FragmentAcrossChangeCipherSuite for DTLS. It
is possible for us to, while receiving pre-CCS handshake messages, to
buffer up a message with sequence number meant for a post-CCS Finished.
When we then get to the new epoch and attempt to read the Finished, we
will process the buffered Finished although it was sent with the wrong
encryption.
Move ssl_set_{read,write}_state to SSL_PROTOCOL_METHOD hooks as this is
a property of the transport. Notably, read_state may fail. In DTLS
check the handshake buffer size. We could place this check in
read_change_cipher_spec, but TLS 1.3 has no ChangeCipherSpec message, so
we will need to implement this at the cipher change point anyway. (For
now, there is only an assert on the TLS side. This will be replaced with
a proper check in TLS 1.3.)
Change-Id: Ia52b0b81e7db53e9ed2d4f6d334a1cce13e93297
Reviewed-on: https://boringssl-review.googlesource.com/8790
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>
Keep our C implementation honest.
Change-Id: I9e9e686b7f730b61218362450971afdd82b0b640
Reviewed-on: https://boringssl-review.googlesource.com/8782
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>
It tests the same thing right now with Fake TLS 1.3, but we'll need this
tested in real TLS 1.3.
Change-Id: Iacd32c2d4e56d341e5709a2ccd80fed5d556c94d
Reviewed-on: https://boringssl-review.googlesource.com/8783
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>
prk should be a const parameter.
Change-Id: I2369ed9f87fc3c59afc07d3b667b86aec340052e
Reviewed-on: https://boringssl-review.googlesource.com/8810
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 way we can test them at TLS 1.3 as well. The tests for extensions
which will not exist in TLS 1.3 are intentionally skipped, though the
commit which adds TLS 1.3 will want to add negative tests for them.
Change-Id: I41784298cae44eb6c27b13badae700ad02f9c721
Reviewed-on: https://boringssl-review.googlesource.com/8788
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 legal to enforce and we can keep our server honest.
Change-Id: I86ab796dcb51f88ab833fcf5b57aff40e14c7363
Reviewed-on: https://boringssl-review.googlesource.com/8789
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 was pointed out that the equivalent values may sometimes be hard to
find.
Change-Id: I02a1790e026047b3dc2034c2f9ad75abc9e59eb7
Reviewed-on: https://boringssl-review.googlesource.com/8800
Reviewed-by: Adam Langley <agl@google.com>
This allows us to implement custom RSA-PSS-based keys, so the async TLS
1.3 tests can proceed. For now, both sign and sign_digest exist, so
downstreams only need to manage a small change atomically. We'll remove
sign_digest separately.
In doing so, fold all the *_complete hooks into a single complete hook
as no one who implemented two operations ever used different function
pointers for them.
While I'm here, I've bumped BORINGSSL_API_VERSION. I do not believe we
have any SSL_PRIVATE_KEY_METHOD versions who cannot update atomically,
but save a round-trip in case we do. It's free.
Change-Id: I7f031aabfb3343805deee429b9e244aed5d76aed
Reviewed-on: https://boringssl-review.googlesource.com/8786
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 makes custom private keys and EVP_PKEYs symmetric again. There is
no longer a requirement that the caller pre-filter the configured
signing prefs.
Also switch EVP_PKEY_RSA to NID_rsaEncryption. These are identical, but
if some key types are to be NIDs, we should make them all NIDs.
Change-Id: I82ea41c27a3c57f4c4401ffe1ccad406783e4c64
Reviewed-on: https://boringssl-review.googlesource.com/8785
Reviewed-by: David Benjamin <davidben@google.com>
This gives us a sigalg-based API for configuring signing algorithms.
Change-Id: Ib746a56ebd1061eadd2620cdb140d5171b59bc02
Reviewed-on: https://boringssl-review.googlesource.com/8784
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I2f5c45e0e491f9dd25c2463710697599fea708ed
Reviewed-on: https://boringssl-review.googlesource.com/8794
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: I9ec1a8c87e29ffd4fabef68beb6d094aa7d9a215
Reviewed-on: https://boringssl-review.googlesource.com/8795
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 server must switch the outgoing keys early so that client
certificate alerts are sent with the right keys. (Also so that half-RTT
data may be sent.)
Change-Id: Id5482c811aa0b747ab646453b3856a83f23d3f06
Reviewed-on: https://boringssl-review.googlesource.com/8791
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>
clang-format is being really insistent on reformatting these even when I
tell it only to reformat a small region far away.
Change-Id: I46cfd40e8c8658b73caee9c7deae65265c42f762
Reviewed-on: https://boringssl-review.googlesource.com/8787
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>
EVP_PKT_SIGN is redundant with the RSA/EC check which, in turn, is
redundant with sigalgs processing. The type need only be checked in the
pre-1.2 case which was indeed missing an else.
The client half was likewise missing an else, though it's unreachable
due to leaf cert checks.
Change-Id: Ib3550f71a2120b38eacdd671d4f1700876bcc485
Reviewed-on: https://boringssl-review.googlesource.com/8779
Reviewed-by: David Benjamin <davidben@google.com>
This is already duplicated between client and server and otherwise will
get duplicated yet again for TLS 1.3.
Change-Id: Ia8a352f9bc76fab0f88c1629d08a1da4c13d2510
Reviewed-on: https://boringssl-review.googlesource.com/8778
Reviewed-by: David Benjamin <davidben@google.com>
This will get shared between TLS 1.2 and 1.3.
Change-Id: I9c0d73a087942ac4f8f2075a44bd55647c0dd70b
Reviewed-on: https://boringssl-review.googlesource.com/8777
Reviewed-by: David Benjamin <davidben@google.com>
TLS 1.3 will go through very different code than everything else. Even
SSL 3.0 is somewhat special-cased now. Move the invalid signature tests
there and run at all versions.
Change-Id: Idd0ee9aac2939c0c8fd9af2ea7b4a22942121c60
Reviewed-on: https://boringssl-review.googlesource.com/8775
Reviewed-by: David Benjamin <davidben@google.com>
These will all want to be shared with the TLS 1.3 handshake.
Change-Id: I4e50dc0ed2295d43c7ae800015d71c1406311801
Reviewed-on: https://boringssl-review.googlesource.com/8776
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>
Between client and server, the second API behaves very very differently.
Change-Id: I2a6c3cab717466a2d67ae102810a5ecd99362d9e
Reviewed-on: https://boringssl-review.googlesource.com/8781
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Change-Id: I5addfb1e8ec97fc426ae8ca39769120856470451
Reviewed-on: https://boringssl-review.googlesource.com/8780
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
The TLS 1.3 CertificateRequest code advertised the signing set, not the
verify set. It also wasn't saving the peer's signature algorithm.
Change-Id: I62247d5703e30d8463c92f3d597dbeb403b355ae
Reviewed-on: https://boringssl-review.googlesource.com/8774
Reviewed-by: David Benjamin <davidben@google.com>
ServerKeyExchange and SigningHash are both very 1.2-specific names.
Replace with names that fit both 1.2 and 1.3 (and are a bit shorter).
Also fix a reference to ServerKeyExchange in sign.go.
Change-Id: I25d4ff135cc77cc545f0f9e94014244d56a9e96b
Reviewed-on: https://boringssl-review.googlesource.com/8773
Reviewed-by: David Benjamin <davidben@google.com>
The API is definitive and works in TLS 1.3.
Change-Id: Ifefa295bc792f603b297e796559355f66f668811
Reviewed-on: https://boringssl-review.googlesource.com/8772
Reviewed-by: David Benjamin <davidben@google.com>
The extension is not defined in TLS 1.3.
Change-Id: I5eb85f7142be7e11f1a9c0e4680e8ace9ac50feb
Reviewed-on: https://boringssl-review.googlesource.com/8771
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Resumption is not yet implemented.
Change-Id: I7c3df2912456a0e0d5339d7b0b1f5819f958e900
Reviewed-on: https://boringssl-review.googlesource.com/8770
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 preceding client CA bug is actually almost unreachable since the
list is initialized to a non-NULL empty list. But if one tries hard
enough, a NULL one is possible.
Change-Id: I49e69511bf65b0178c4e0acdb887f8ba7d85faff
Reviewed-on: https://boringssl-review.googlesource.com/8769
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>
We must have mistranscribed this to CBB at some point. If the CA list is
empty, we must still include that field.
Change-Id: I341224d85c9073b09758517cdfa14893793ea0ec
Reviewed-on: https://boringssl-review.googlesource.com/8767
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Nick Harper <nharper@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
Tested against the C code.
Change-Id: I62639e1e46cd4f57625be5d4ff7f6902b318c278
Reviewed-on: https://boringssl-review.googlesource.com/8768
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
We need EnableAllCiphers to make progress so, temporarily, defer the PSK
error. Also flip a true/false bug in the OCSP stapling logic.
Change-Id: Iad597c84393e1400c42b8b290eedc16f73f5ed30
Reviewed-on: https://boringssl-review.googlesource.com/8766
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
deriveTrafficAEAD gets confused by the EnableAllCiphers bug. As a hack,
just return the nil cipher. We only need to progress far enough to read
the shim's error code.
Change-Id: I72d25ac463a03a0e99dd08c38a1a7daef1f94311
Reviewed-on: https://boringssl-review.googlesource.com/8763
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
We'll enable it again later, but the initial land of the 1.3 handshake
will not do resumption. In preparation, turn those off.
Change-Id: I5f98b6a9422eb96be26c4ec41ca7ecde5f592da7
Reviewed-on: https://boringssl-review.googlesource.com/8765
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
In preparation for getting the tests going.
Change-Id: Ifd2ab09e6ce91f99abde759d5db8dc6554521572
Reviewed-on: https://boringssl-review.googlesource.com/8764
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
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>
Change-Id: I6741f374dc69e8d4dd3977f607c3c5688eeabfd7
Reviewed-on: https://boringssl-review.googlesource.com/8744
Reviewed-by: Steven Valdez <svaldez@google.com>
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>
David Benjamin
Steven Valdez
Steven Valdez
Matt Braithwaite
Nick Harper
Steven Valdez