Merge SSL_METHOD_INTERNAL into SSL_METHOD.

Now that SSL_METHOD is opaque and in internal headers, we can remove
SSL_METHOD_INTERNAL by merging it back into SSL_METHOD.

ok tb@

Provide a ssl_sigalg_for_peer() function and use in the TLSv1.3 code.

Provide an ssl_sigalg_for_peer() function that knows how to figure out
which signature algorithm should be used for a peer provi

Provide a ssl_sigalg_for_peer() function and use in the TLSv1.3 code.

Provide an ssl_sigalg_for_peer() function that knows how to figure out
which signature algorithm should be used for a peer provided signature,
performing appropriate validation to ensure that the peer provided value
is suitable for the protocol version and key in use.

In the TLSv1.3 code, this replaces the need for separate calls to lookup
the sigalg from the peer provided value, then perform validation.

ok inoguchi@ tb@

show more ...

Move the RSA-PSS check for TLSv1.3 to ssl_sigalg_pkey_ok().

Also, rather than passing in a check_curve flag, pass in the SSL * and
handle version checks internally to ssl_sigalg_pkey_ok(), simplifyi

Move the RSA-PSS check for TLSv1.3 to ssl_sigalg_pkey_ok().

Also, rather than passing in a check_curve flag, pass in the SSL * and
handle version checks internally to ssl_sigalg_pkey_ok(), simplifying
the callers.

ok inoguchi@ tb@

show more ...

Track the sigalgs used by ourselves and our peer.

Move the sigalg pointer from SSL_HANDSHAKE_TLS13 to SSL_HANDSHAKE, naming
it our_sigalg, adding an equivalent peer_sigalg. Adjust the TLSv1.3 code
t

Track the sigalgs used by ourselves and our peer.

Move the sigalg pointer from SSL_HANDSHAKE_TLS13 to SSL_HANDSHAKE, naming
it our_sigalg, adding an equivalent peer_sigalg. Adjust the TLSv1.3 code
that records our signature algorithm. Add code to record the signature
algorithm used by our peer.

Needed for upcoming API additions.

ok tb@

show more ...

Change ssl_sigalgs_from_value() to perform sigalg list selection.

Rather that passing in a sigalg list at every call site, pass in the
appropriate TLS version and have ssl_sigalgs_from_value() perfo

Change ssl_sigalgs_from_value() to perform sigalg list selection.

Rather that passing in a sigalg list at every call site, pass in the
appropriate TLS version and have ssl_sigalgs_from_value() perform the
sigalg list selection itself. This allows the sigalg lists to be made
internal to the sigalgs code.

ok tb@

show more ...

Rename ssl_sigalg() to ssl_sigalg_from_value().

This makes the code more self-documenting and avoids the ambiguity between
ssl_sigalg the struct and ssl_sigalg the function.

ok tb@

Indent all labels with a single space.

This ensures that diff reports the correct function prototype.

Prompted by tb@

TLSv1.3 server: avoid sending alerts in legacy records

As soon as we know that we're dealing with a TLSv1.3 client, set
the legacy version in the record layer to 0x0303 so that we send
alerts with t

TLSv1.3 server: avoid sending alerts in legacy records

As soon as we know that we're dealing with a TLSv1.3 client, set
the legacy version in the record layer to 0x0303 so that we send
alerts with the correct record version. Previously we would send
early alerts with a record version of 0x0300.

ok jsing

show more ...

Make local header inclusion consistent.

Consistently include local headers in the same location, using the same
grouping/sorting across all files.

Avoid pulling ssl_sigalgs.h in via ssl_locl.h.

Forward declare struct sigalg in ssl_locl.h and avoid including
ssl_sigalgs.h. Explicitly include ssl_sigalgs.h where it is needed.

Move finished and peer finished to the handshake struct.

This moves the finish_md and peer_finish_md from the 'tmp' struct to the
handshake struct, renaming to finished and peer_finished in the proc

Move finished and peer finished to the handshake struct.

This moves the finish_md and peer_finish_md from the 'tmp' struct to the
handshake struct, renaming to finished and peer_finished in the process.
This also allows the remaining S3I(s) references to be removed from the
TLSv1.3 client and server.

ok inoguchi@ tb@

show more ...

Rename new_cipher to cipher.

This is in the SSL_HANDSHAKE struct and is what we're currently
negotiating, so there is really nothing more "new" about the cipher
than there is the key block or other

Rename new_cipher to cipher.

This is in the SSL_HANDSHAKE struct and is what we're currently
negotiating, so there is really nothing more "new" about the cipher
than there is the key block or other parts of the handshake data.

ok inoguchi@ tb@

show more ...

Move the TLSv1.3 handshake struct inside the shared handshake struct.

There are currently three different handshake structs that are in use -
the SSL_HANDSHAKE struct (as S3I(s)->hs), the SSL_HANDSH

Move the TLSv1.3 handshake struct inside the shared handshake struct.

There are currently three different handshake structs that are in use -
the SSL_HANDSHAKE struct (as S3I(s)->hs), the SSL_HANDSHAKE_TLS13 struct
(as S3I(s)->hs_tls13 or ctx->hs in the TLSv1.3 code) and the infamous
'tmp' embedded in SSL3_STATE_INTERNAL (as S3I(s)->tmp)).

This is the first step towards cleaning up the handshake structs so that
shared data is in the SSL_HANDSHAKE struct, with sub-structs for TLSv1.2
and TLSv1.3 specific information. Place SSL_HANDSHAKE_TLS13 inside
SSL_HANDSHAKE and change ctx->hs to refer to the SSL_HANDSHAKE struct
instead of the SSL_HANDSHAKE_TLS13 struct. This allows the TLSv1.3 code
to access the shared handshake data without needing the SSL struct.

ok inoguchi@ tb@

show more ...

Improve internal version handling.

Add handshake fields for our minimum TLS version, our maximum TLS version
and the TLS version negotiated during the handshake. Initialise our min/max
versions at t

Improve internal version handling.

Add handshake fields for our minimum TLS version, our maximum TLS version
and the TLS version negotiated during the handshake. Initialise our min/max
versions at the start of the handshake and leave these unchanged. The
negotiated TLS version is set in the client once we receive the ServerHello
and in the server at the point we select the highest shared version.

Provide an ssl_effective_version() function that returns the negotiated TLS
version if known, otherwise our maximum TLS version - this is effectively
what is stored in s->version currently.

Convert most of the internal code to use one of these three version fields,
which greatly simplifies code (especially in the TLS extension handling
code).

ok tb@

show more ...

Only use TLS versions internally (rather than both TLS and DTLS versions).

DTLS protocol version numbers are the 1's compliment of human readable TLS
version numbers, which means that newer versions

Only use TLS versions internally (rather than both TLS and DTLS versions).

DTLS protocol version numbers are the 1's compliment of human readable TLS
version numbers, which means that newer versions decrease in value and
there is no direct mapping between TLS protocol version numbers and DTLS
protocol version numbers.

Rather than having to deal with this internally, only use TLS versions
internally and map between DTLS and TLS protocol versions when necessary.
Rename functions and variables to use 'tls_version' when they contain a
TLS version (and never a DTLS version).

ok tb@

show more ...

Add support for SSL_get_shared_ciphers() in TLSv1.3

As reported by Steffen Ullrich and bluhm, since enabling TLSv1.3 server
some tests fail in t/local/07_sslecho.c of security/p5-Net-SSLeay due
to m

Add support for SSL_get_shared_ciphers() in TLSv1.3

As reported by Steffen Ullrich and bluhm, since enabling TLSv1.3 server
some tests fail in t/local/07_sslecho.c of security/p5-Net-SSLeay due
to missing support for SSL_get_shared_ciphers(). This fixes the parts
related to shared ciphers.

ok beck inoguchi jsing

show more ...

Rename two local variables ssl to s for consistency

In our tls13_* files, we use SSL *s for local variables and SSL *ssl
for function arguments. This is odd, but probably the result of finger
memory

Rename two local variables ssl to s for consistency

In our tls13_* files, we use SSL *s for local variables and SSL *ssl
for function arguments. This is odd, but probably the result of finger
memory. We intended to use ssl everywhere. Be that as it may, all local
variables except in two functions ended up being called s, so align the
two outliers with that. As noted by jsing, this is not ideal either as
in tls13_legacy_servername_process() the ssl_ctx is now inconsistent.
Renaming all s to ssl is a substantial amount of unnecessary churn at a
moment that isn't ideal, so we have to live with that.

ok bcook inoguchi jsing

show more ...

Use tls13_secret_{init,cleanup}() for the finished_key

This trades an array on the stack for a dynamically allocated secret in
tls13_{client,server}_finished_send() but has the benefit of wiping out

Use tls13_secret_{init,cleanup}() for the finished_key

This trades an array on the stack for a dynamically allocated secret in
tls13_{client,server}_finished_send() but has the benefit of wiping out
an intermediate secret on function exit.

ok jsing

show more ...

Use consistent names in tls13_{client,server}_finished_{recv,send}().

In tls13_{client,server}_finished_recv() we use verify_data_len, which
makes more sense than hmac_len. Use the same name in
tls1

Use consistent names in tls13_{client,server}_finished_{recv,send}().

In tls13_{client,server}_finished_recv() we use verify_data_len, which
makes more sense than hmac_len. Use the same name in
tls13_{client,server}_finished_send(), keeping things consistent between
functions.

ok tb@

show more ...

Use legacy verifier when building auto chains.

The new verifier builds all chains, starting with the shortest possible
path. It also does not currently return partial chains. Both of these
things co

Use legacy verifier when building auto chains.

The new verifier builds all chains, starting with the shortest possible
path. It also does not currently return partial chains. Both of these
things conflict with auto chain, where we want to build the longest
possible chain (to include all intermediates, and probably the root
unnecessarily), as well as using an incomplete chain when a trusted chain
is not known.

Depending on software configuration, we can end up building a chain
consisting only of a leaf certificate, rather than a longer chain. This
results in auto chain not including intermediates, which is undesireable.
For now, switch auto chain building to use the legacy verifier.

This should resolve the issues encountered by ajacoutot@ with sendmail.

ok tb@

show more ...

Fix SSL_get{,_peer}_finished() with TLSv1.3

As reported by Steffen Ullrich and bluhm, the Finished tests in
p5-Net-SSLeay's t/local/43_misc_functions.t broke with with TLSv1.3.
The reason for this i

Fix SSL_get{,_peer}_finished() with TLSv1.3

As reported by Steffen Ullrich and bluhm, the Finished tests in
p5-Net-SSLeay's t/local/43_misc_functions.t broke with with TLSv1.3.
The reason for this is that we don't copy the MDs over to the SSL, so
the API functions can't retrieve them. This commit fixes this part of
the test (one unrelated test still fails).

ok inoguchi jsing

show more ...

typo & punctuation in comment

Implement auto chain for the TLSv1.3 server.

Apparently OpenLDAP relies on this craziness to provide intermediates,
rather than specifying the chain directly like a normal TLS server would.

Issue n

Implement auto chain for the TLSv1.3 server.

Apparently OpenLDAP relies on this craziness to provide intermediates,
rather than specifying the chain directly like a normal TLS server would.

Issue noted by sthen@ and Bernard Spil, who both also tested this diff.

ok tb@

show more ...

Improve argument order for the internal tlsext API

Move is_server and msg_type right after the SSL object so that CBS
and CBB and alert come last. This brings these functions more in
line with other

Improve argument order for the internal tlsext API

Move is_server and msg_type right after the SSL object so that CBS
and CBB and alert come last. This brings these functions more in
line with other internal functions and separates state from data.

requested by jsing

show more ...

Switch the order of the two tests in tls13_client_hello_required_extensions
to match the order they are listed in the RFC. No functional change.