ssl_tlsext: fix uninitialized variable warning with gcc

This is a false positive but as is well-known, gcc is terrible at
understanding conditionally initialized variables and it is tedious
to explain this to downstream maintainers who look at warnings.

ok miod

Fix key share negotiation in HRR case

In the ClientHello retrying the handshake after a HelloRetryRequest, the
client must send a single key share matching the group selected by the
server in the HRR. This is not necessarily the mutually preferred group.
Incorrect logic added in ssl_tlsect.c r1.134 would potentially reject
such a key share because of that.

Instead, add logic to ensure on the server side that there is a single
share matching the group we selected in the HRR.

Fixes a regress test in p5-IO-Socket-SSL where server is configured
with P-521:P-384 and the client with P-256:P-384:P-521. Since the
client sends an initial P-256 key share, a HRR is triggered which
the faulty logic rejected because it was not the mutually preferred
P-384 but rather matching the server-selected P-521.

This will need some deduplication in subsequent commits. We may also
want to consider honoring the mutual preference and request a key
accordingly in the HRR.

reported by bluhm, fix suggested by jsing
ok beck jsing

Recommit a better version of the removal of the F5 workaround

Unlike for previous TLS versions, TLSv1.3 servers can send the supported
groups extension to inform a client of the server's preferences. The
intention is that a client can adapt for subsequent commits. We ignore
this info for now, but sthen ran into java-based servers that do this.

Thus, rejecting the extension outright was incorrect. Instead, only allow
the extension in TLSv1.3 encrypted extensions. This way the F5 workaround
is also disabled, but we continue to interoperate with TLSv1.3 servers that
do follow the last paragraph of RFC 8446, section 4.2.7.

This mostly adjusts outdated/misleading comments.

ok jsing sthen

Backout previous commit (intending that libressl client rejects a supported
groups extension from the server). It triggers 'CONNECT_CR_SRVR_HELLO:tlsv1
alert decode error' when connecting to a (modern) java server (tomcat 10.1.18
on openjdk 17.0.10).

"please revert" tb@

Stop pandering to the loadbalancer industrial complex.

So we initially kept this hack around for f5 boxes that
should have been patched in 2014, and were not as of 2017.

The f5 article for the bug archived on their web site,
and any of these devices on the public internet will have
since been upgraded to deal with a host of record layer, TLS,
and other bugs, or they likely won't be talking to modern
stacks, since as of this point the software with the bug
would not have been updated in 10 years.

So just make this spec compliant and reject a supported groups
extension that should not have been sent by a server.

ok tb@ jsing@

Fix up server processing of key shares.

Ensure that the client can not provide a duplicate key share
for any group, or send more key shares than groups they support.

Ensure that the key shares must be provided in the same order
as the client preference order specified in supported_groups.

Ensure we only will choose to use a key share that is for the
most preferred group by the client that we also support,
to avoid the client being downgraded by sending a less preferred
key share. If we do not end up with a key share for the most preferred
mutually supported group, will then do a hello retry request
selecting that group.

Add regress for this to regress/tlsext/tlsexttest.c

ok jsing@

Do not allow duplicate groups in supported groups.

While we are here refactor this to single return.

ok jsing@ tb@

Add an indicator that an extension has been processed.

ok jsing@

Process supported groups before key share.

This will allow us to know the client preferences for an upcoming
change to key share processing.

ok jsing@

Simplify TLS extension parsing and processing.

Rather than having a separate parse and process step for each TLS
extension, do a first pass that parses all of the TLS outer extensions and
retains the extension data, before running a second pass that calls the TLS
extension processing code.

ok beck@ tb@

Fix typo msg_types -> msg_type

from jsing

Split TLS extension parsing from processing.

The TLS extension parsing and processing order is currently dependent on
the order of the extensions in the handshake message. This means that the
processing order (and callback order) is not under our control. Split the
parsing from the processing such that the processing (and callbacks) are
run in a defined order.

Convert ALPN to the new model - other extensions will be split into
separate parse/process in following diffs.

ok beck@ tb@

Decouple TLS extension table order from tlsext_randomize_build_order()

The PSK extension must be the last extension in the client hello. This is
currently implemented by relying on the fact that it is the last extension
in the TLS extension table. Remove this dependency so that we can reorder
the table as needed.

ok tb@

Too many stupid things whine about these being used uninitialized
(which they aren't), so appease them.

ssl_tlsext.c: Add an accessor for the tls extension type.

Needed for the tlsexttest.c

ok jsing

Fix allocation size

Reported by anton

Free and calloc() the tlsext_build_order and remember its length

Aligns tlsext_randomize_build_order() with tlsext_linearize_build_order()
and will help regression testing.

ok jsing

Use TLSEXT_TYPE_alpn instead of the stupid long one

Randomize the order of TLS extensions

On creation of an SSL using SSL_new(), randomize the order in which the
extensions will be sent. There are several constraints: the PSK extension
must always come last. The order cannot be randomized on a per-message
basis as the strict interpretation of the standard chosen in the CH hashing
doesn't allow changing the order between first and second ClientHello.

Another constraint is that the current code calls callbacks directly on
parsing an extension, which means that the order callbacks are called
depends on the order in which the peer sent the extensions. This results
in breaking apache-httpd setups using virtual hosts with full ranomization
because virtual hosts don't work if the SNI is unknown at the time the
ALPN callback is called. So for the time being, we ensure that SNI always
precedes ALPN to avoid issues until this issue is fixed.

This is based on an idea by David Benjamin
https://boringssl-review.googlesource.com/c/boringssl/+/48045

Input & 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 *_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

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@

Avoid shadowing the cbs function parameter in tlsext_alpn_server_parse()

ok jsing

Make tlsext_*_{build,needs,parse}() functions static

None of these functions are used outside of ssl_tlsext.c. The only reason
they are prototyped in the header is for the use of tlsexttest.c. Rather
than having a big pile of useless copy-paste in the header, we can adapt
the test to avoid using these functions directly.

ok jsing

Rely on tlsext_parse() to set a decode_error alert

Instead of setting the alert manually in various parse handlers, we can
make use of the fact that tlsext_parse() sets the alert to decode_error
by default. This simplifies the code quite a bit.

ok jsing

Remove redundant length checks in parse functions

The main parsing function already checks that the entire extension data
was consumed, so the length checks inside some of the parse handlers are
redundant. They were also not done everywhere, so this makes the parse
handlers more consistent.

Similar diff was sent by jsing a long while back

ok jsing

Simplify tlsext_supported_groups_server_parse

Add an early return in the s->internal->hit case so that we can unindent
a lot of this code. In the HRR case, we do not need to check that the list
of supported groups is unmodified from the first CH. The CH extension
hashing already does that for us.

ok jsing

Drop some unnecessary parentheses.

ok jsing

Copy alpn_selected using CBS

ok jsing

Factor out ALPN extension format check

The ALPN extension must contain a non-empty list of protocol names.
Split a check of this out of tlsext_alpn_server_parse() so that it
can be reused elsewhere in the library.

ok jsing

Correct handling of QUIC transport parameters extension.

Remove duplicate U16 length prefix, since tlsext_build() already adds this
for us. Condition on SSL_is_quic() rather than TLS version - RFC 9001 is
clear that this extension is only permitted on QUIC transport and an
fatal unsupported extension alert is required if used elsewhere.
Additionally, at the point where extensions are parsed, we do not
necessarily know what TLS version has been negotiated.

ok beck@ tb@

Correct TLSEXT_TYPE_quic_transport_parameters message types.

Per RFC 9001, TLSEXT_TYPE_quic_transport_parameters may only appear in
ClientHello and EncryptedExtensions (not ServerHello).

ok beck@ tb@

Stop using ssl{_ctx,}_security() outside of ssl_seclevel.c

The API is ugly and we can easily abstract it away. The SSL_SECOP_* stuff
is now confined into ssl_seclevel.c and the rest of the library can make
use of the more straightforward wrappers, which makes it a lot easier on
the eyes.

ok beck jsing

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

Check security level for supported groups.

ok jsing

Check whether the security level allows session tickets.

ok beck jsing

Add support for sending QUIC transport parameters

This is the start of adding the boringssl API for QUIC support,
and the TLS extensions necessary to send and receive QUIC transport
data.

Inspired by boringssl's https://boringssl-review.googlesource.com/24464

ok jsing@ tb@

Check the security level when building sigalgs

ok beck jsing

The parse stubs need to skip over the extension data.

Found by anton with tlsfuzzer

ok anton

Add stubbed out handlers for the pre_shared_key extension

ok jsing

Implement handlers for the psk_key_exchange_modes extensions.

ok jsing

Bye bye S3I.

S3I has served us well, however now that libssl is fully opaque it is time
to say goodbye. Aside from removing the calloc/free/memset, the rest is
mechanical sed.

ok inoguchi@ tb@

Avoid use of uninitialized in tlsext_sni_server_parse()

If the hostname is too long, tlsext_sni_is_valid_hostname() will fail
without having initialized *is_ip. As a result, the garbage value could
lead to accepting (but otherwise ignoring) overlong and possibly invalid
hostnames without erroring in tlsext_sni_server_parse().

ok inoguchi jsing

Plumb decode errors through key share parsing code.

Distinguish between decode errors and other errors, so that we can send
a SSL_AD_DECODE_ERROR alert when appropriate.

Fixes a tlsfuzzer failure, due to it expecting a decode error alert and
not receiving one.

Prompted by anton@

ok tb@

Use SSL_AD_INTERNAL_ERROR for non-decoding alerts when parsing keyshares.

ok tb@

Simplify tlsext_keyshare_server_parse()

SSL_AD_DECODE_ERROR is the default alert for a TLS extension parsing
failure - remove the various gotos and simply return 0 instead.

ok tb@

Convert legacy TLS client to tls_key_share.

This requires adding DHE support to tls_key_share. In doing so,
tls_key_share_peer_public() has to lose the group argument and gains
an invalid_key argument. The one place that actually needs the group
check is tlsext_keyshare_client_parse(), so add code to do this.

ok inoguchi@ tb@

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@

Pull key share group/length CBB code up from tls13_key_share_public()

This provides better symmetry with the parsing code and will allow for
better reuse with the legacy stack, which has different message structures.

ok inoguchi@ tb@

Only allow zero length key shares when we know we're doing HRR.

ok inoguchi@ tb@

Improve SNI hostname validation.

For some time now we've validated the hostname provided to the server in
the SNI extension. Per RFC 6066, an IP literal is invalid as a hostname -
the current code rejects IPv6 literals, but allows IPv4 literals through.

Improve this check to explicitly detect both IPv4 and IPv6 literals. Some
software has been historically known to include IP literals in SNI, so
rather than rejecting this outright (and failing with a decode error),
pretend that the SNI extension does not exist (such that we do not break
some older clients).

ok inoguchi@ tb@

Fold SSL_SESSION_INTERNAL back into SSL_SESSION.

ok beck@ tb@

Do not ignore SSL_TLSEXT_ERR_FATAL from the ALPN callback

As reported by Jeremy Harris, we inherited a strange behavior from
OpenSSL, in that we ignore the SSL_TLSEXT_ERR_FATAL return from the
ALPN callback. RFC 7301, 3.2 states: 'In the event that the server
supports no protocols that the client advertises, then the server
SHALL respond with a fatal "no_application_protocol" alert.'

Honor this requirement and succeed only on SSL_TLSEXT_ERR_{OK,NOACK}
which is the current behavior of OpenSSL. The documentation change
is taken from OpenSSL 1.1.1 as well.

As pointed out by jsing, there is more to be fixed here:
- ensure that the same protocol is selected on session resumption
- should the callback be called even if no ALPN extension was sent?
- ensure for TLSv1.2 and earlier that the SNI has already been processed

ok beck jsing

Correct the is_server flag in the call to the debug callback to be correct.
ok tb@

Use appropriate TLS version when building client sigalg extensions.

Only use the minimum TLS version to when building a signature algorithms
extension for a ClientHello - in all other cases we should be using the
negotiated TLS version.

ok inoguchi@ tb@

Change ssl_sigalgs_build() to perform sigalg list selection.

Rather that doing sigalg list selection at every call site, pass in the
appropriate TLS version and have ssl_sigalgs_build() perform the sigalg
list selection itself. This reduces code duplication, simplifies the
calling code and is the first step towards internalising the sigalg lists.

ok tb@

Only use SSL_AD_* internally.

Due to hysterical raisins there are three different types of defines for
alerts. SSL3_AD_* are from SSLv3, TLS1_AD_* are from TLSv1.0 onwards and
SSL_AD_* currently map to either an SSL3_AD_* or TLS1_AD_* define.

Currently, all three of these are used in various places - switch to using
just SSL_AD_* values internally, as a first step in cleaning this up.

ok tb@

Simplify tlsext_ecpf_parse()

The default alert in the tlsext parsing code is a decode_error, so
there's no need for an error path that only sets that alert.

suggested by/ok jsing

Adjust alert for ECPF without uncompressed point format

According to RFC 8422, we must send an illegal_parameter alert on
receiving an ECPF extension that doesn't include the uncompressed
format, not a decode_error.

Reported via GitHub issue #675.

ok jsing

Make local header inclusion consistent.

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

Explicitly include <openssl/opensslconf.h> in files using OPENSSL_NO_*

Where a file references to OPENSSL_NO_* conditions, ensure that we
explicitly include <openssl/opensslconf.h> before any references, rather
than relying on another header to pull this in.

Only hash known CH extensions

RFC 4.1.2 specifies the ways in which the extensions in the first and
the second ClientHello may differ. It basically says that extensions
not known to a server must not change. This in turn makes it impossible
to introduce new extensions that do change. It makes little sense to
enforce that extensions we don't know and care about aren't modified,
so make the hashing more lenient and restrict it to the extensions we
do care about. Arguably, enforcing no change in an unknown extension
is incompatible with the requirement that it be ignored.

ok bcook jsing

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@

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@

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@

Remove bogus DTLS checks to disable ECC and OCSP.

ECC and OCSP can be used with DTLS, so remove bogus checks that currently
prevent it. These are long lasting remnants from the original OpenSSL code.

ok tb@

Replace SSL_IS_DTLS with SSL_is_dtls().

Garbage collect the now unused SSL_IS_DTLS macro.

ok tb@

Constipate srtp_known_profiles, pushing it into .data.rel.ro

ok tb@ jsing@

Constipate ssl3_ciphers and tls1[23]_sigalgs*, pushing them into
.data.rel.ro and .rodata respectively.

ok tb@ jsing@

Set alpn_selected_len = 0 when alpn_selected is NULL

ok jsing@ tb@

Only parse a client's status_request in the CH

A client should only send a status_request as part of the CH.

Pointed out by Michael Forney

ok inoguchi jsing

Ensure clients only send a status_request in the CH

The current code might cause a client to send a status_request
containing a CertificateStatusRequest with its certificate. This
makes no sense.

Pointed out by Michael Forney

ok inoguchi jsing

Correctly handle server requests for an OCSP response

According to RFC 8446, 4.4.2.1, a server may request that a client
present an OCSP response with its certificate by sending an empty
status_request extension as part of the certificate request. The
current code expects a full CertificateStatus structure, which is
only sent if the server sends an OCSP response with its certificate.

This causes interoperability issues with Go's TLS server and with
newer GnuTLS where we would abort the handshake with a decode_error
alert and length mismatch error.

Issue reported and diagnosed by Michael Forney
Problem also found by Mikolaj Kucharski and inoguchi.

ok inoguchi jsing

zap trailing whitespace on one line

Make the message type available to the extension functions

Some TLS extensions need to be treated differently depending on the
handshake message they appear in. Over time, various workarounds and
hacks were used to deal with the unavailability of the message type
in these functions, but this is getting fragile and unwieldy. Having
the message type available will enable us to clean this code up and
will allow simple fixes for a number of bugs in our handling of the
status_request extension reported by Michael Forney.

This approach was suggested a while ago by jsing.

ok beck jsing

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

Implement a rolling hash of the ClientHello message, Enforce RFC 8446
section 4.1.2 to ensure subsequent ClientHello messages after a
HelloRetryRequest messages must be unchanged from the initial
ClientHello.

ok tb@ jsing@

Mop up servername_done, which is unused.

ok beck@ inoguchi@ tb@

Fix some stylistic nits from jsing.

ok jsing

Enforce that SNI hostnames be correct as per rfc 6066 and 5980.
Correct SNI alerts to differentiate between illegal parameter
and an unknown name.

ok tb@`

Do not assume that server_group != 0 or tlsext_supportedgroups != NULL
implies that we're dealing with a HRR in the extension handling code.

Explicitly check that we're in this situation by inspecting the flag in
the handshake context. Add missing error checks and send the appropriate
alerts. The hrr flag needs to be unset after parsing the client hello
retry to avoid breaking the server hello handling. All this is far from
ideal, but better than nothing.

The correct fix would likely be to make the message type available
but that would need to be part of a more extensive rearchitecture of
the extension handling.

Discussed at length with jsing

Only send ocsp staples if the client asked for ocsp certificate status.
noticed by dlg@ on www.openbsd.org with curl.

ok dlg@

Add support for TLS 1.3 server to send certificate status
messages with oscp staples.

ok jsing@ tb@

Fix pesky whitespace.

Use size_t for OCSP response length.

The OCSP response length is currently an integer, which is overloaded with
-1 meaning "unset". Use a size_t for the OCSP response length and infer
unset from the OCSP response being NULL. This makes code more readable,
simpler and less error prone.

ok beck@

Only reset TLS extension state when parsing client hello or server hello.

With TLSv1.3 we end up parsing extensions from more than just these two
messages. This can result in variables (like the selected alpn) being
freed when things still need them.

ok tb@

Add support for certificate status requests in TLS 1.3 client
ok jsing@, tb@, inoguchi@

Add support for HelloRetryRequests in the TLSv1.3 server.

ok inoguchi@ tb@

branches: 1.63.4;
Handle TLSv1.3 key shares other than X25519 on the server side.

Previously we would only select an X25519 key share from the client,
ignoring any others. Change this so that we will select the first of the
key shares that matches one of our supported groups.

ok beck@ inoguchi@ tb@

drop unused include <openssl/curve25519.h>

ok inoguchi jsing

Avoid potential NULL dereference when parsing a server keyshare extension.

It is currently possible for key_share to be NULL when a TLS client
receives a keyshare extension. However, for this to occur the client has
to be doing TLS 1.2 or earlier, which means that it was invalid for the
server to send the extension. As such, check for NULL and treat it as an
invalid extension.

Found by oss-fuzz (#20741 and #20745).

ok inoguchi@ tb@

Correctly handle key share extensions in a hello retry request.

In a hello retry request the server will only send the selected group and
not actually provide a key exchange. In this case we need to store the
server selected group for further processing.

ok tb@

Correctly unpack client key shares.

Even if we're not processing/using the peer public key from the key share,
we still need to unpack it in order to parse the TLS extension correctly.
Resolves issues with TLSv1.3 clients talking to TLSv1.2 server.

ok tb@

Provide struct/functions for handling TLSv1.3 key shares.

Pull out the key share handling code and provide a clean/self contained
interface. This will make it easier to support groups other than X25519.

ok beck@ inoguchi@ tb@

Add sigalgs for server side to enable client certificate processing
in tls 1.3

Will be used in a follow on commit to enable tls1.3 client certificates

ok jsing@

Only discard the extension block for client hello and server hello
messages.

TLSv1.3 messages that include extensions need a length prefixed field with
zero bytes, rather than no data at all.

ok beck@ tb@

Only send an RI extension for pre-TLSv1.3 versions.

ok beck@

Rename failure into alert_desc in tlsext_ocsp_server_parse().

fix previous: alert_desc needs to be an int.

Avoid modifying alert in the success path.

ok beck jsing

Revert previous deduplication diff, I broke portable in a strange way.
I'll figure it out a bit later.
Found and diagnosed by inoguchi@

Deduplicate some extension processing code.

ok tb@ inoguchi@

Relax parsing of TLS key share extensions on the server.

The RFC does not require X25519 and it also allows clients to send an empty
key share when the want the server to select a group. The current behaviour
results in handshake failures where the client supports TLS 1.3 and sends a
TLS key share extension that does not contain X25519.

Issue reported by Hubert Kario via github.

ok tb@

Do not send an SNI extension when resuming a session that contains a server
name (which means the client sent SNI during the initial handshake).

Issue reported by Renaud Allard.

ok tb@

Fix typo and label indent.

Tidy up some names/structures following the renaming of TLS extension
functions based on message type (clienthello/serverhello), to which side
is handling the processing.

No intended functional change.

ok beck@

In DTLS, use_srtp is part of the extended server hello while in TLSv1.3,
it is an encrypted extension. Include it in the server hello for now.
This will have to be revisited once TLSv1.3 gets there. Fixes SRTP
negotiation.

Problem found by two rust-openssl regress failures reported by mikeb.

with & ok beck

branches: 1.44.2;
Defer sigalgs selection until the certificate is known.

Previously the signature algorithm was selected when the TLS extension was
parsed (or the client received a certificate request), however the actual
certificate to be used is not known at this stage. This leads to various
problems, including the selection of a signature algorithm that cannot be
used with the certificate key size (as found by jeremy@ via ruby regress).

Instead, store the signature algorithms list and only select a signature
algorithm when we're ready to do signature generation.

Joint work with beck@.

Revert TLS1_get{,_client}_version simplification because DTLS.

Partially clean up the TLS1_get_{,client}_version macros.

LibreSSL only supports TLSv1.0 and above, hence the checks the macros are
performing are useless. Simplify them to their effective code. Also place
both under #ifndef LIBRESSL_INTERNAL and use the variables directly in our
code, which improves readability.

ok tb@

Revert r1.38 as it introduces use of a stack value post function return.

The deduplication is also not quite right - this will be revisited in due
course.

unwrap a line introduced in previous.

Correct handling of TLS sigalgs extension for TLSv1.0/TLSv1.1.

When operating as a TLSv1.0 or TLSv1.1 server, we still have to parse the
TLS sigalgs extension if presented by the client (which might be TLSv1.2
capable), rather than treating its presence as an error.

While here, remove future version dependence issues by avoiding explicit
version equality checks.

Issue reported by bluhm@.

ok bluhm@ tb@

Deduplicate a bunch of replicated code in the extension handling
ok tb@

Add tls_extension_seen(), a utility to know if a particular extension
has been seen in the handshake so far. Use it for keyshare.
ok tb@

Add server side of versions, keyshare, and client and server of cookie
extensions for tls1.3.
versions is currently defanged to ignore its result until tls13 server
side wired in full, so that server side code still works today when
we only support tls 1.2
ok bcook@ tb@ jsing@

move the extensions_seen into the handshake struct
ok jsing@

Modify sigalgs extension processing to accomodate TLS 1.3.
- Make a separate sigalgs list for TLS 1.3 including only modern
algorithm choices which we use when the handshake will not negotiate
TLS 1.2.
- Modify the legacy sigalgs for TLS 1.2 to include the RSA PSS algorithms as
mandated by RFC8446 when the handshake will permit negotiation of TLS 1.2
from a 1.3 handshake.
ok jsing@ tb@

revert previous, accidentally contained another diff in addition
to the one I intended to commit

Modify sigalgs extension processing for TLS 1.3.
- Make a separate sigalgs list for TLS 1.3 including only modern
algorithm choices which we use when the handshake will not negotiate
TLS 1.2
- Modify the legacy sigalgs for TLS 1.2 to include the RSA PSS algorithms as
mandated by RFC8446 when the handshake will permit negotiation of TLS 1.2
ok jsing@ tb@

TLS 1.3 clients always need to send the supported groups extension.

A couple of cleanup/style tweaks while here.

ok tb@

bump copyright years appopriately

Add client side of supported versions and keyshare extensions with basic regress
ok jsing@

Add support for RFC 8446 section 4.2 enforcing which extensions may
appear with which messages.
ok jsing@

Rename TLS extension handling to use less "hello".

When the TLS extension code was rewritten, TLS extensions could only exist
in ClientHello and ServerHello messages - as such, they were named in pairs
of *_clienthello_{needs,build} which would be called by the client and
*_clienthello_parse. Likewise for *_serverhello_{needs,build} which would
be called by a server and *_serverhello_parse, which would be called by a
client.

Enter TLSv1.3 - TLS extensions can now exist in one of seven messages,
with only certain types being allowed to appear in each, meaning the naming
scheme no longer works. Instead, rename them to indicate the caller rather
than the message type - this effectively means:

clienthello_needs -> client_needs
clienthello_build -> client_build
clienthello_parse -> server_parse
serverhello_needs -> server_needs
serverhello_build -> server_build
serverhello_parse -> client_parse

ok beck@ tb@

Add the ability to have a separate priority list for sigalgs.
Add a priority list for tls 1.2
ok jsing@

Reimplement the sigalgs processing code into a new implementation
that will be usable with TLS 1.3 with less eye bleed.
ok jsing@ tb@

Rename the TLS Supported Elliptic Curves extension to Supported Groups.

RFC 7919 renamed the Supported Elliptic Curves TLS extension to Supported
Groups and redefined it to include finite field DH (FFDH) in addition to
elliptic curve DH (ECDH). As such, rename the TLS extension and change the
associated code to refer to groups rather than curves.

ok beck@ tb@

Rework the TLS extension handling code to improve readability/flexibility,
by moving the needs/build/parse functions into their own struct.

ok beck@ tb@

If we fail to decode an EC point format extension, send a decode_error
alert rather than an internal_error alert.

Issue found by Simon Friedberger, Robert Merget and Juraj Somorovsky.

ok beck@ inoguchi@

Complete the TLS extension rewrite on the client-side.

The RI logic gets pulled up into ssl3_get_server_hello() and
ssl_parse_serverhello_tlsext() gets replaced by tlsext_client_parse(),
which allows a CBS to be passed all the way down.

This also deduplicates the tlsext_client_build() and tlsext_server_build()
code.

ok beck@

Complete the TLS extension handling rewrite for the server-side.

This removes ssl_parse_clienthello_tlsext() and allows the CBS to be
passed all the way through from ssl3_get_client_hello(). The renegotation
check gets pulled up into ssl3_get_client_hello() which is where other
such checks exist.

The TLS extension parsing now also ensures that we do not get duplicates
of any known extensions (the old pre-rewrite code only did this for some
extensions).

ok inoguchi@

Clarify the comment re the F5 EC curves extension bug.

Also reference the knowledge base article instead of a discussion thread.

Correct TLS extensions handling when no extensions are present.

If no TLS extensions are present in a client hello or server hello, omit
the entire extensions block, rather than including it with a length of
zero.

ok beck@ inoguchi@

branches: 1.17.4;
Fix various issues in the OCSP extension parsing code:

- When parsing the OCSP extension we can have multiple responder IDs - pull
these out correctly.

- Stop using CBS_stow() - it's unnecessary since we just need access to the
data and length (which we can get via CBS_data() and CBS_len()).

- Use a temporary pointer when calling d2i_*() functions, since it will
increment the pointer by the number of bytes it consumed when decoding.

The original code incorrectly passes the pointer allocated via CBS_stow()
(using malloc()) to a d2i_*() function and then calls free() on the now
incremented pointer, most likely resulting in a crash. This issue was
reported by Robert Swiecki who found the issue using honggfuzz.

ok beck@

When building the OCSP extension, only add the length prefixed extensions
after we finish building the responder ID list. Otherwise adding to the
responder ID list fails.

ok beck@

Move the full extension building into tlsext_{client,server}hello_build(),
leaving ssl_add_{client,server}hello_tlsext() as pointer to CBB wrappers.

ok doug@

When OCSP status type is unknown, ignore the extension.

This needs to skip past the CBS data or it will be treated as a decode
error even though it returns 1.

ok jsing@

Actually parse the ALPN extension in a client hello, even if no ALPN
callback has been installed. This ensures that the ALPN extension is valid
and avoids leaving unprocessed extension data, which leads to a decode
error.

Found the hard way by jsg@

Rewrite SRTP extension using CBB/CBS and the new extension framework.

input + ok beck@, jsing@

Rewrite ALPN extension using CBB/CBS and the new extension framework.

ok bcook@ beck@
input + ok jsing@

Work around bug in F5's handling of the supported elliptic curves extension.

RFC 4492 only defines elliptic_curves for ClientHello. However, F5 is
sending it in ServerHello. We need to skip over it since our TLS extension
parsing code is now more strict.

Thanks to Armin Wolfermann and WJ Liu for reporting the issue.

input + ok jsing@

Rewrite the TLS status request extension to use the new TLS extension framework.
ok jsing@

Convert TLS signature algorithms extension handling to the new framework.

ok beck@ doug@

Rewrite session ticket TLS extension handling using CBB/CBS and the new
extension framework.

ok jsing@ beck@

Rewrite EllipticCurves TLS extension handling using CBB/CBS and the new
extension framework.

input + ok jsing@

Add doug@'s copyright since he just added code to these two files.

Rewrite the ECPointFormats TLS extension handling using CBB/CBS and the
new extension framework.

input + ok jsing@

Rewrite and move the last remnants of the ServerHello SNI handling into
tlsext_sni_serverhello_parse(). This also adds a check to ensure that
if we have an existing session, the name matches what we specified via
SNI.

ok doug@

Rewrite the TLS Renegotiation Indication extension handling using CBB/CBS
and the new extension framework.

Feedback from doug@

ok inoguchi@

Start rewriting TLS extension handling.

Introduce a TLS extension handling framework that has per-extension type
functions to determine if an extension is needed, to build the extension
data and parse the extension data. This is somewhat analogous to BoringSSL,
however these build and parse functions are intentionally symetrical. The
framework is hooked into the existing TLS handling code in such a way that
we can gradual convert the extension handling code.

Convert the TLS Server Name Indication extension to the new framework,
while rewriting it to use CBB/CBS and be more strict in the process.

Discussed with beck@

ok inoguchi@

Fix key share negotiation in HRR case

In the ClientHello retrying the handshake after a HelloRetryRequest, the
client must send a single key share matching the group selected by the
server in the HRR. This is not necessarily the mutually preferred group.
Incorrect logic added in ssl_tlsect.c r1.134 would potentially reject
such a key share because of that.

Instead, add logic to ensure on the server side that there is a single
share matching the group we selected in the HRR.

Fixes a regress test in p5-IO-Socket-SSL where server is configured
with P-521:P-384 and the client with P-256:P-384:P-521. Since the
client sends an initial P-256 key share, a HRR is triggered which
the faulty logic rejected because it was not the mutually preferred
P-384 but rather matching the server-selected P-521.

This will need some deduplication in subsequent commits. We may also
want to consider honoring the mutual preference and request a key
accordingly in the HRR.

reported by bluhm, fix suggested by jsing
ok beck jsing

Recommit a better version of the removal of the F5 workaround

Unlike for previous TLS versions, TLSv1.3 servers can send the supported
groups extension to inform a client of the server's preferences. The
intention is that a client can adapt for subsequent commits. We ignore
this info for now, but sthen ran into java-based servers that do this.

Thus, rejecting the extension outright was incorrect. Instead, only allow
the extension in TLSv1.3 encrypted extensions. This way the F5 workaround
is also disabled, but we continue to interoperate with TLSv1.3 servers that
do follow the last paragraph of RFC 8446, section 4.2.7.

This mostly adjusts outdated/misleading comments.

ok jsing sthen

Backout previous commit (intending that libressl client rejects a supported
groups extension from the server). It triggers 'CONNECT_CR_SRVR_HELLO:tlsv1
alert decode error' when connecting to a (modern) java server (tomcat 10.1.18
on openjdk 17.0.10).

"please revert" tb@

Stop pandering to the loadbalancer industrial complex.

So we initially kept this hack around for f5 boxes that
should have been patched in 2014, and were not as of 2017.

The f5 article for the bug archived on their web site,
and any of these devices on the public internet will have
since been upgraded to deal with a host of record layer, TLS,
and other bugs, or they likely won't be talking to modern
stacks, since as of this point the software with the bug
would not have been updated in 10 years.

So just make this spec compliant and reject a supported groups
extension that should not have been sent by a server.

ok tb@ jsing@

Fix up server processing of key shares.

Ensure that the client can not provide a duplicate key share
for any group, or send more key shares than groups they support.

Ensure that the key shares must be provided in the same order
as the client preference order specified in supported_groups.

Ensure we only will choose to use a key share that is for the
most preferred group by the client that we also support,
to avoid the client being downgraded by sending a less preferred
key share. If we do not end up with a key share for the most preferred
mutually supported group, will then do a hello retry request
selecting that group.

Add regress for this to regress/tlsext/tlsexttest.c

ok jsing@

Do not allow duplicate groups in supported groups.

While we are here refactor this to single return.

ok jsing@ tb@

Add an indicator that an extension has been processed.

ok jsing@

Process supported groups before key share.

This will allow us to know the client preferences for an upcoming
change to key share processing.

ok jsing@

Simplify TLS extension parsing and processing.

Rather than having a separate parse and process step for each TLS
extension, do a first pass that parses all of the TLS outer extensions and
retains the extension data, before running a second pass that calls the TLS
extension processing code.

ok beck@ tb@

Fix typo msg_types -> msg_type

from jsing

Split TLS extension parsing from processing.

The TLS extension parsing and processing order is currently dependent on
the order of the extensions in the handshake message. This means that the
processing order (and callback order) is not under our control. Split the
parsing from the processing such that the processing (and callbacks) are
run in a defined order.

Convert ALPN to the new model - other extensions will be split into
separate parse/process in following diffs.

ok beck@ tb@

Decouple TLS extension table order from tlsext_randomize_build_order()

The PSK extension must be the last extension in the client hello. This is
currently implemented by relying on the fact that it is the last extension
in the TLS extension table. Remove this dependency so that we can reorder
the table as needed.

ok tb@

Too many stupid things whine about these being used uninitialized
(which they aren't), so appease them.

ssl_tlsext.c: Add an accessor for the tls extension type.

Needed for the tlsexttest.c

ok jsing

Fix allocation size

Reported by anton

Free and calloc() the tlsext_build_order and remember its length

Aligns tlsext_randomize_build_order() with tlsext_linearize_build_order()
and will help regression testing.

ok jsing

Use TLSEXT_TYPE_alpn instead of the stupid long one

Randomize the order of TLS extensions

On creation of an SSL using SSL_new(), randomize the order in which the
extensions will be sent. There are several constraints: the PSK extension
must always come last. The order cannot be randomized on a per-message
basis as the strict interpretation of the standard chosen in the CH hashing
doesn't allow changing the order between first and second ClientHello.

Another constraint is that the current code calls callbacks directly on
parsing an extension, which means that the order callbacks are called
depends on the order in which the peer sent the extensions. This results
in breaking apache-httpd setups using virtual hosts with full ranomization
because virtual hosts don't work if the SNI is unknown at the time the
ALPN callback is called. So for the time being, we ensure that SNI always
precedes ALPN to avoid issues until this issue is fixed.

This is based on an idea by David Benjamin
https://boringssl-review.googlesource.com/c/boringssl/+/48045

Input & 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 *_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

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@

Avoid shadowing the cbs function parameter in tlsext_alpn_server_parse()

ok jsing

Make tlsext_*_{build,needs,parse}() functions static

None of these functions are used outside of ssl_tlsext.c. The only reason
they are prototyped in the header is for the use of tlsexttest.c. Rather
than having a big pile of useless copy-paste in the header, we can adapt
the test to avoid using these functions directly.

ok jsing

Rely on tlsext_parse() to set a decode_error alert

Instead of setting the alert manually in various parse handlers, we can
make use of the fact that tlsext_parse() sets the alert to decode_error
by default. This simplifies the code quite a bit.

ok jsing

Remove redundant length checks in parse functions

The main parsing function already checks that the entire extension data
was consumed, so the length checks inside some of the parse handlers are
redundant. They were also not done everywhere, so this makes the parse
handlers more consistent.

Similar diff was sent by jsing a long while back

ok jsing

Simplify tlsext_supported_groups_server_parse

Add an early return in the s->internal->hit case so that we can unindent
a lot of this code. In the HRR case, we do not need to check that the list
of supported groups is unmodified from the first CH. The CH extension
hashing already does that for us.

ok jsing

Drop some unnecessary parentheses.

ok jsing

Copy alpn_selected using CBS

ok jsing

Factor out ALPN extension format check

The ALPN extension must contain a non-empty list of protocol names.
Split a check of this out of tlsext_alpn_server_parse() so that it
can be reused elsewhere in the library.

ok jsing

Correct handling of QUIC transport parameters extension.

Remove duplicate U16 length prefix, since tlsext_build() already adds this
for us. Condition on SSL_is_quic() rather than TLS version - RFC 9001 is
clear that this extension is only permitted on QUIC transport and an
fatal unsupported extension alert is required if used elsewhere.
Additionally, at the point where extensions are parsed, we do not
necessarily know what TLS version has been negotiated.

ok beck@ tb@

Correct TLSEXT_TYPE_quic_transport_parameters message types.

Per RFC 9001, TLSEXT_TYPE_quic_transport_parameters may only appear in
ClientHello and EncryptedExtensions (not ServerHello).

ok beck@ tb@

Stop using ssl{_ctx,}_security() outside of ssl_seclevel.c

The API is ugly and we can easily abstract it away. The SSL_SECOP_* stuff
is now confined into ssl_seclevel.c and the rest of the library can make
use of the more straightforward wrappers, which makes it a lot easier on
the eyes.

ok beck jsing

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

Check security level for supported groups.

ok jsing

Check whether the security level allows session tickets.

ok beck jsing

Add support for sending QUIC transport parameters

This is the start of adding the boringssl API for QUIC support,
and the TLS extensions necessary to send and receive QUIC transport
data.

Inspired by boringssl's https://boringssl-review.googlesource.com/24464

ok jsing@ tb@

Check the security level when building sigalgs

ok beck jsing

The parse stubs need to skip over the extension data.

Found by anton with tlsfuzzer

ok anton

Add stubbed out handlers for the pre_shared_key extension

ok jsing

Implement handlers for the psk_key_exchange_modes extensions.

ok jsing

Bye bye S3I.

S3I has served us well, however now that libssl is fully opaque it is time
to say goodbye. Aside from removing the calloc/free/memset, the rest is
mechanical sed.

ok inoguchi@ tb@

Avoid use of uninitialized in tlsext_sni_server_parse()

If the hostname is too long, tlsext_sni_is_valid_hostname() will fail
without having initialized *is_ip. As a result, the garbage value could
lead to accepting (but otherwise ignoring) overlong and possibly invalid
hostnames without erroring in tlsext_sni_server_parse().

ok inoguchi jsing

Plumb decode errors through key share parsing code.

Distinguish between decode errors and other errors, so that we can send
a SSL_AD_DECODE_ERROR alert when appropriate.

Fixes a tlsfuzzer failure, due to it expecting a decode error alert and
not receiving one.

Prompted by anton@

ok tb@

Use SSL_AD_INTERNAL_ERROR for non-decoding alerts when parsing keyshares.

ok tb@

Simplify tlsext_keyshare_server_parse()

SSL_AD_DECODE_ERROR is the default alert for a TLS extension parsing
failure - remove the various gotos and simply return 0 instead.

ok tb@

Convert legacy TLS client to tls_key_share.

This requires adding DHE support to tls_key_share. In doing so,
tls_key_share_peer_public() has to lose the group argument and gains
an invalid_key argument. The one place that actually needs the group
check is tlsext_keyshare_client_parse(), so add code to do this.

ok inoguchi@ tb@

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@

Pull key share group/length CBB code up from tls13_key_share_public()

This provides better symmetry with the parsing code and will allow for
better reuse with the legacy stack, which has different message structures.

ok inoguchi@ tb@

Only allow zero length key shares when we know we're doing HRR.

ok inoguchi@ tb@

Improve SNI hostname validation.

For some time now we've validated the hostname provided to the server in
the SNI extension. Per RFC 6066, an IP literal is invalid as a hostname -
the current code rejects IPv6 literals, but allows IPv4 literals through.

Improve this check to explicitly detect both IPv4 and IPv6 literals. Some
software has been historically known to include IP literals in SNI, so
rather than rejecting this outright (and failing with a decode error),
pretend that the SNI extension does not exist (such that we do not break
some older clients).

ok inoguchi@ tb@

Fold SSL_SESSION_INTERNAL back into SSL_SESSION.

ok beck@ tb@

Do not ignore SSL_TLSEXT_ERR_FATAL from the ALPN callback

As reported by Jeremy Harris, we inherited a strange behavior from
OpenSSL, in that we ignore the SSL_TLSEXT_ERR_FATAL return from the
ALPN callback. RFC 7301, 3.2 states: 'In the event that the server
supports no protocols that the client advertises, then the server
SHALL respond with a fatal "no_application_protocol" alert.'

Honor this requirement and succeed only on SSL_TLSEXT_ERR_{OK,NOACK}
which is the current behavior of OpenSSL. The documentation change
is taken from OpenSSL 1.1.1 as well.

As pointed out by jsing, there is more to be fixed here:
- ensure that the same protocol is selected on session resumption
- should the callback be called even if no ALPN extension was sent?
- ensure for TLSv1.2 and earlier that the SNI has already been processed

ok beck jsing

Correct the is_server flag in the call to the debug callback to be correct.
ok tb@

Use appropriate TLS version when building client sigalg extensions.

Only use the minimum TLS version to when building a signature algorithms
extension for a ClientHello - in all other cases we should be using the
negotiated TLS version.

ok inoguchi@ tb@

Change ssl_sigalgs_build() to perform sigalg list selection.

Rather that doing sigalg list selection at every call site, pass in the
appropriate TLS version and have ssl_sigalgs_build() perform the sigalg
list selection itself. This reduces code duplication, simplifies the
calling code and is the first step towards internalising the sigalg lists.

ok tb@

Only use SSL_AD_* internally.

Due to hysterical raisins there are three different types of defines for
alerts. SSL3_AD_* are from SSLv3, TLS1_AD_* are from TLSv1.0 onwards and
SSL_AD_* currently map to either an SSL3_AD_* or TLS1_AD_* define.

Currently, all three of these are used in various places - switch to using
just SSL_AD_* values internally, as a first step in cleaning this up.

ok tb@

Simplify tlsext_ecpf_parse()

The default alert in the tlsext parsing code is a decode_error, so
there's no need for an error path that only sets that alert.

suggested by/ok jsing

Adjust alert for ECPF without uncompressed point format

According to RFC 8422, we must send an illegal_parameter alert on
receiving an ECPF extension that doesn't include the uncompressed
format, not a decode_error.

Reported via GitHub issue #675.

ok jsing

Make local header inclusion consistent.

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

Explicitly include <openssl/opensslconf.h> in files using OPENSSL_NO_*

Where a file references to OPENSSL_NO_* conditions, ensure that we
explicitly include <openssl/opensslconf.h> before any references, rather
than relying on another header to pull this in.

Only hash known CH extensions

RFC 4.1.2 specifies the ways in which the extensions in the first and
the second ClientHello may differ. It basically says that extensions
not known to a server must not change. This in turn makes it impossible
to introduce new extensions that do change. It makes little sense to
enforce that extensions we don't know and care about aren't modified,
so make the hashing more lenient and restrict it to the extensions we
do care about. Arguably, enforcing no change in an unknown extension
is incompatible with the requirement that it be ignored.

ok bcook jsing

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@

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@

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@

Remove bogus DTLS checks to disable ECC and OCSP.

ECC and OCSP can be used with DTLS, so remove bogus checks that currently
prevent it. These are long lasting remnants from the original OpenSSL code.

ok tb@

Replace SSL_IS_DTLS with SSL_is_dtls().

Garbage collect the now unused SSL_IS_DTLS macro.

ok tb@

Constipate srtp_known_profiles, pushing it into .data.rel.ro

ok tb@ jsing@

Constipate ssl3_ciphers and tls1[23]_sigalgs*, pushing them into
.data.rel.ro and .rodata respectively.

ok tb@ jsing@

Set alpn_selected_len = 0 when alpn_selected is NULL

ok jsing@ tb@

Only parse a client's status_request in the CH

A client should only send a status_request as part of the CH.

Pointed out by Michael Forney

ok inoguchi jsing

Ensure clients only send a status_request in the CH

The current code might cause a client to send a status_request
containing a CertificateStatusRequest with its certificate. This
makes no sense.

Pointed out by Michael Forney

ok inoguchi jsing

Correctly handle server requests for an OCSP response

According to RFC 8446, 4.4.2.1, a server may request that a client
present an OCSP response with its certificate by sending an empty
status_request extension as part of the certificate request. The
current code expects a full CertificateStatus structure, which is
only sent if the server sends an OCSP response with its certificate.

This causes interoperability issues with Go's TLS server and with
newer GnuTLS where we would abort the handshake with a decode_error
alert and length mismatch error.

Issue reported and diagnosed by Michael Forney
Problem also found by Mikolaj Kucharski and inoguchi.

ok inoguchi jsing

zap trailing whitespace on one line

Make the message type available to the extension functions

Some TLS extensions need to be treated differently depending on the
handshake message they appear in. Over time, various workarounds and
hacks were used to deal with the unavailability of the message type
in these functions, but this is getting fragile and unwieldy. Having
the message type available will enable us to clean this code up and
will allow simple fixes for a number of bugs in our handling of the
status_request extension reported by Michael Forney.

This approach was suggested a while ago by jsing.

ok beck jsing

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

Implement a rolling hash of the ClientHello message, Enforce RFC 8446
section 4.1.2 to ensure subsequent ClientHello messages after a
HelloRetryRequest messages must be unchanged from the initial
ClientHello.

ok tb@ jsing@

Mop up servername_done, which is unused.

ok beck@ inoguchi@ tb@

Fix some stylistic nits from jsing.

ok jsing

Enforce that SNI hostnames be correct as per rfc 6066 and 5980.
Correct SNI alerts to differentiate between illegal parameter
and an unknown name.

ok tb@`

Do not assume that server_group != 0 or tlsext_supportedgroups != NULL
implies that we're dealing with a HRR in the extension handling code.

Explicitly check that we're in this situation by inspecting the flag in
the handshake context. Add missing error checks and send the appropriate
alerts. The hrr flag needs to be unset after parsing the client hello
retry to avoid breaking the server hello handling. All this is far from
ideal, but better than nothing.

The correct fix would likely be to make the message type available
but that would need to be part of a more extensive rearchitecture of
the extension handling.

Discussed at length with jsing

Only send ocsp staples if the client asked for ocsp certificate status.
noticed by dlg@ on www.openbsd.org with curl.

ok dlg@

Add support for TLS 1.3 server to send certificate status
messages with oscp staples.

ok jsing@ tb@

Fix pesky whitespace.

Use size_t for OCSP response length.

The OCSP response length is currently an integer, which is overloaded with
-1 meaning "unset". Use a size_t for the OCSP response length and infer
unset from the OCSP response being NULL. This makes code more readable,
simpler and less error prone.

ok beck@

Only reset TLS extension state when parsing client hello or server hello.

With TLSv1.3 we end up parsing extensions from more than just these two
messages. This can result in variables (like the selected alpn) being
freed when things still need them.

ok tb@

Add support for certificate status requests in TLS 1.3 client
ok jsing@, tb@, inoguchi@

Add support for HelloRetryRequests in the TLSv1.3 server.

ok inoguchi@ tb@

branches: 1.63.4;
Handle TLSv1.3 key shares other than X25519 on the server side.

Previously we would only select an X25519 key share from the client,
ignoring any others. Change this so that we will select the first of the
key shares that matches one of our supported groups.

ok beck@ inoguchi@ tb@

drop unused include <openssl/curve25519.h>

ok inoguchi jsing

Avoid potential NULL dereference when parsing a server keyshare extension.

It is currently possible for key_share to be NULL when a TLS client
receives a keyshare extension. However, for this to occur the client has
to be doing TLS 1.2 or earlier, which means that it was invalid for the
server to send the extension. As such, check for NULL and treat it as an
invalid extension.

Found by oss-fuzz (#20741 and #20745).

ok inoguchi@ tb@

Correctly handle key share extensions in a hello retry request.

In a hello retry request the server will only send the selected group and
not actually provide a key exchange. In this case we need to store the
server selected group for further processing.

ok tb@

Correctly unpack client key shares.

Even if we're not processing/using the peer public key from the key share,
we still need to unpack it in order to parse the TLS extension correctly.
Resolves issues with TLSv1.3 clients talking to TLSv1.2 server.

ok tb@

Provide struct/functions for handling TLSv1.3 key shares.

Pull out the key share handling code and provide a clean/self contained
interface. This will make it easier to support groups other than X25519.

ok beck@ inoguchi@ tb@

Add sigalgs for server side to enable client certificate processing
in tls 1.3

Will be used in a follow on commit to enable tls1.3 client certificates

ok jsing@

Only discard the extension block for client hello and server hello
messages.

TLSv1.3 messages that include extensions need a length prefixed field with
zero bytes, rather than no data at all.

ok beck@ tb@

Only send an RI extension for pre-TLSv1.3 versions.

ok beck@

Rename failure into alert_desc in tlsext_ocsp_server_parse().

fix previous: alert_desc needs to be an int.

Avoid modifying alert in the success path.

ok beck jsing

Revert previous deduplication diff, I broke portable in a strange way.
I'll figure it out a bit later.
Found and diagnosed by inoguchi@

Deduplicate some extension processing code.

ok tb@ inoguchi@

Relax parsing of TLS key share extensions on the server.

The RFC does not require X25519 and it also allows clients to send an empty
key share when the want the server to select a group. The current behaviour
results in handshake failures where the client supports TLS 1.3 and sends a
TLS key share extension that does not contain X25519.

Issue reported by Hubert Kario via github.

ok tb@

Do not send an SNI extension when resuming a session that contains a server
name (which means the client sent SNI during the initial handshake).

Issue reported by Renaud Allard.

ok tb@

Fix typo and label indent.

Tidy up some names/structures following the renaming of TLS extension
functions based on message type (clienthello/serverhello), to which side
is handling the processing.

No intended functional change.

ok beck@

In DTLS, use_srtp is part of the extended server hello while in TLSv1.3,
it is an encrypted extension. Include it in the server hello for now.
This will have to be revisited once TLSv1.3 gets there. Fixes SRTP
negotiation.

Problem found by two rust-openssl regress failures reported by mikeb.

with & ok beck

branches: 1.44.2;
Defer sigalgs selection until the certificate is known.

Previously the signature algorithm was selected when the TLS extension was
parsed (or the client received a certificate request), however the actual
certificate to be used is not known at this stage. This leads to various
problems, including the selection of a signature algorithm that cannot be
used with the certificate key size (as found by jeremy@ via ruby regress).

Instead, store the signature algorithms list and only select a signature
algorithm when we're ready to do signature generation.

Joint work with beck@.

Revert TLS1_get{,_client}_version simplification because DTLS.

Partially clean up the TLS1_get_{,client}_version macros.

LibreSSL only supports TLSv1.0 and above, hence the checks the macros are
performing are useless. Simplify them to their effective code. Also place
both under #ifndef LIBRESSL_INTERNAL and use the variables directly in our
code, which improves readability.

ok tb@

Revert r1.38 as it introduces use of a stack value post function return.

The deduplication is also not quite right - this will be revisited in due
course.

unwrap a line introduced in previous.

Correct handling of TLS sigalgs extension for TLSv1.0/TLSv1.1.

When operating as a TLSv1.0 or TLSv1.1 server, we still have to parse the
TLS sigalgs extension if presented by the client (which might be TLSv1.2
capable), rather than treating its presence as an error.

While here, remove future version dependence issues by avoiding explicit
version equality checks.

Issue reported by bluhm@.

ok bluhm@ tb@

Deduplicate a bunch of replicated code in the extension handling
ok tb@

Add tls_extension_seen(), a utility to know if a particular extension
has been seen in the handshake so far. Use it for keyshare.
ok tb@

Add server side of versions, keyshare, and client and server of cookie
extensions for tls1.3.
versions is currently defanged to ignore its result until tls13 server
side wired in full, so that server side code still works today when
we only support tls 1.2
ok bcook@ tb@ jsing@

move the extensions_seen into the handshake struct
ok jsing@

Modify sigalgs extension processing to accomodate TLS 1.3.
- Make a separate sigalgs list for TLS 1.3 including only modern
algorithm choices which we use when the handshake will not negotiate
TLS 1.2.
- Modify the legacy sigalgs for TLS 1.2 to include the RSA PSS algorithms as
mandated by RFC8446 when the handshake will permit negotiation of TLS 1.2
from a 1.3 handshake.
ok jsing@ tb@

revert previous, accidentally contained another diff in addition
to the one I intended to commit

Modify sigalgs extension processing for TLS 1.3.
- Make a separate sigalgs list for TLS 1.3 including only modern
algorithm choices which we use when the handshake will not negotiate
TLS 1.2
- Modify the legacy sigalgs for TLS 1.2 to include the RSA PSS algorithms as
mandated by RFC8446 when the handshake will permit negotiation of TLS 1.2
ok jsing@ tb@

TLS 1.3 clients always need to send the supported groups extension.

A couple of cleanup/style tweaks while here.

ok tb@

bump copyright years appopriately

Add client side of supported versions and keyshare extensions with basic regress
ok jsing@

Add support for RFC 8446 section 4.2 enforcing which extensions may
appear with which messages.
ok jsing@

Rename TLS extension handling to use less "hello".

When the TLS extension code was rewritten, TLS extensions could only exist
in ClientHello and ServerHello messages - as such, they were named in pairs
of *_clienthello_{needs,build} which would be called by the client and
*_clienthello_parse. Likewise for *_serverhello_{needs,build} which would
be called by a server and *_serverhello_parse, which would be called by a
client.

Enter TLSv1.3 - TLS extensions can now exist in one of seven messages,
with only certain types being allowed to appear in each, meaning the naming
scheme no longer works. Instead, rename them to indicate the caller rather
than the message type - this effectively means:

clienthello_needs -> client_needs
clienthello_build -> client_build
clienthello_parse -> server_parse
serverhello_needs -> server_needs
serverhello_build -> server_build
serverhello_parse -> client_parse

ok beck@ tb@

Add the ability to have a separate priority list for sigalgs.
Add a priority list for tls 1.2
ok jsing@

Reimplement the sigalgs processing code into a new implementation
that will be usable with TLS 1.3 with less eye bleed.
ok jsing@ tb@

Rename the TLS Supported Elliptic Curves extension to Supported Groups.

RFC 7919 renamed the Supported Elliptic Curves TLS extension to Supported
Groups and redefined it to include finite field DH (FFDH) in addition to
elliptic curve DH (ECDH). As such, rename the TLS extension and change the
associated code to refer to groups rather than curves.

ok beck@ tb@

Rework the TLS extension handling code to improve readability/flexibility,
by moving the needs/build/parse functions into their own struct.

ok beck@ tb@

If we fail to decode an EC point format extension, send a decode_error
alert rather than an internal_error alert.

Issue found by Simon Friedberger, Robert Merget and Juraj Somorovsky.

ok beck@ inoguchi@

Complete the TLS extension rewrite on the client-side.

The RI logic gets pulled up into ssl3_get_server_hello() and
ssl_parse_serverhello_tlsext() gets replaced by tlsext_client_parse(),
which allows a CBS to be passed all the way down.

This also deduplicates the tlsext_client_build() and tlsext_server_build()
code.

ok beck@

Complete the TLS extension handling rewrite for the server-side.

This removes ssl_parse_clienthello_tlsext() and allows the CBS to be
passed all the way through from ssl3_get_client_hello(). The renegotation
check gets pulled up into ssl3_get_client_hello() which is where other
such checks exist.

The TLS extension parsing now also ensures that we do not get duplicates
of any known extensions (the old pre-rewrite code only did this for some
extensions).

ok inoguchi@

Clarify the comment re the F5 EC curves extension bug.

Also reference the knowledge base article instead of a discussion thread.

Correct TLS extensions handling when no extensions are present.

If no TLS extensions are present in a client hello or server hello, omit
the entire extensions block, rather than including it with a length of
zero.

ok beck@ inoguchi@

branches: 1.17.4;
Fix various issues in the OCSP extension parsing code:

- When parsing the OCSP extension we can have multiple responder IDs - pull
these out correctly.

- Stop using CBS_stow() - it's unnecessary since we just need access to the
data and length (which we can get via CBS_data() and CBS_len()).

- Use a temporary pointer when calling d2i_*() functions, since it will
increment the pointer by the number of bytes it consumed when decoding.

The original code incorrectly passes the pointer allocated via CBS_stow()
(using malloc()) to a d2i_*() function and then calls free() on the now
incremented pointer, most likely resulting in a crash. This issue was
reported by Robert Swiecki who found the issue using honggfuzz.

ok beck@

When building the OCSP extension, only add the length prefixed extensions
after we finish building the responder ID list. Otherwise adding to the
responder ID list fails.

ok beck@

Move the full extension building into tlsext_{client,server}hello_build(),
leaving ssl_add_{client,server}hello_tlsext() as pointer to CBB wrappers.

ok doug@

When OCSP status type is unknown, ignore the extension.

This needs to skip past the CBS data or it will be treated as a decode
error even though it returns 1.

ok jsing@

Actually parse the ALPN extension in a client hello, even if no ALPN
callback has been installed. This ensures that the ALPN extension is valid
and avoids leaving unprocessed extension data, which leads to a decode
error.

Found the hard way by jsg@

Rewrite SRTP extension using CBB/CBS and the new extension framework.

input + ok beck@, jsing@

Rewrite ALPN extension using CBB/CBS and the new extension framework.

ok bcook@ beck@
input + ok jsing@

Work around bug in F5's handling of the supported elliptic curves extension.

RFC 4492 only defines elliptic_curves for ClientHello. However, F5 is
sending it in ServerHello. We need to skip over it since our TLS extension
parsing code is now more strict.

Thanks to Armin Wolfermann and WJ Liu for reporting the issue.

input + ok jsing@

Rewrite the TLS status request extension to use the new TLS extension framework.
ok jsing@

Convert TLS signature algorithms extension handling to the new framework.

ok beck@ doug@

Rewrite session ticket TLS extension handling using CBB/CBS and the new
extension framework.

ok jsing@ beck@

Rewrite EllipticCurves TLS extension handling using CBB/CBS and the new
extension framework.

input + ok jsing@

Add doug@'s copyright since he just added code to these two files.

Rewrite the ECPointFormats TLS extension handling using CBB/CBS and the
new extension framework.

input + ok jsing@

Rewrite and move the last remnants of the ServerHello SNI handling into
tlsext_sni_serverhello_parse(). This also adds a check to ensure that
if we have an existing session, the name matches what we specified via
SNI.

ok doug@

Rewrite the TLS Renegotiation Indication extension handling using CBB/CBS
and the new extension framework.

Feedback from doug@

ok inoguchi@

Start rewriting TLS extension handling.

Introduce a TLS extension handling framework that has per-extension type
functions to determine if an extension is needed, to build the extension
data and parse the extension data. This is somewhat analogous to BoringSSL,
however these build and parse functions are intentionally symetrical. The
framework is hooked into the existing TLS handling code in such a way that
we can gradual convert the extension handling code.

Convert the TLS Server Name Indication extension to the new framework,
while rewriting it to use CBB/CBS and be more strict in the process.

Discussed with beck@

ok inoguchi@

Recommit a better version of the removal of the F5 workaround

Unlike for previous TLS versions, TLSv1.3 servers can send the supported
groups extension to inform a client of the server's preferences. The
intention is that a client can adapt for subsequent commits. We ignore
this info for now, but sthen ran into java-based servers that do this.

Thus, rejecting the extension outright was incorrect. Instead, only allow
the extension in TLSv1.3 encrypted extensions. This way the F5 workaround
is also disabled, but we continue to interoperate with TLSv1.3 servers that
do follow the last paragraph of RFC 8446, section 4.2.7.

This mostly adjusts outdated/misleading comments.

ok jsing sthen

Backout previous commit (intending that libressl client rejects a supported
groups extension from the server). It triggers 'CONNECT_CR_SRVR_HELLO:tlsv1
alert decode error' when connecting to a (modern) java server (tomcat 10.1.18
on openjdk 17.0.10).

"please revert" tb@

Stop pandering to the loadbalancer industrial complex.

So we initially kept this hack around for f5 boxes that
should have been patched in 2014, and were not as of 2017.

The f5 article for the bug archived on their web site,
and any of these devices on the public internet will have
since been upgraded to deal with a host of record layer, TLS,
and other bugs, or they likely won't be talking to modern
stacks, since as of this point the software with the bug
would not have been updated in 10 years.

So just make this spec compliant and reject a supported groups
extension that should not have been sent by a server.

ok tb@ jsing@

Fix up server processing of key shares.

Ensure that the client can not provide a duplicate key share
for any group, or send more key shares than groups they support.

Ensure that the key shares must be provided in the same order
as the client preference order specified in supported_groups.

Ensure we only will choose to use a key share that is for the
most preferred group by the client that we also support,
to avoid the client being downgraded by sending a less preferred
key share. If we do not end up with a key share for the most preferred
mutually supported group, will then do a hello retry request
selecting that group.

Add regress for this to regress/tlsext/tlsexttest.c

ok jsing@

Do not allow duplicate groups in supported groups.

While we are here refactor this to single return.

ok jsing@ tb@

Add an indicator that an extension has been processed.

ok jsing@

Process supported groups before key share.

This will allow us to know the client preferences for an upcoming
change to key share processing.

ok jsing@

Simplify TLS extension parsing and processing.

Rather than having a separate parse and process step for each TLS
extension, do a first pass that parses all of the TLS outer extensions and
retains the extension data, before running a second pass that calls the TLS
extension processing code.

ok beck@ tb@

Fix typo msg_types -> msg_type

from jsing

Split TLS extension parsing from processing.

The TLS extension parsing and processing order is currently dependent on
the order of the extensions in the handshake message. This means that the
processing order (and callback order) is not under our control. Split the
parsing from the processing such that the processing (and callbacks) are
run in a defined order.

Convert ALPN to the new model - other extensions will be split into
separate parse/process in following diffs.

ok beck@ tb@

Decouple TLS extension table order from tlsext_randomize_build_order()

The PSK extension must be the last extension in the client hello. This is
currently implemented by relying on the fact that it is the last extension
in the TLS extension table. Remove this dependency so that we can reorder
the table as needed.

ok tb@

Too many stupid things whine about these being used uninitialized
(which they aren't), so appease them.

ssl_tlsext.c: Add an accessor for the tls extension type.

Needed for the tlsexttest.c

ok jsing

Fix allocation size

Reported by anton

Free and calloc() the tlsext_build_order and remember its length

Aligns tlsext_randomize_build_order() with tlsext_linearize_build_order()
and will help regression testing.

ok jsing

Use TLSEXT_TYPE_alpn instead of the stupid long one

Randomize the order of TLS extensions

On creation of an SSL using SSL_new(), randomize the order in which the
extensions will be sent. There are several constraints: the PSK extension
must always come last. The order cannot be randomized on a per-message
basis as the strict interpretation of the standard chosen in the CH hashing
doesn't allow changing the order between first and second ClientHello.

Another constraint is that the current code calls callbacks directly on
parsing an extension, which means that the order callbacks are called
depends on the order in which the peer sent the extensions. This results
in breaking apache-httpd setups using virtual hosts with full ranomization
because virtual hosts don't work if the SNI is unknown at the time the
ALPN callback is called. So for the time being, we ensure that SNI always
precedes ALPN to avoid issues until this issue is fixed.

This is based on an idea by David Benjamin
https://boringssl-review.googlesource.com/c/boringssl/+/48045

Input & 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 *_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

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@

Avoid shadowing the cbs function parameter in tlsext_alpn_server_parse()

ok jsing

Make tlsext_*_{build,needs,parse}() functions static

None of these functions are used outside of ssl_tlsext.c. The only reason
they are prototyped in the header is for the use of tlsexttest.c. Rather
than having a big pile of useless copy-paste in the header, we can adapt
the test to avoid using these functions directly.

ok jsing

Rely on tlsext_parse() to set a decode_error alert

Instead of setting the alert manually in various parse handlers, we can
make use of the fact that tlsext_parse() sets the alert to decode_error
by default. This simplifies the code quite a bit.

ok jsing

Remove redundant length checks in parse functions

The main parsing function already checks that the entire extension data
was consumed, so the length checks inside some of the parse handlers are
redundant. They were also not done everywhere, so this makes the parse
handlers more consistent.

Similar diff was sent by jsing a long while back

ok jsing

Simplify tlsext_supported_groups_server_parse

Add an early return in the s->internal->hit case so that we can unindent
a lot of this code. In the HRR case, we do not need to check that the list
of supported groups is unmodified from the first CH. The CH extension
hashing already does that for us.

ok jsing

Drop some unnecessary parentheses.

ok jsing

Copy alpn_selected using CBS

ok jsing

Factor out ALPN extension format check

The ALPN extension must contain a non-empty list of protocol names.
Split a check of this out of tlsext_alpn_server_parse() so that it
can be reused elsewhere in the library.

ok jsing

Correct handling of QUIC transport parameters extension.

Remove duplicate U16 length prefix, since tlsext_build() already adds this
for us. Condition on SSL_is_quic() rather than TLS version - RFC 9001 is
clear that this extension is only permitted on QUIC transport and an
fatal unsupported extension alert is required if used elsewhere.
Additionally, at the point where extensions are parsed, we do not
necessarily know what TLS version has been negotiated.

ok beck@ tb@

Correct TLSEXT_TYPE_quic_transport_parameters message types.

Per RFC 9001, TLSEXT_TYPE_quic_transport_parameters may only appear in
ClientHello and EncryptedExtensions (not ServerHello).

ok beck@ tb@

Stop using ssl{_ctx,}_security() outside of ssl_seclevel.c

The API is ugly and we can easily abstract it away. The SSL_SECOP_* stuff
is now confined into ssl_seclevel.c and the rest of the library can make
use of the more straightforward wrappers, which makes it a lot easier on
the eyes.

ok beck jsing

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

Check security level for supported groups.

ok jsing

Check whether the security level allows session tickets.

ok beck jsing

Add support for sending QUIC transport parameters

This is the start of adding the boringssl API for QUIC support,
and the TLS extensions necessary to send and receive QUIC transport
data.

Inspired by boringssl's https://boringssl-review.googlesource.com/24464

ok jsing@ tb@

Check the security level when building sigalgs

ok beck jsing

The parse stubs need to skip over the extension data.

Found by anton with tlsfuzzer

ok anton

Add stubbed out handlers for the pre_shared_key extension

ok jsing

Implement handlers for the psk_key_exchange_modes extensions.

ok jsing

Bye bye S3I.

S3I has served us well, however now that libssl is fully opaque it is time
to say goodbye. Aside from removing the calloc/free/memset, the rest is
mechanical sed.

ok inoguchi@ tb@

Avoid use of uninitialized in tlsext_sni_server_parse()

If the hostname is too long, tlsext_sni_is_valid_hostname() will fail
without having initialized *is_ip. As a result, the garbage value could
lead to accepting (but otherwise ignoring) overlong and possibly invalid
hostnames without erroring in tlsext_sni_server_parse().

ok inoguchi jsing

Plumb decode errors through key share parsing code.

Distinguish between decode errors and other errors, so that we can send
a SSL_AD_DECODE_ERROR alert when appropriate.

Fixes a tlsfuzzer failure, due to it expecting a decode error alert and
not receiving one.

Prompted by anton@

ok tb@

Use SSL_AD_INTERNAL_ERROR for non-decoding alerts when parsing keyshares.

ok tb@

Simplify tlsext_keyshare_server_parse()

SSL_AD_DECODE_ERROR is the default alert for a TLS extension parsing
failure - remove the various gotos and simply return 0 instead.

ok tb@

Convert legacy TLS client to tls_key_share.

This requires adding DHE support to tls_key_share. In doing so,
tls_key_share_peer_public() has to lose the group argument and gains
an invalid_key argument. The one place that actually needs the group
check is tlsext_keyshare_client_parse(), so add code to do this.

ok inoguchi@ tb@

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@

Pull key share group/length CBB code up from tls13_key_share_public()

This provides better symmetry with the parsing code and will allow for
better reuse with the legacy stack, which has different message structures.

ok inoguchi@ tb@

Only allow zero length key shares when we know we're doing HRR.

ok inoguchi@ tb@

Improve SNI hostname validation.

For some time now we've validated the hostname provided to the server in
the SNI extension. Per RFC 6066, an IP literal is invalid as a hostname -
the current code rejects IPv6 literals, but allows IPv4 literals through.

Improve this check to explicitly detect both IPv4 and IPv6 literals. Some
software has been historically known to include IP literals in SNI, so
rather than rejecting this outright (and failing with a decode error),
pretend that the SNI extension does not exist (such that we do not break
some older clients).

ok inoguchi@ tb@

Fold SSL_SESSION_INTERNAL back into SSL_SESSION.

ok beck@ tb@

Do not ignore SSL_TLSEXT_ERR_FATAL from the ALPN callback

As reported by Jeremy Harris, we inherited a strange behavior from
OpenSSL, in that we ignore the SSL_TLSEXT_ERR_FATAL return from the
ALPN callback. RFC 7301, 3.2 states: 'In the event that the server
supports no protocols that the client advertises, then the server
SHALL respond with a fatal "no_application_protocol" alert.'

Honor this requirement and succeed only on SSL_TLSEXT_ERR_{OK,NOACK}
which is the current behavior of OpenSSL. The documentation change
is taken from OpenSSL 1.1.1 as well.

As pointed out by jsing, there is more to be fixed here:
- ensure that the same protocol is selected on session resumption
- should the callback be called even if no ALPN extension was sent?
- ensure for TLSv1.2 and earlier that the SNI has already been processed

ok beck jsing

Correct the is_server flag in the call to the debug callback to be correct.
ok tb@

Use appropriate TLS version when building client sigalg extensions.

Only use the minimum TLS version to when building a signature algorithms
extension for a ClientHello - in all other cases we should be using the
negotiated TLS version.

ok inoguchi@ tb@

Change ssl_sigalgs_build() to perform sigalg list selection.

Rather that doing sigalg list selection at every call site, pass in the
appropriate TLS version and have ssl_sigalgs_build() perform the sigalg
list selection itself. This reduces code duplication, simplifies the
calling code and is the first step towards internalising the sigalg lists.

ok tb@

Only use SSL_AD_* internally.

Due to hysterical raisins there are three different types of defines for
alerts. SSL3_AD_* are from SSLv3, TLS1_AD_* are from TLSv1.0 onwards and
SSL_AD_* currently map to either an SSL3_AD_* or TLS1_AD_* define.

Currently, all three of these are used in various places - switch to using
just SSL_AD_* values internally, as a first step in cleaning this up.

ok tb@

Simplify tlsext_ecpf_parse()

The default alert in the tlsext parsing code is a decode_error, so
there's no need for an error path that only sets that alert.

suggested by/ok jsing

Adjust alert for ECPF without uncompressed point format

According to RFC 8422, we must send an illegal_parameter alert on
receiving an ECPF extension that doesn't include the uncompressed
format, not a decode_error.

Reported via GitHub issue #675.

ok jsing

Make local header inclusion consistent.

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

Explicitly include <openssl/opensslconf.h> in files using OPENSSL_NO_*

Where a file references to OPENSSL_NO_* conditions, ensure that we
explicitly include <openssl/opensslconf.h> before any references, rather
than relying on another header to pull this in.

Only hash known CH extensions

RFC 4.1.2 specifies the ways in which the extensions in the first and
the second ClientHello may differ. It basically says that extensions
not known to a server must not change. This in turn makes it impossible
to introduce new extensions that do change. It makes little sense to
enforce that extensions we don't know and care about aren't modified,
so make the hashing more lenient and restrict it to the extensions we
do care about. Arguably, enforcing no change in an unknown extension
is incompatible with the requirement that it be ignored.

ok bcook jsing

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@

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@

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@

Remove bogus DTLS checks to disable ECC and OCSP.

ECC and OCSP can be used with DTLS, so remove bogus checks that currently
prevent it. These are long lasting remnants from the original OpenSSL code.

ok tb@

Replace SSL_IS_DTLS with SSL_is_dtls().

Garbage collect the now unused SSL_IS_DTLS macro.

ok tb@

Constipate srtp_known_profiles, pushing it into .data.rel.ro

ok tb@ jsing@

Constipate ssl3_ciphers and tls1[23]_sigalgs*, pushing them into
.data.rel.ro and .rodata respectively.

ok tb@ jsing@

Set alpn_selected_len = 0 when alpn_selected is NULL

ok jsing@ tb@

Only parse a client's status_request in the CH

A client should only send a status_request as part of the CH.

Pointed out by Michael Forney

ok inoguchi jsing

Ensure clients only send a status_request in the CH

The current code might cause a client to send a status_request
containing a CertificateStatusRequest with its certificate. This
makes no sense.

Pointed out by Michael Forney

ok inoguchi jsing

Correctly handle server requests for an OCSP response

According to RFC 8446, 4.4.2.1, a server may request that a client
present an OCSP response with its certificate by sending an empty
status_request extension as part of the certificate request. The
current code expects a full CertificateStatus structure, which is
only sent if the server sends an OCSP response with its certificate.

This causes interoperability issues with Go's TLS server and with
newer GnuTLS where we would abort the handshake with a decode_error
alert and length mismatch error.

Issue reported and diagnosed by Michael Forney
Problem also found by Mikolaj Kucharski and inoguchi.

ok inoguchi jsing

zap trailing whitespace on one line

Make the message type available to the extension functions

Some TLS extensions need to be treated differently depending on the
handshake message they appear in. Over time, various workarounds and
hacks were used to deal with the unavailability of the message type
in these functions, but this is getting fragile and unwieldy. Having
the message type available will enable us to clean this code up and
will allow simple fixes for a number of bugs in our handling of the
status_request extension reported by Michael Forney.

This approach was suggested a while ago by jsing.

ok beck jsing

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

Implement a rolling hash of the ClientHello message, Enforce RFC 8446
section 4.1.2 to ensure subsequent ClientHello messages after a
HelloRetryRequest messages must be unchanged from the initial
ClientHello.

ok tb@ jsing@

Mop up servername_done, which is unused.

ok beck@ inoguchi@ tb@

Fix some stylistic nits from jsing.

ok jsing

Enforce that SNI hostnames be correct as per rfc 6066 and 5980.
Correct SNI alerts to differentiate between illegal parameter
and an unknown name.

ok tb@`

Do not assume that server_group != 0 or tlsext_supportedgroups != NULL
implies that we're dealing with a HRR in the extension handling code.

Explicitly check that we're in this situation by inspecting the flag in
the handshake context. Add missing error checks and send the appropriate
alerts. The hrr flag needs to be unset after parsing the client hello
retry to avoid breaking the server hello handling. All this is far from
ideal, but better than nothing.

The correct fix would likely be to make the message type available
but that would need to be part of a more extensive rearchitecture of
the extension handling.

Discussed at length with jsing