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>
