This is adapted from BoringSSL commit 2f87112b963.
This fixes a number of bugs where the existence of bbio was leaked in the
public API and broke things.
- SSL_get_wbio returned the bbio during the handshake. It must always return
the BIO the consumer configured. In doing so, some internal accesses of
SSL_get_wbio should be switched to ssl->wbio since those want to see bbio.
- The logic in SSL_set_rfd, etc. (which I doubt is quite right since
SSL_set_bio's lifetime is unclear) would get confused once wbio got
wrapped. Those want to compare to SSL_get_wbio.
- If SSL_set_bio was called mid-handshake, bbio would get disconnected and
lose state. It forgets to reattach the bbio afterwards. Unfortunately,
Conscrypt does this a lot. It just never ended up calling it at a point
where the bbio would cause problems.
- Make more explicit the invariant that any bbio's which exist are always
attached. Simplify a few things as part of that.
RT#4572
Reviewed-by: Richard Levitte <levitte@openssl.org>
Fix some indentation at the same time
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1292)
- Always process ALPN (previously there was an early return in the
certificate status handling)
- Don't send a duplicate alert. Previously, both
ssl_check_clienthello_tlsext_late and its caller would send an
alert. Consolidate alert sending code in the caller.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Continuing from the previous commit. Refactor tls_process_key_exchange() to
split out into a separate function the ECDHE aspects.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Continuing from the previous commit. Refactor tls_process_key_exchange() to
split out into a separate function the DHE aspects.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Continuing from the previous commit. Refactor tls_process_key_exchange() to
split out into a separate function the SRP aspects.
Reviewed-by: Richard Levitte <levitte@openssl.org>
The tls_process_key_exchange() function is too long. This commit starts
the process of splitting it up by moving the PSK preamble code to a
separate function.
Reviewed-by: Richard Levitte <levitte@openssl.org>
The function tls_process_key_exchange() is too long. This commit moves
the PSK preamble processing out to a separate function.
Reviewed-by: Richard Levitte <levitte@openssl.org>
If the SSL_SESS_CACHE_NO_INTERNAL_STORE cache mode is used then we weren't
removing sessions from the external cache, e.g. if an alert occurs the
session is supposed to be automatically removed.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Don't call strncpy with strlen of the source as the length. Don't call
strlen multiple times. Eventually we will want to replace this with a proper
PACKET style handling (but for construction of PACKETs instead of just
reading them as it is now). For now though this is safe because
PSK_MAX_IDENTITY_LEN will always fit into the destination buffer.
This addresses an OCAP Audit issue.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Continuing previous commit to break up the
tls_construct_client_key_exchange() function. This splits out the SRP
code.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Continuing previous commit to break up the
tls_construct_client_key_exchange() function. This splits out the GOST
code.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Continuing previous commit to break up the
tls_construct_client_key_exchange() function. This splits out the ECDHE
code.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Continuing previous commit to break up the
tls_construct_client_key_exchange() function. This splits out the DHE
code.
Reviewed-by: Richard Levitte <levitte@openssl.org>
The tls_construct_client_key_exchange() function is too long. This splits
out the construction of the PSK pre-amble into a separate function as well
as the RSA construction.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Continuing from the previous commits, this splits out the GOST code into
a separate function from the process CKE code.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Continuing from the previous commits, this splits out the ECDHE code into
a separate function from the process CKE code.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Continuing from the previous commit, this splits out the DHE code into
a separate function from the process CKE code.
Reviewed-by: Richard Levitte <levitte@openssl.org>
The tls_process_client_key_exchange() function is far too long. This
splits out the PSK preamble processing, and the RSA processing into
separate functions.
Reviewed-by: Richard Levitte <levitte@openssl.org>
In preparation for splitting this function up into smaller functions this
commit reduces the scope of some of the variables to only be in scope for
the algorithm specific parts. In some cases that makes the error handling
more verbose than it needs to be - but we'll clean that up in a later
commit.
Reviewed-by: Richard Levitte <levitte@openssl.org>
The logic testing whether a CKE message is allowed or not was a little
difficult to follow. This tries to clean it up.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
The static function key_exchange_expected() used to return -1 on error.
Commit 361a119127 changed that so that it can never fail. This means that
some tidy up can be done to simplify error handling in callers of that
function.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
Having received a ClientKeyExchange message instead of a Certificate we
know that we are not going to receive a CertificateVerify message. This
means we can free up the handshake_buffer. However we better call
ssl3_digest_cached_records() instead of just freeing it up, otherwise we
later try and use it anyway and a core dump results. This could happen,
for example, in SSLv3 where we send a CertificateRequest but the client
sends no Certificate message at all. This is valid in SSLv3 (in TLS
clients are required to send an empty Certificate message).
Found using the BoringSSL test suite.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
In TLS if the server sends a CertificateRequest and the client does not
provide one, if the server cannot continue it should send a
HandshakeFailure alert. In SSLv3 the same should happen, but instead we
were sending an UnexpectedMessage alert. This is incorrect - the message
isn't unexpected - it is valid for the client not to send one - its just
that we cannot continue without one.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
Move the preparation of the client certificate to be post processing work
after reading the CertificateRequest message rather than pre processing
work prior to writing the Certificate message. As part of preparing the
client certificate we may discover that we do not have one available. If
we are also talking SSLv3 then we won't send the Certificate message at
all. However, if we don't discover this until we are about to send the
Certificate message it is too late and we send an empty one anyway. This
is wrong for SSLv3.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
The set0 setters take ownership of their arguments, so the values should
be set to NULL to avoid a double-free in the cleanup block should
ssl_security(SSL_SECOP_TMP_DH) fail. Found by BoringSSL's WeakDH test.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1299)
We calculate the size required for the ServerKeyExchange message and then
call BUF_MEM_grow_clean() on the buffer. However we fail to take account of
2 bytes required for the signature algorithm and 2 bytes for the signature
length, i.e. we could overflow by 4 bytes. In reality this won't happen
because the buffer is pre-allocated to a large size that means it should be
big enough anyway.
Addresses an OCAP Audit issue.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1264)
Using RSA_PKCS1_PADDING with RSA_private_decrypt is inherently unsafe.
The API requires writing output on success and touching the error queue
on error. Thus, although the padding check itself is constant-time as of
294d1e36c2, and the logic after the
decryption in the SSL code is constant-time as of
adb46dbc6d, the API boundary in the middle
still leaks whether the padding check succeeded, giving us our
much-loved Bleichenbacher padding oracle.
Instead, PKCS#1 padding must be handled by the caller which uses
RSA_NO_PADDING, in timing-sensitive code integrated with the
Bleichenbacher mitigation. Removing PKCS#1 padding in constant time is
actually much simpler when the expected length is a constant (and if
it's not a constant, avoiding a padding oracle seems unlikely), so just
do it inline.
Signed-off-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Rich Salz <rsalz@openssl.org>
GH: #1222
When session tickets are used, it's possible that SNI might swtich the
SSL_CTX on an SSL. Normally, this is not a problem, because the
initial_ctx/session_ctx are used for all session ticket/id processes.
However, when the SNI callback occurs, it's possible that the callback
may update the options in the SSL from the SSL_CTX, and this could
cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things
can happen:
1. The session ticket TLSEXT may not be written when the ticket expected
flag is set. The state machine transistions to writing the ticket, and
the client responds with an error as its not expecting a ticket.
2. When creating the session ticket, if the ticket key cb returns 0
the crypto/hmac contexts are not initialized, and the code crashes when
trying to encrypt the session ticket.
To fix 1, if the ticket TLSEXT is not written out, clear the expected
ticket flag.
To fix 2, consider a return of 0 from the ticket key cb a recoverable
error, and write a 0 length ticket and continue. The client-side code
can explicitly handle this case.
Fix these two cases, and add unit test code to validate ticket behavior.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1098)
The ssl3_init_finished_mac() function can fail, in which case we need to
propagate the error up through the stack.
RT#3198
Reviewed-by: Rich Salz <rsalz@openssl.org>
In the new state machine if using nbio and we get the header of a
handshake message is one record with the body in the next, with an nbio
event in the middle, then the connection was failing. This is because
s->init_num was getting reset. We should only reset it after we have
read the whole message.
RT#4394
Reviewed-by: Andy Polyakov <appro@openssl.org>
