This is an API from OpenSSL 1.1.0 which is a little risky to add ahead
of bumping OPENSSL_VERSION_NUMBER, but anything which currently builds
against BoringSSL already had an #ifdef due to the
ssl_cipher_preference_list_st business anyway.
Bump BORINGSSL_API_VERSION to make it easier to patch envoy for this.
BUG=6
Change-Id: If8307e30eb069bbd7dc4b8447b6e48e83899d584
Reviewed-on: https://boringssl-review.googlesource.com/14067
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Everything has been updated to return the ECDSA curve.
Change-Id: Iee8fafb576c0ff92d9a47304d59cc607b5faa112
Reviewed-on: https://boringssl-review.googlesource.com/14066
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This adds a CRYPTO_BUFFER getter for the peer certificate chain. Other
things we need for Chromium:
- Verification callback. Ultimately, we want an asynchronous one, but a
synchronous one will do for now.
- Configure client cert chain without X509
I've also removed the historical note about SSL_SESSION serialization.
That was years ago and we've since invalidated all serialized client
sessions.
BUG=671420
Change-Id: I2b3bb010f9182e751fc791cdfd7db44a4ec348e6
Reviewed-on: https://boringssl-review.googlesource.com/14065
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Due to middlebox and ecosystem intolerance, short record headers are going to
be unsustainable to deploy.
BUG=119
Change-Id: I20fee79dd85bff229eafc6aeb72e4f33cac96d82
Reviewed-on: https://boringssl-review.googlesource.com/14044
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This function is a |CRYPTO_BUFFER|-based method for getting the X.509
names from a CertificateRequest.
Change-Id: Ife26f726d3c1a055b332656678c2bc560b5a66ec
Reviewed-on: https://boringssl-review.googlesource.com/14013
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This allows us to move the code from Chrome into BoringSSL itself.
BUG=126
Change-Id: I04b4f63008a6de0a58dd6c685c78e9edd06deda6
Reviewed-on: https://boringssl-review.googlesource.com/14028
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This is the first part to fixing the SSL stack to be 2038-clean.
Internal structures and functions are switched to use OPENSSL_timeval
which, unlike timeval and long, are suitable for timestamps on all
platforms.
It is generally accepted that the year is now sometime after 1970, so
use uint64_t for the timestamps to avoid worrying about serializing
negative numbers in SSL_SESSION.
A follow-up change will fix SSL_CTX_set_current_time_cb to use
OPENSSL_timeval. This will require some coordinating with WebRTC.
DTLSv1_get_timeout is left alone for compatibility and because it stores
time remaining rather than an absolute time.
BUG=155
Change-Id: I1a5054813300874b6f29e348f9cd8ca80f6b9729
Reviewed-on: https://boringssl-review.googlesource.com/13944
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
The DTLS stack has two very different APIs for handling timeouts. In
non-blocking mode, timeouts are driven externally by the caller with
DTLSv1_get_timeout. In blocking mode, timeouts are driven by the BIO by
calling a BIO_ctrl with BIO_CTRL_DGRAM_SET_NEXT_TIMEOUT.
The latter is never used by consumers, so remove support for it.
BIO_CTRL_DGRAM_SET_NEXT_TIMEOUT implicitly depends on struct timeval
being used for timestamps, which we would like to remove. Without this,
the only public API which relies on this is the testing-only
SSL_CTX_set_current_time_cb which is BoringSSL-only and we can change at
our leisure.
BUG=155
Change-Id: Ic68fa70afab2fa9e6286b84d010eac8ddc9d2ef4
Reviewed-on: https://boringssl-review.googlesource.com/13945
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This allows a caller to get an |SSL_METHOD| that is free of crypto/x509.
Change-Id: I088e78310fd3ff5db453844784e7890659a633bf
Reviewed-on: https://boringssl-review.googlesource.com/14009
Reviewed-by: Adam Langley <agl@google.com>
All the other |X509_METHOD| functions have their type in the name. The
|CERT|-based functions happened not to because they were first, but
that's not a good reason.
Change-Id: I5bcd8a5fb1d1db6966686700e293d8b1361c0095
Reviewed-on: https://boringssl-review.googlesource.com/14007
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
We don't have a way to create an X509-less |SSL| yet but, when we do,
it'll be bad to call any X509-related functions on it. This change adds
an assert to every X509-related call to catch this.
Change-Id: Iec1bdf13baa587ee3487a7cfdc8a105bee20f5ca
Reviewed-on: https://boringssl-review.googlesource.com/13970
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Rather than store CA names and only find out that they're unparsable
when we're asked for a |STACK_OF(X509_NAME)|, check that we can parse
them all during the handshake. This avoids changing the semantics with
the previous change that kept CA names as |CRYPTO_BUFFER|s.
Change-Id: I0fc7a4e6ab01685347e7a5be0d0579f45b8a4818
Reviewed-on: https://boringssl-review.googlesource.com/13969
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This change converts the CA names that are parsed from a server's
CertificateRequest, as well as the CA names that are configured for
sending to clients in the same, to use |CRYPTO_BUFFER|.
The |X509_NAME|-based interfaces are turned into compatibility wrappers.
Change-Id: I95304ecc988ee39320499739a0866c7f8ff5ed98
Reviewed-on: https://boringssl-review.googlesource.com/13585
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: I3bc1e46fb94104c4ae31c1c98fa0d5a931e5f954
Reviewed-on: https://boringssl-review.googlesource.com/13974
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
It has no more callers.
Change-Id: I587ccb3b63810ed167febf7a65ba85106d17a300
Reviewed-on: https://boringssl-review.googlesource.com/13911
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
The new APIs are SSL_CTX_set_strict_cipher_list() and
SSL_set_strict_cipher_list(). They have two motivations:
First, typos in cipher lists can go undetected for a long time, and
can have surprising consequences when silently ignored.
Second, there is a tendency to use superstition in the construction of
cipher lists, for example by "turning off" things that do not actually
exist. This leads to the corrosive belief that DEFAULT and ALL ought
not to be trusted. This belief is false.
Change-Id: I42909b69186e0b4cf45457e5c0bc968f6bbf231a
Reviewed-on: https://boringssl-review.googlesource.com/13925
Commit-Queue: Matt Braithwaite <mab@google.com>
Reviewed-by: Matt Braithwaite <mab@google.com>
The two non-trivial changes are:
1. The public API now queries it out of the session. There is a long
comment over the old field explaining why the state was separate, but
this predates EMS being forbidden from changing across resumption. It
is not possible for established_session and the socket to disagree on
EMS.
2. Since SSL_HANDSHAKE gets reset on each handshake, the check that EMS
does not change on renego looks different. I've reworked that function a
bit, but it should have the same effect.
Change-Id: If72e5291f79681381cf4d8ceab267f76618b7c3d
Reviewed-on: https://boringssl-review.googlesource.com/13910
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This lets us trim another two pointers of per-connection state.
Change-Id: I2145d529bc25b7e24a921d01e82ee99f2c98867c
Reviewed-on: https://boringssl-review.googlesource.com/13804
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This effectively reverts b9824e2417. This
error seems to have mostly just caused confusion in logs and the
occasional bug around failing to ERR_clear_error. Consumers tend to
blindly call SSL_shutdown when tearing down an SSL (to avoid
invalidating sessions). This means handshake failures trigger two
errors, which is screwy.
Go back to the old behavior where SSL_shutdown while SSL_in_init
silently succeeds.
Change-Id: I1fcfc92d481b97c840847dc39afe59679cd995f2
Reviewed-on: https://boringssl-review.googlesource.com/13909
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This reduces us from seven different configuration patterns to six (see
comment #2 of linked bug). I do not believe there is any behavior change
here as SSL_set_SSL_CTX already manually copied the field. It now gives
us a nice invariant: SSL_set_SSL_CTX overrides all and only the
dual-SSL/SSL_CTX options hanging off of CERT.
BUG=123
Change-Id: I1ae06b791fb869917a6503cee41afb2d9be53d89
Reviewed-on: https://boringssl-review.googlesource.com/13865
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
I'm not sure why the SSL versions of these functions return int while
the SSL_CTX version returns void. It looks like this dates to
https://boringssl-review.googlesource.com/c/1491/, of which the initial
upload was an SSL_ctrl macro. I guess one of the ints got accidentally
preserved in conversion.
(No existing caller, aside from bssl_shim, checks the result.)
Change-Id: Id54309c1aa03462d520b9a45cdfdefdd2cdd1298
Reviewed-on: https://boringssl-review.googlesource.com/13866
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
0-RTT requires matching the selected ALPN parameters against those in
the session. Stash the ALPN value in the session in TLS 1.3, so we can
recover it.
BUG=76
Change-Id: I8668b287651ae4deb0bf540c0885a02d189adee0
Reviewed-on: https://boringssl-review.googlesource.com/13845
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Recent changes added SSL-level setters to these APIs. Unfortunately,
this has the side effect of breaking SSL_set_SSL_CTX, which is how SNI
is typically handled. SSL_set_SSL_CTX is kind of a weird function in
that it's very sensitive to which of the hodge-podge of config styles is
in use. I previously listed out all the config styles here, but it was
long and unhelpful. (I counted up to 7.)
Of the various SSL_set_SSL_CTX-visible config styles, the sanest seems
to be to move it to CERT. In this case, it's actually quite reasonable
since they're very certificate-related.
Later we may wish to think about whether we can cut down all 7 kinds of
config styles because this is kinda nuts. I'm wondering we should do
CERT => SSL_CONFIG, move everything there, and make that be the same
structure that is dropped post-handshake (supposing the caller has
disavowed SSL_clear and renego). Fruit for later thought. (Note though
that comes with a behavior change for all the existing config.)
Change-Id: I9aa47d8bd37bf2847869e0b577739d4d579ee4ae
Reviewed-on: https://boringssl-review.googlesource.com/13864
Reviewed-by: Martin Kreichgauer <martinkr@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
All the business with rewinding hs->state back or skipping states based
on reuse_message or a skip parameter isn't really worth the trouble for
a debugging callback. With SSL_state no longer exposed, we don't have to
worry about breaking things.
BUG=177
Change-Id: I9a0421f01c8b2f24c80a6b3e44de9138ea023f58
Reviewed-on: https://boringssl-review.googlesource.com/13829
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
The split was there out of paranoia that some caller may notice the
change in initial state. Now that SSL_state is neutered, simplify.
BUG=177
Change-Id: I7e2138c2b56821b0c79eec98bb09a82fc28238e8
Reviewed-on: https://boringssl-review.googlesource.com/13828
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
I doubt this matters, but this seems a little odd. In particular, this
avoids info_callback seeing the SSL_ST_OK once we stop switching
hs->state back and forth.
BUG=177
Change-Id: Ied39c0e94c242af9d5d0f26795d6e0f2f0b12406
Reviewed-on: https://boringssl-review.googlesource.com/13827
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Code which manages to constrain itself on this will limit our ability to
rework the handshake. I believe, at this point, we only need to expose
one bit of information (there's some code that compares SSL_state to
SSL_ST_OK), if even that.
BUG=177
Change-Id: Ie1c43006737db0b974811f1819755c629ae68e7b
Reviewed-on: https://boringssl-review.googlesource.com/13826
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This makes sense to do if we are a client and initiate a renegotiation
at the same time as the server requesting one. Since we will never
initiate a renegotiation, this should not be necessary.
Change-Id: I5835944291fdb8dfcc4fed2ebf1064e91ccdbe6a
Reviewed-on: https://boringssl-review.googlesource.com/13825
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
We compare pointer/length pairs constantly. To avoid needing to type it
everywhere and get GTest's output, add a StringPiece-alike for byte
slices which supports ==, !=, and std::ostream.
BUG=129
Change-Id: I108342cbd2c6a58fec0b9cb87ebdf50364bda099
Reviewed-on: https://boringssl-review.googlesource.com/13625
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
|SSL_SESSION_from_bytes| now takes an |SSL_CTX*|, from which it uses the
|X509_METHOD| and buffer pool. This is our API so we can do this.
This also requires adding an |SSL_CTX*| argument to |SSL_SESSION_new|
for the same reason. However, |SSL_SESSION_new| already has very few
callers (and none in third-party code that I can see) so I think we can
get away with this.
Change-Id: I1337cd2bd8cff03d4b9405ea3146b3b59584aa72
Reviewed-on: https://boringssl-review.googlesource.com/13584
Reviewed-by: Adam Langley <alangley@gmail.com>
Commit-Queue: Adam Langley <alangley@gmail.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
We sized the post-handshake message limit for the older zero-length
KeyUpdate and forgot to update it when it got larger.
Thanks to Matt Caswell for catching this.
Change-Id: I7d2189479e9516fbfb6c195dfa367794d383582c
Reviewed-on: https://boringssl-review.googlesource.com/13805
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: I98903df561bbf8c5739f892d2ad5e89ac0eb8e6f
Reviewed-on: https://boringssl-review.googlesource.com/13369
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
In honor of CVE-2016-9244. Although that particular bug BoGo was already
testing since it uses 16 bytes here.
The empty session ID case is particularly worth testing to make sure we
don't get confused somewhere. RFC 5077 allows clients to offer tickets
with no session ID. This is absurd since the client then has no way of
detecting resumption except by lookahead. We'll never do this as a
client, but should handle it correctly as a server.
Change-Id: I49695d19f03c4efdef43749c07372d590a010cda
Reviewed-on: https://boringssl-review.googlesource.com/13740
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
ssl_rsa.c now basically deals with private-key functions, so rename to
reflect that.
Change-Id: Ia87ed4c0f9b34af134844e2eeb270fc45ff3f23f
Reviewed-on: https://boringssl-review.googlesource.com/13583
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
I even made a note to update my change in light of this but still
managed to forget. With this, grep tells me that all |alert| values have
the correct default value now.
Change-Id: If37c4f2f6b36cf69e53303a3924a8eda4cfffed8
Reviewed-on: https://boringssl-review.googlesource.com/13721
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
We already have some cases where the default is DECODE_ERROR and, rather
than have two defaults, just harmonise on that. (INTERNAL_ERROR might
make more sense in some cases, but we don't want to have to remember
what the default is in each case and nobody really cares what the actual
value is anyway.)
Change-Id: I28007898e8d6e7415219145eb9f43ea875028ab2
Reviewed-on: https://boringssl-review.googlesource.com/13720
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: If97da565155292d5f0de5c6a8b0fd8508398768a
Reviewed-on: https://boringssl-review.googlesource.com/13564
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This ABCD thing with multiple ways to enter the same function is
confusing. ClientHello processing is the most egregious of these, so
split it up ahead of time as an intermediate step.
States remain named as-is due to them being exposed as public API. We
should have a story for which subset of states we need to promise as
public API and to intentionally break all other cases (map to some
generic value) before we go too far there.
BUG=128
Change-Id: Id9d28c6de14bd53c3294552691cebe705748f489
Reviewed-on: https://boringssl-review.googlesource.com/13563
Reviewed-by: Adam Langley <agl@google.com>
Previously, the alert was uninitialised.
(Thanks to Robert Swiecki and honggfuzz.)
Change-Id: I2d4eb96b0126f3eb502672b2600ad43ae140acec
Reviewed-on: https://boringssl-review.googlesource.com/13700
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
The Go side (thankfully not the C side) was not fully updated for the
exporter secret derivation being earlier at some point. Also TLS 1.2
upgrades the PRF hash for pre-1.2 ciphers to SHA-256, so make sure we
cover that.
Change-Id: Ibdf50ef500e7e48a52799ac75577822bc304a613
Reviewed-on: https://boringssl-review.googlesource.com/13663
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: I471880d785c38123e038279f67348bf02b47d091
Reviewed-on: https://boringssl-review.googlesource.com/13662
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Replicate the logic in the AllTests targets to dump the error queue on
failure. GTest seems to print to stdout, so we do here too.
BUG=129
Change-Id: I623b695fb9a474945834c3653728f54e5b122187
Reviewed-on: https://boringssl-review.googlesource.com/13623
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
The more complex ones will want a TEST_P, but here are a few easy ones
to start with.
BUG=129
Change-Id: I2e341d04910c0b05a5bc7afec961c4541ca7db41
Reviewed-on: https://boringssl-review.googlesource.com/13622
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Right now the only way to set an SCT list is the per-context function
SSL_CTX_set_signed_cert_timestamp_list. However this assumes that all the
SSLs generated from a SSL_CTX share the same SCT list, which is wrong.
In order to avoid memory duplication in case SSL_CTX has its own list, a
CRYPTO_BUFFER is used for both SSL_CTX and SSL.
Change-Id: Id20e6f128c33cf3e5bff1be390645441be6518c6
Reviewed-on: https://boringssl-review.googlesource.com/13642
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
As previously discussed, it turns out we don't actually need this, so
there's no point in keeping it.
Change-Id: If549c917b6bd818cd36948e37cb7839c8d122b1a
Reviewed-on: https://boringssl-review.googlesource.com/13641
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
The SNI extension may be ACKed by the server. This is kind of pointless,
but make sure we cover these codepaths.
Change-Id: I14b25ab865dd6e35a30f11ebc9027a1518bbeed9
Reviewed-on: https://boringssl-review.googlesource.com/13633
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: I878dfb9f5d3736c3ec0d5fa39052cca58932dbb7
Reviewed-on: https://boringssl-review.googlesource.com/12981
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: I38cd04fa40edde4e4dd31fdc16bbf92985430198
Reviewed-on: https://boringssl-review.googlesource.com/12702
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
ssl_get_new_session would stash a copy of the configured hostname
into the SSL_SESSION on the server. Servers have no reason to
configuring that anyway, but, if one did, we'd leak when filling in
the client-supplied SNI later.
Remove this code and guard against this by remembering to OPENSSL_free
when overwriting that field (although it should always be NULL).
Reported-By: Robert Swiecki <swiecki@google.com>
Change-Id: Ib901b5f82e5cf818060ef47a9585363e05dd9932
Reviewed-on: https://boringssl-review.googlesource.com/13631
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
With the CRYPTO_BUFFER stuff, this API is now slightly more complex. Add
some tests as a sanity-check.
Change-Id: I9da20e3eb6391fc86ed215c5fabec71aa32ef56f
Reviewed-on: https://boringssl-review.googlesource.com/13620
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This is purely to support curl, which now has HTTPS proxy support that,
sadly, uses the BIO SSL. Don't use the BIO SSL for anything else.
Change-Id: I9ef6c9773ec87a11e0b5a93968386ac4b351986d
Reviewed-on: https://boringssl-review.googlesource.com/13600
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
The TLS 1.2 and 1.3 state machines do the exact same thing at the
beginning. Let them process the ClientHello extensions, etc., and
finalize the certificate in common code. Once we start picking
parameters, we begin to diverge. Everything before this point is
arguably part of setting up the configuration, which is
version-agnostic.
BUG=128
Change-Id: I293ea3087ecbc3267bd8cdaa011c98d26a699789
Reviewed-on: https://boringssl-review.googlesource.com/13562
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The version negotiation logic was a little bizarrely wedged in the
middle of the state machine. (We don't support server renegotiation, so
have_version is always false here.)
BUG=128
Change-Id: I9448dce374004b92e8bd5172c36a4e0eea51619c
Reviewed-on: https://boringssl-review.googlesource.com/13561
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
It has no other callers, now that the handshake is written elsewhere.
Change-Id: Ib04bbdc4a54fc7d01405d9b3f765fa9f186244de
Reviewed-on: https://boringssl-review.googlesource.com/13540
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
In TLS 1.2, resumption's benefits are more-or-less subsumed by False
Start. TLS 1.2 resumption lifetime is bounded by how much traffic we are
willing to encrypt without fresh key material, so the lifetime is short.
Renewal uses the same key, so we do not allow it to increase lifetimes.
In TLS 1.3, resumption unlocks 0-RTT. We do not implement psk_ke, so
resumption incorporates fresh key material into both encrypted traffic
(except for early data) and renewed tickets. Thus we are both more
willing to and more interested in longer lifetimes for tickets. Renewal
is also not useless. Thus in TLS 1.3, lifetime is bound separately by
the lifetime of a given secret as a psk_dhe_ke authenticator and the
lifetime of the online signature which authenticated the initial
handshake.
This change maintains two lifetimes on an SSL_SESSION: timeout which is
the renewable lifetime of this ticket, and auth_timeout which is the
non-renewable cliff. It also separates the TLS 1.2 and TLS 1.3 timeouts.
The old session timeout defaults and configuration apply to TLS 1.3, and
we define new ones for TLS 1.3.
Finally, this makes us honor the NewSessionTicket timeout in TLS 1.3.
It's no longer a "hint" in 1.3 and there's probably value in avoiding
known-useless 0-RTT offers.
BUG=120
Change-Id: Iac46d56e5a6a377d8b88b8fa31f492d534cb1b85
Reviewed-on: https://boringssl-review.googlesource.com/13503
Reviewed-by: Adam Langley <agl@google.com>
This special-case is almost unexposed (the timeout is initialized to the
default) except if the caller calls SSL_CTX_set_timeout(0). Preserve
that behavior by mapping 0 to SSL_DEFAULT_SESSION_TIMEOUT in
SSL_CTX_set_timeout but simplify the internal state.
Change-Id: Ice03a519c25284b925f1e0cf485f2d8c54dc5038
Reviewed-on: https://boringssl-review.googlesource.com/13502
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
It is impossible to have to call dispatch_alert when writing application
data. Now that we don't send warning alerts through ssl3_send_alert, all
alerts are closure alerts, which means attempts to write will fail.
This prunes a lot of dead code, avoiding the re-entrancy in the write
path. With that gone, tracking alert_dispatch is much more
straightforward.
BUG=146
Change-Id: Ie5fe677daee71e463d79562f3d2cea822a92581d
Reviewed-on: https://boringssl-review.googlesource.com/13500
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Fix this and add a test. Otherwise enabling TLS 1.3 will cause a server
to blow through its session cache.
Change-Id: I67edbc468faedfd94a6c30cf842af085a6543b50
Reviewed-on: https://boringssl-review.googlesource.com/13501
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This change moves the interface between |X509| and |CRYPTO_BUFFER| a
little further out, towards the API.
Change-Id: I1c014d20f12ad83427575843ca0b3bb22de1a694
Reviewed-on: https://boringssl-review.googlesource.com/13365
Reviewed-by: Adam Langley <agl@google.com>
The recent CRYPTO_BUFFER changes meant that |X509| objects passed to
SSL_CTX_add_extra_chain_cert would be |free|ed immediately. However,
some third-party code (at least serf and curl) continue to use the
|X509| even after handing over ownership.
In order to unblock things, keep the past |X509| around for a while to
paper over the issues with those libraries while we try and upstream
changes.
Change-Id: I832b458af9b265749fed964658c5c34c84d518df
Reviewed-on: https://boringssl-review.googlesource.com/13480
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: I44202457841f06a899e140f78ae8afa7ac720283
Reviewed-on: https://boringssl-review.googlesource.com/12600
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Move to explicit hashing everywhere, matching TLS 1.2 with TLS 1.3. The
ssl_get_message calls between all the handshake states are now all
uniform so, when we're ready, we can rewire the TLS 1.2 state machine to
look like the TLS 1.3 one. (ssl_get_message calls become an
ssl_hs_read_message transition, reuse_message becomes an ssl_hs_ok
transition.)
This avoids some nuisance in processing the ServerHello at the 1.2 / 1.3
transition.
The downside of explicit hashing is we may forget to hash something, but
this will fail to interop with our tests and anyone else, so we should
be able to catch it.
BUG=128
Change-Id: I01393943b14dfaa98eec2a78f62c3a41c29b3a0e
Reviewed-on: https://boringssl-review.googlesource.com/13266
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This is kind of annoying (even new state is needed to keep the layering
right). As part of aligning the read paths of the TLS 1.2 and TLS 1.3
state machine, we'll want to move to states calling
ssl_hash_current_message when the process the message, rather than when
the message is read. Right now the TLS 1.2 optional message story
(reuse_message) depends on all messages preceded by an optional message
using ssl_hash_message. For instance, if TLS 1.2 decided to place
CertificateStatus before ServerKeyExchange, we would not be able to
handle it.
However, V2ClientHello, by being handled in the message layer, relies on
ssl_get_message-driven hashing to replace the usual ClientHello hash
with a hash of something custom. This switches things so rather than
ClientHellos being always pre-hashed by the message layer, simulated
ClientHellos no-op ssl_hash_current_message.
This just replaces one hack with another (V2ClientHello is inherently
nasty), but this hack should be more compatible with future plans.
BUG=128
Change-Id: If807ea749d91e306a37bb2362ecc69b84bf224c9
Reviewed-on: https://boringssl-review.googlesource.com/13265
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This aligns the TLS 1.2 state machine closer with the TLS 1.3 state
machine. This is more work for the handshake, but ultimately the
plan is to take the ssl_get_message call out of the handshake (so it is
just the state machine rather than calling into BIO), so the parameters
need to be folded out as in TLS 1.3.
The WrongMessageType-* family of tests should make sure we don't miss
one of these.
BUG=128
Change-Id: I17a1e6177c52a7540b2bc6b0b3f926ab386c4950
Reviewed-on: https://boringssl-review.googlesource.com/13264
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
If an existing chain had a NULL placeholder for a leaf we could end up
trying to increment its reference count. That results in a crash at
configuration time. Found via the SSL_CTX API fuzzer.
BUG=oss-fuzz:480
Change-Id: I0ddc2cbde2e625015768f1bdc8da625e8a4f05fd
Reviewed-on: https://boringssl-review.googlesource.com/13383
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This was originally changed so that flush_flight could forward BIO_write
errors as-is, but we can and probably should still map BIO_flush errors.
This is unlikely to matter (every relevant BIO likely just has a no-op
flush which returns one), but, e.g., our file BIO returns 0, not -1, on
error.
We possibly should also be mapping BIO_write errors, but I'll leave that
alone for now. It's primarily BIO_read where the BIO return value must
be preserved due to error vs. EOF.
(We probably can just remove the BIO_flush calls altogether, but since
the buffer BIO forwarded the flush signal it would be a user-visible
behavior change to confirm.)
Change-Id: Ib495cc5d043867cf964f99b7ee4535114f7b2230
Reviewed-on: https://boringssl-review.googlesource.com/13367
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
(I split this change off to minimise the noise in future diffs that
actually do something meaningful.)
Change-Id: I7a054dcfc90a44ab5bb89b8f46704e5e3410e524
Reviewed-on: https://boringssl-review.googlesource.com/13364
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This change converts the |CERT| struct to holding certificates as binary
blobs, rather than in parsed form. The members for holding the parsed
form are still there, however, but are only used as a cache for the
event that someone asks us for a non-owning pointer to the parsed leaf
or chain.
Next steps:
* Move more functions in to ssl_x509.c
* Create an X509_OPS struct of function pointers that will hang off
the |SSL_METHOD| to abstract out the current calls to crypto/x509
operations.
BUG=chromium:671420
Change-Id: Ifa05d88c49a987fd561b349705c9c48f106ec868
Reviewed-on: https://boringssl-review.googlesource.com/13280
Reviewed-by: Adam Langley <agl@google.com>
This resolves a TODO, trims per-connection memory, and makes more sense.
These masks have nothing to do with certificate configuration.
Change-Id: I783e6158e51f58cce88e3e68dfa0ed965bdc894c
Reviewed-on: https://boringssl-review.googlesource.com/13368
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Until we've gotten it fully working, we should not mint any of these
SSL_SESSIONs, to avoid constraining future versions of our client code.
Notably, if any of our TLS 1.3 clients today serialized sessions, we
would need to rev the serialization format. Without opting into 0-RTT, a
TLS 1.3 client will create SSL_SESSIONs tagged as 0-RTT-capable but
missing important fields (ALPN, etc.). When that serialized session
makes its way to a future version of our client code, it would disagree
with the server about the ALPN value stored in the ticket and cause
interop failures.
I believe the only client code enabling TLS 1.3 right now is Chrome, and
the window is small, so it should be fine. But fix this now before it
becomes a problem.
Change-Id: Ie2b109f8d158017a6f3b4cb6169050d38a66b31c
Reviewed-on: https://boringssl-review.googlesource.com/13342
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Change-Id: I324743e7d1864fbbb9653209ff93e4da872c8d31
Reviewed-on: https://boringssl-review.googlesource.com/13340
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: Idc93fdca2f1c5c23e4ba48c4efed2edbad1e857b
Reviewed-on: https://boringssl-review.googlesource.com/12521
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
The TLS 1.2 state machine now looks actually much closer to the TLS 1.3
one on the write side. Although the write states still have a BIO-style
return, they don't actually send anything anymore. Only the BIO flush
state does. Reads are still integrated into the states themselves
though, so I haven't made it match TLS 1.3 yet.
BUG=72
Change-Id: I7708162efca13cd335723efa5080718a5f2808ab
Reviewed-on: https://boringssl-review.googlesource.com/13228
Reviewed-by: Adam Langley <agl@google.com>
The SSL code suffers from needing too many verbs for variations on
writing things without actually writing them. We used to have queuing
the message up to be written to the buffer BIO, writing to the buffer
BIO, and flushing the buffer BIO. (Reading, conversely, has a similar
mess of verbs.)
Now we just have adding to the pending flight and flushing the pending
flight, match the SSL_PROTOCOL_METHOD naming.
BUG=72
Change-Id: I332966928bf13f03dfb8eddd519c2fefdd7f24d4
Reviewed-on: https://boringssl-review.googlesource.com/13227
Reviewed-by: Adam Langley <agl@google.com>
Large chunks of contiguous messages can now be sent in a row. Notably,
the ServerHello flight involves a number of optional messages which can
now be collapsed into straight-line code.
BUG=72
Change-Id: I1429d22a12401aa0f811a04e495bd5d754c084a4
Reviewed-on: https://boringssl-review.googlesource.com/13226
Reviewed-by: Adam Langley <agl@google.com>
On the TLS side, we introduce a running buffer of ciphertext. Queuing up
pending data consists of encrypting the record into the buffer. This
effectively reimplements what the buffer BIO was doing previously, but
this resizes to fit the whole flight.
As part of this, rename all the functions to add to the pending flight
to be more uniform. This CL proposes "add_foo" to add to the pending
flight and "flush_flight" to drain it.
We add an add_alert hook for alerts but, for now, only the SSL 3.0
warning alert (sent mid-handshake) uses this mechanism. Later work will
push this down to the rest of the write path so closure alerts use it
too, as in DTLS. The intended end state is that all the ssl_buffer.c and
wpend_ret logic will only be used for application data and eventually
optionally replaced by the in-place API, while all "incidental" data
will be handled internally.
For now, the two buffers are mutually exclusive. Moving closure alerts
to "incidentals" will change this, but flushing application data early
is tricky due to wpend_ret. (If we call ssl_write_buffer_flush,
do_ssl3_write doesn't realize it still has a wpend_ret to replay.) That
too is all left alone in this change.
To keep the diff down, write_message is retained for now and will be
removed from the state machines in a follow-up change.
BUG=72
Change-Id: Ibce882f5f7196880648f25d5005322ca4055c71d
Reviewed-on: https://boringssl-review.googlesource.com/13224
Reviewed-by: Adam Langley <agl@google.com>
Instead, "writing" a message merely adds it to the outgoing_messages
structure. The code to write the flight then loops over it all and now
shares code with retransmission. The verbs here are all a little odd,
but they'll be fixed in later commits.
In doing so, this fixes a slight miscalculation of the record-layer
overhead when retransmitting a flight that spans two epochs. (We'd use
the encrypted epoch's overhead for the unencrypted epoch.)
BUG=72
Change-Id: I8ac897c955cc74799f8b5ca6923906e97d6dad17
Reviewed-on: https://boringssl-review.googlesource.com/13223
Reviewed-by: Adam Langley <agl@google.com>
This was replaced by the more general CLIENT_RANDOM scheme that records
the master secret. Support was added in Wireshark 1.8.0, released in
June 2012. At this point, ECDHE is sufficiently widely deployed that
anyone that cares about this feature must have upgraded their Wireshark
by now.
Change-Id: I9b708f245ec8728c1999daf91aca663be7d25661
Reviewed-on: https://boringssl-review.googlesource.com/13263
Reviewed-by: David Benjamin <davidben@google.com>
This will let us avoid a scratch buffer when assembling DTLS handshake
packets in the write_message-less flow.
BUG=72
Change-Id: I15e78efe3a9e3933c307e599f0043427330f4a9e
Reviewed-on: https://boringssl-review.googlesource.com/13262
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We need to suppress a few tests on the system Android build until
RSA-PSS is shipped there.
Change-Id: I5843997aae9fa499ec08d76f44fdf3b523599e1c
Reviewed-on: https://boringssl-review.googlesource.com/13267
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: Ifc28887cbf91c7a80bdaf56e3bf80b2f8cfa7d53
Reviewed-on: https://boringssl-review.googlesource.com/13260
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Eventually, all uses of crypto/x509 will be from ssl_x509.c, but this is
just a start.
Change-Id: I2f38cdcbf18b1f26add0aac10a70af10a79dee0e
Reviewed-on: https://boringssl-review.googlesource.com/13242
Reviewed-by: Adam Langley <agl@google.com>
This is the first part to removing the buffer BIO. The eventual end
state is the SSL_PROTOCOL_METHOD is responsible for maintaining one
flight's worth of messages. In TLS, it will just be a buffer containing
the flight's ciphertext. In DTLS, it's the existing structure for
retransmit purposes. There will be hooks:
- add_message (synchronous)
- add_change_cipher_spec (synchronous)
- add_warning_alert (synchronous; needed until we lose SSLv3 client auth
and TLS 1.3 draft 18; draft 19 will switch end_of_early_data to a
handshake message)
- write_flight (BIO; flush_flight will be renamed to this)
This also preserves the exact return value of BIO_flush. Eventually all
the BIO_write calls will be hidden behind BIO_flush to, to be consistent
with other BIO-based calls, preserve the return value.
BUG=72
Change-Id: I74cd23759a17356aab3bb475a8ea42bd2cd115c9
Reviewed-on: https://boringssl-review.googlesource.com/13222
Reviewed-by: Adam Langley <agl@google.com>
EVP_parse_public_key already acts like CBS_get_* in that it peels one
element off and leaves a remainder.
Change-Id: Ic90952785005ed81664a6f46503b13ecd293176c
Reviewed-on: https://boringssl-review.googlesource.com/13045
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
For now, this is the laziest conversion possible. The intent is to just
get the build setup ready so that we can get everything working in our
consumers. The intended end state is:
- The standalone build produces three test targets, one per library:
{crypto,ssl,decrepit}_tests.
- Each FOO_test is made up of:
FOO/**/*_test.cc
crypto/test/gtest_main.cc
test_support
- generate_build_files.py emits variables crypto_test_sources and
ssl_test_sources. These variables are populated with FindCFiles,
looking for *_test.cc.
- The consuming file assembles those variables into the two test targets
(plus decrepit) from there. This avoids having generate_build_files.py
emit actual build rules.
- Our standalone builders, Chromium, and Android just run the top-level
test targets using whatever GTest-based reporting story they have.
In transition, we start by converting one of two tests in each library
to populate the three test targets. Those are added to all_tests.json
and all_tests.go hacked to handle them transparently. This keeps our
standalone builder working.
generate_build_files.py, to start with, populates the new source lists
manually and subtracts them out of the old machinery. We emit both for
the time being. When this change rolls in, we'll write all the build
glue needed to build the GTest-based tests and add it to consumers'
continuous builders.
Next, we'll subsume a file-based test and get the consumers working with
that. (I.e. make sure the GTest targets can depend on a data file.)
Once that's all done, we'll be sure all this will work. At that point,
we start subsuming the remaining tests into the GTest targets and,
asynchronously, rewriting tests to use GTest properly rather than
cursory conversion here.
When all non-GTest tests are gone, the old generate_build_files.py hooks
will be removed, consumers updated to not depend on them, and standalone
builders converted to not rely on all_tests.go, which can then be
removed. (Unless bits end up being needed as a malloc test driver. I'm
thinking we'll want to do something with --gtest_filter.)
As part of this CL, I've bumped the CMake requirements (for
target_include_directories) and added a few suppressions for warnings
that GTest doesn't pass.
BUG=129
Change-Id: I881b26b07a8739cc0b52dbb51a30956908e1b71a
Reviewed-on: https://boringssl-review.googlesource.com/13232
Reviewed-by: Adam Langley <agl@google.com>
It's not completely clear to me why select_cetificate_cb behaves the way it
does, however not only is it confusing, but it makes assumptions about the
application using BoringSSL (it's not always possible to implement custom
logic outside of the callbacks provided by libssl), that make this callback
somewhat useless.
Case in point, the callback can be used for changing min/max protocol versions
based on per-site policies, and select_certificate_cb is the only place where
SSL_set_min/max_proto_version() can be used (e.g. you can't call them in
cert_cb because it's too late), but the decision on the specific versions to
use might depend on configuration that needs retrieving asynchronously from
over the network, which requires re-running the callback multiple times.
Change-Id: Ia8e151b163628545373e7fd1f327e9af207478a6
Reviewed-on: https://boringssl-review.googlesource.com/13000
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
We have a test somewhere which tries to read off of it. Align the getter
roughly with upstream's SSL_SESSION_get0_id_context (which we don't
currently expose).
BUG=6
Change-Id: Iab240868838ba56c1f08d112888d9536574347b4
Reviewed-on: https://boringssl-review.googlesource.com/12636
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>
Before RFC 7539 we had a ChaCha20-Poly1305 cipher suite that had a 64/64
nonce/counter split (as DJB's original ChaCha20 did). RFC 7539 changed
that to 96/32 and we've supported both for some time.
This change removes the old version and the TLS cipher suites that used
it.
BUG=chromium:682816
Change-Id: I2345d6db83441691fe0c1ab6d7c6da4d24777849
Reviewed-on: https://boringssl-review.googlesource.com/13203
Reviewed-by: Adam Langley <agl@google.com>
This reverts commit def9b46801.
(I should have uploaded a new version before sending to the commit queue.)
Change-Id: Iaead89c8d7fc1f56e6294d869db9238b467f520a
Reviewed-on: https://boringssl-review.googlesource.com/13202
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>
TLS 1.3 forbids warning alerts, and sending these is a bad idea. Per RFC
6066:
If the server understood the ClientHello extension but
does not recognize the server name, the server SHOULD take one of two
actions: either abort the handshake by sending a fatal-level
unrecognized_name(112) alert or continue the handshake. It is NOT
RECOMMENDED to send a warning-level unrecognized_name(112) alert,
because the client's behavior in response to warning-level alerts is
unpredictable.
The motivation is to cut down on the number of places where we send
non-closing alerts. We can't remove them yet (SSL 3.0 and TLS 1.3 draft
18 need to go), but eventually this can be a simplifying assumption.
Already this means DTLS never sends warning alerts, which is good
because DTLS can't retransmit them.
Change-Id: I577a1eb9c23e66d28235c0fbe913f00965e19486
Reviewed-on: https://boringssl-review.googlesource.com/13221
Reviewed-by: Adam Langley <agl@google.com>
