SSL_get_signature_nid() -- local signature algorithm
SSL_get_signature_type_nid() -- local signature algorithm key type
SSL_get_peer_tmp_key() -- Peer key-exchange public key
SSL_get_tmp_key -- local key exchange public key
Aliased pre-existing SSL_get_server_tmp_key(), which was formerly
just for clients, to SSL_get_peer_tmp_key(). Changed internal
calls to use the new name.
Reviewed-by: Matt Caswell <matt@openssl.org>
SSL(_CTX)?_set_client_CA_list() was a server side only function in 1.1.0.
If it was called on the client side then it was ignored. In 1.1.1 it now
makes sense to have a CA list defined for both client and server (the
client now sends it the the TLSv1.3 certificate_authorities extension).
Unfortunately some applications were using the same SSL_CTX for both
clients and servers and this resulted in some client ClientHellos being
excessively large due to the number of certificate authorities being sent.
This commit seperates out the CA list updated by
SSL(_CTX)?_set_client_CA_list() and the more generic
SSL(_CTX)?_set0_CA_list(). This means that SSL(_CTX)?_set_client_CA_list()
still has no effect on the client side. If both CA lists are set then
SSL(_CTX)?_set_client_CA_list() takes priority.
Fixes#7411
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7503)
(cherry picked from commit 9873297900)
TLSv1.3 is more restrictive about the curve used. There must be a matching
sig alg defined for that curve. Therefore if we are using some other curve
in our certificate then we should not negotiate TLSv1.3.
Fixes#7435
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7442)
(cherry picked from commit de4dc59802)
use_ecc() was always returning 1 because there are default (TLSv1.3)
ciphersuites that use ECC - even if those ciphersuites are disabled by
other options.
Fixes#7471
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/7479)
(cherry picked from commit 589b6227a8)
Commit 9ef9088c15 switched the SSL/SSL_CTX
statistics counters to using Thread-Sanitizer-friendly primitives.
However, it erroneously converted an addition of -1
(for s->session_ctx->stats.sess_accept) to an addition of +1, since that
is the only counter API provided by the internal tsan_assist.h header
until the previous commit. This means that for each accepted (initial)
connection, the session_ctx's counter would get doubly incremented, and the
(switched) ctx's counter would also get incremented.
Restore the counter decrement so that each accepted connection increments
exactly one counter exactly once (in net effect).
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7464)
(cherry picked from commit 2aaa0b146b)
In TLSv1.2 and below a CertificateRequest is sent after the Certificate
from the server. This means that by the time the client_cert_cb is called
on receipt of the CertificateRequest a call to SSL_get_peer_certificate()
will return the server certificate as expected. In TLSv1.3 a
CertificateRequest is sent before a Certificate message so calling
SSL_get_peer_certificate() returns NULL.
To workaround this we delay calling the client_cert_cb until after we
have processed the CertificateVerify message, when we are doing TLSv1.3.
Fixes#7384
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/7413)
(cherry picked from commit e45620140f)
Since 1fb9fdc30 we may attempt to buffer a record from the next epoch
that has already been buffered. Prior to that this never occurred.
We simply ignore a failure to buffer a duplicated record.
Fixes#6902
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7414)
(cherry picked from commit 840facc3cc)
Previously when a ClientHello arrives with a valid cookie using
DTLSv1_listen() we only "peeked" at the message and left it on the
underlying fd. This works fine for single threaded applications but for
multi-threaded apps this does not work since the fd is typically reused for
the server thread, while a new fd is created and connected for the client.
By "peeking" we leave the message on the server fd, and consequently we
think we've received another valid ClientHello and so we create yet another
fd for the client, and so on until we run out of fds.
In this new approach we remove the ClientHello and buffer it in the SSL
object.
Fixes#6934
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/7375)
(cherry picked from commit 079ef6bd53)
Rather than using init_buf we use the record layer read and write buffers
in DTLSv1_listen(). These seem more appropriate anyway and will help with
the next commit.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/7375)
(cherry picked from commit 2fc4c77c3f)
The formula used for this is now
kVarianceBlocks = ((255 + 1 + md_size + md_block_size - 1) / md_block_size) + 1
Notice that md_block_size=64 for SHA256, which results on the
magic constant kVarianceBlocks = 6.
However, md_block_size=128 for SHA384 leading to kVarianceBlocks = 4.
CLA:trivial
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7342)
(cherry picked from commit cb8164b05e)
If using an old style TLSv1.2 PSK callback then the maximum possible PSK
len is PSK_MAX_PSK_LEN (256) - not 64.
Fixes#7261
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7267)
(cherry picked from commit f39a02c68a)
Historically SSL_CTX_set_ssl_version() has reset the cipher list
to the default. Splitting TLS 1.3 ciphers to be tracked separately
caused a behavior change, in that TLS 1.3 cipher configuration was
preserved across calls to SSL_CTX_set_ssl_version(). To restore commensurate
behavior with the historical behavior, set the ciphersuites to the default as
well as setting the cipher list to the default.
Closes: #7226
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7270)
(cherry picked from commit 2340ed277b)
PR #3783 introduce coded to reset the server side SNI state in
SSL_do_handshake() to ensure any erroneous config time SNI changes are
cleared. Unfortunately SSL_do_handshake() can be called mid-handshake
multiple times so this is the wrong place to do this and can mean that
any SNI data is cleared later on in the handshake too.
Therefore move the code to a more appropriate place.
Fixes#7014
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/7149)
Ideally, SSL_get_servername() would do exactly as it is documented
and return exactly what the client sent (i.e., what we currently
are stashing in the SSL's ext.hostname), without needing to refer
to an SSL_SESSION object. For historical reasons, including the
parsed SNI value from the ClientHello originally being stored in the
SSL_SESSION's ext.hostname field, we have had references to the
SSL_SESSION in this function. We cannot fully excise them due to
the interaction between user-supplied callbacks and TLS 1.2 resumption
flows, where we call all callbacks but the client did not supply an
SNI value. Existing callbacks expect to receive a valid SNI value
in this case, so we must fake one up from the resumed session in
order to avoid breakage.
Otherwise, greatly simplify the implementation and just return the
value in the SSL, as sent by the client.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7115)
Commit 1c4aa31d79 modified the state machine
to clean up stale ext.hostname values from SSL objects in the case when
SNI was not negotiated for the current handshake. This is natural from
the TLS perspective, since this information is an extension that the client
offered but we ignored, and since we ignored it we do not need to keep it
around for anything else.
However, as documented in https://github.com/openssl/openssl/issues/7014 ,
there appear to be some deployed code that relies on retrieving such an
ignored SNI value from the client, after the handshake has completed.
Because the 1.1.1 release is on a stable branch and should preserve the
published ABI, restore the historical behavior by retaining the ext.hostname
value sent by the client, in the SSL structure, for subsequent retrieval.
[extended tests]
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7115)
The is_tls13_capable() function should not return 0 if no certificates
are configured directly because a certificate callback is present.
Fixes#7140
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7141)
If we've sent a close_notify then we are restricted about what we can do
in response to handshake messages that we receive. However we can sensibly
process NewSessionTicket messages. We can also process a KeyUpdate message
as long as we also ignore any request for us to update our sending keys.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7114)
If we have selected a ciphersuite using RSA key exchange then we must
not attempt to use an RSA-PSS cert for that.
Fixes#7059
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7099)
Treat a connection using an external PSK like we would a resumption and
send a single NewSessionTicket afterwards.
Fixes#6941
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7097)
If a client sends data to a server and then immediately closes without
waiting to read the NewSessionTickets then the server can receive EPIPE
when trying to write the tickets and never gets the opportunity to read
the data that was sent. Therefore we ignore EPIPE when writing out the
tickets in TLSv1.3
Fixes#6904
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6944)
They add a single item, so the names give a false impression of what
they do, making them hard to remember. Better to give them a somewhat
better name.
Fixes#6930
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6931)
Fixes#6994
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Yang <yang.yang@baishancloud.com>
(Merged from https://github.com/openssl/openssl/pull/7009)
We need to ensure that the min-max version range we use when constructing
the ClientHello is the same range we use when we validate the version
selected by the ServerHello. Otherwise this may appear as a fallback or
downgrade.
Fixes#6964
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7013)
The TLS-1.3 ciphersuites must not be blocked by @SECLEVEL=3 even
though they are not explicitly marked as using DH/ECDH.
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6959)
We already have SSL_set_post_handshake_auth(). This just adds the SSL_CTX
equivalent.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6938)
Having post handshake auth automatically switched on breaks some
applications written for TLSv1.2. This changes things so that an explicit
function call is required for a client to indicate support for
post-handshake auth.
Fixes#6933.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6938)
A client that has fallen back could detect an inappropriate fallback if
the TLSv1.3 downgrade protection sentinels are present.
Fixes#6756
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6894)
At certain points in the handshake we could receive either a plaintext or
an encrypted alert from the client. We should tolerate both where
appropriate.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6887)
If we sent early_data and then received back an HRR, the enc_write_ctx
was stale resulting in errors if an alert needed to be sent.
Thanks to Quarkslab for reporting this.
In any case it makes little sense to encrypt alerts using the
client_early_traffic_secret, so we add special handling for alerts sent
after early_data. All such alerts are sent in plaintext.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6887)
