Use cipher suite values instead of IDs.

OpenSSL has had the concept of cipher IDs, which were a way of working
around overlapping cipher suite values between SSLv2 and SSLv3. Given
that we no longer

Use cipher suite values instead of IDs.

OpenSSL has had the concept of cipher IDs, which were a way of working
around overlapping cipher suite values between SSLv2 and SSLv3. Given
that we no longer have to deal with this issue, replace the use of IDs
with cipher suite values. In particular, this means that we can stop
mapping back and forth between the two, simplifying things considerably.

While here, remove the 'valid' member of the SSL_CIPHER. The ssl3_ciphers[]
table is no longer mutable, meaning that ciphers cannot be disabled at
runtime (and we have `#if 0' if we want to do it at compile time).

Clean up the comments and add/update RFC references for cipher suites.

ok tb@

show more ...

Remove cipher from SSL_SESSION.

For a long time SSL_SESSION has had both a cipher ID and a pointer to
an SSL_CIPHER (and not both are guaranteed to be populated). There is also
a pointer to an SSL_C

Remove cipher from SSL_SESSION.

For a long time SSL_SESSION has had both a cipher ID and a pointer to
an SSL_CIPHER (and not both are guaranteed to be populated). There is also
a pointer to an SSL_CIPHER in the SSL_HANDSHAKE that denotes the cipher
being used for this connection. Some code has been using the cipher from
SSL_SESSION and some code has been using the cipher from SSL_HANDSHAKE.

Remove cipher from SSL_SESSION and use the version in SSL_HANDSHAKE
everywhere. If resuming from a session then we need to use the SSL_SESSION
cipher ID to set the SSL_HANDSHAKE cipher. And we still need to ensure that
we update the cipher ID in the SSL_SESSION whenever the SSL_HANDSHAKE
cipher changes (this only occurs in a few places).

ok tb@

show more ...

Move client ciphers from SSL_SESSION to SSL_HANDSHAKE.

SSL_SESSION has a 'ciphers' member which contains a list of ciphers
that were advertised by the client. Move this from SSL_SESSION to
SSL_HANDS

Move client ciphers from SSL_SESSION to SSL_HANDSHAKE.

SSL_SESSION has a 'ciphers' member which contains a list of ciphers
that were advertised by the client. Move this from SSL_SESSION to
SSL_HANDSHAKE and rename it to match reality.

ok tb@

show more ...

Convert EVP_Digest{Sign,Verify}* to one-shot for TLSv1.3

Using one-shot EVP_DigestSign() and EVP_DigestVerify() is slightly shorter
and is needed for Ed25519 support.

ok jsing

Make internal header file names consistent

Libcrypto currently has a mess of *_lcl.h, *_locl.h, and *_local.h names
used for internal headers. Move all these headers we inherited from
OpenSSL to *_l

Make internal header file names consistent

Libcrypto currently has a mess of *_lcl.h, *_locl.h, and *_local.h names
used for internal headers. Move all these headers we inherited from
OpenSSL to *_local.h, reserving the name *_internal.h for our own code.
Similarly, move dtls_locl.h and ssl_locl.h to dtls_local and ssl_local.h.
constant_time_locl.h is moved to constant_time.h since it's special.

Adjust all .c files in libcrypto, libssl and regress.

The diff is mechanical with the exception of tls13_quic.c, where
#include <ssl_locl.h> was fixed manually.

discussed with jsing,
no objection bcook

show more ...

Get rid of SSL_CTX_INTERNAL and SSL_INTERNAL.

These are no longer necessary due to SSL_CTX and SSL now being fully
opaque. Merge SSL_CTX_INTERNAL back into SSL_CTX and SSL_INTERNAL back
into SSL.

P

Get rid of SSL_CTX_INTERNAL and SSL_INTERNAL.

These are no longer necessary due to SSL_CTX and SSL now being fully
opaque. Merge SSL_CTX_INTERNAL back into SSL_CTX and SSL_INTERNAL back
into SSL.

Prompted by tb@

show more ...

Allow TLSv1.3 clients to send CCS without middlebox compatibility mode.

While RFC 8446 is clear about what legacy session identifiers can be sent
by a TLSv1.3 client and how middlebox compatibility

Allow TLSv1.3 clients to send CCS without middlebox compatibility mode.

While RFC 8446 is clear about what legacy session identifiers can be sent
by a TLSv1.3 client and how middlebox compatibility mode is requested, it
is delightfully vague about the circumstances under which a client is
permitted to send CCS messages. While it does not make sense for a client
to send CCS messages when they are not requesting middlebox compatibility
mode, it is not strictly forbidden by the RFC and at least one (unknown)
TLSv1.3 stack has been observed to do this in the wild.

Revert part of the previous change and allow clients to send CCS messages,
even if they are not requesting middlebox compatibility mode.

Found the hard way by florian@

ok tb@

show more ...

Be stricter with middlebox compatibility mode in the TLSv1.3 server.

Only allow a TLSv1.3 client to request middlebox compatibility mode if
this is permitted. Ensure that the legacy session identifi

Be stricter with middlebox compatibility mode in the TLSv1.3 server.

Only allow a TLSv1.3 client to request middlebox compatibility mode if
this is permitted. Ensure that the legacy session identifier is either
zero length or 32 bytes in length. Additionally, only allow CCS messages
on the server side if the client actually requested middlebox compatibility
mode.

ok tb@

show more ...

Deduplicate peer certificate chain processing code.

Rather than reimplement this in each TLS client and server, deduplicate it
into a single function. Furthermore, rather than dealing with the API
h

Deduplicate peer certificate chain processing code.

Rather than reimplement this in each TLS client and server, deduplicate it
into a single function. Furthermore, rather than dealing with the API
hazard that is SSL_get_peer_cert_chain() in this code, simply produce two
chains - one that has the leaf and one that does not.
SSL_get_peer_cert_chain() can then return the appropriate one.

This also moves the peer cert chain from the SSL_SESSION to the
SSL_HANDSHAKE, which makes more sense since it is not available on
resumption.

ok tb@

show more ...

Provide QUIC encryption levels.

QUIC wants to know what "encryption level" handshake messages should be
sent at. Provide an ssl_encryption_level_t enum (via BoringSSL) that
defines these (of course

Provide QUIC encryption levels.

QUIC wants to know what "encryption level" handshake messages should be
sent at. Provide an ssl_encryption_level_t enum (via BoringSSL) that
defines these (of course quictls decided to make this an
OSSL_ENCRYPTION_LEVEL typedef, so provide that as well).

Wire these through to tls13_record_layer_set_{read,write}_traffic_key() so
that they can be used in upcoming commits.

ok tb@

show more ...

Rename uses 'curve' to 'group' and rework tls1 group API.

This reworks various tls1_ curve APIs to indicate success via a boolean
return value and move the output to an out parameter. This makes the

Rename uses 'curve' to 'group' and rework tls1 group API.

This reworks various tls1_ curve APIs to indicate success via a boolean
return value and move the output to an out parameter. This makes the
caller code easier and more consistent.

Based on a suggestion by jsing

ok jsing

show more ...

Tweak a comment using review feedback from jsing

Ensure that a client who sent a PSK extension has also sent a PSK
key exchange mode extension, as required by RFC 8446, 4.2.9.

ok jsing

Cleanup/simplify ssl_cert_type()

Remove the X509 argument as it is unused - this was passed so that
ssl_cert_type() can get the public key from the X509 object if the
EVP_PKEY argument is NULL, howe

Cleanup/simplify ssl_cert_type()

Remove the X509 argument as it is unused - this was passed so that
ssl_cert_type() can get the public key from the X509 object if the
EVP_PKEY argument is NULL, however this is never the case.

ok tb@

show more ...

Remove peer_pkeys from SSL_SESSION.

peer_pkeys comes from some world where peers can send multiple certificates
- in fact, one of each known type. Since we do not live in such a world,
get rid of pe

Remove peer_pkeys from SSL_SESSION.

peer_pkeys comes from some world where peers can send multiple certificates
- in fact, one of each known type. Since we do not live in such a world,
get rid of peer_pkeys and simply use peer_cert instead (in both TLSv1.2
and TLSv1.3, both clients and servers can only send a single leaf
(aka end-entity) certificate).

ok inoguchi@ tb@

show more ...

Rename 'peer' to 'peer_cert' in SSL_SESSION.

The 'peer' member of SSL_SESSION is the leaf/end-entity certificate
provided by our peer. Rename it since 'peer' on its own is unhelpful.

ok inoguchi@ t

Rename 'peer' to 'peer_cert' in SSL_SESSION.

The 'peer' member of SSL_SESSION is the leaf/end-entity certificate
provided by our peer. Rename it since 'peer' on its own is unhelpful.

ok inoguchi@ tb@

show more ...

Merge SESS_CERT into SSL_SESSION.

There is no reason for SESS_CERT to exist - remove it and merge its members
into SSL_SESSION for the time being. More clean up to follow.

ok inoguchi@ tb@

Rename CERT to SSL_CERT and CERT_PKEY to SSL_CERT_PKEY.

Nearly all structs in libssl start with an SSL_ suffix, rename CERT and
CERT_PKEY for consistency.

ok inoguchi@ tb@

Convert legacy server to tls_key_share.

This requires a few more additions to the DHE key share code - we need to
be able to either set the DHE parameters or specify the number of key bits
for use w

Convert legacy server to tls_key_share.

This requires a few more additions to the DHE key share code - we need to
be able to either set the DHE parameters or specify the number of key bits
for use with auto DHE parameters. Additionally, we need to be able to
serialise the DHE parameters to send to the client.

This removes the infamous 'tmp' struct from ssl3_state_internal_st.

ok inoguchi@ tb@

show more ...

Rename tls13_key_share to tls_key_share.

In preparation to use the key share code in both the TLSv1.3 and legacy
stacks, rename tls13_key_share to tls_key_share, moving it into the shared
handshake

Rename tls13_key_share to tls_key_share.

In preparation to use the key share code in both the TLSv1.3 and legacy
stacks, rename tls13_key_share to tls_key_share, moving it into the shared
handshake struct. Further changes will then allow the legacy stack to make
use of the same code for ephemeral key exchange.

ok inoguchi@ tb@

show more ...

Correct SSL_get_peer_cert_chain() when used with the TLSv1.3 stack.

Due to a wonderful API inconsistency, a client includes the peer's leaf
certificate in the stored certificate chain, while a serve

Correct SSL_get_peer_cert_chain() when used with the TLSv1.3 stack.

Due to a wonderful API inconsistency, a client includes the peer's leaf
certificate in the stored certificate chain, while a server does not.

Found due to a haproxy test failure reported by Ilya Shipitsin.

ok tb@

show more ...

libssl: stop reaching into the X509 struct and simplify some code by
using X509_get_key_usage().

ok beck jsing

Fold SSL_SESSION_INTERNAL back into SSL_SESSION.

ok beck@ tb@

Provide a way to determine our maximum legacy version.

With the introduction of TLSv1.3, we need the ability to determine our
maximum legacy version and to track our peer's maximum legacy version.
T

Provide a way to determine our maximum legacy version.

With the introduction of TLSv1.3, we need the ability to determine our
maximum legacy version and to track our peer's maximum legacy version.
This is needed for both the TLS record layer when using TLSv1.3, plus
it is needed for RSA key exhange in TLS prior to TLSv1.3, where the
maximum legacy version is incorporated in the pre-master secret to
avoid downgrade attacks.

This unbreaks RSA KEX for the TLS client when the non-version specific
method is used with TLSv1.0 or TLSv1.1 (clearly no one does this).

ok tb@

show more ...

Use X509_STORE_CTX_get0_chain() instead of grabbing the chain directly
out of the X509_STORE_CTX.

ok jsing