libtls: Add downgrade protection for TLS 1.3 and TLS 1.2

Section 4.1.3 in RFC 8446 defines a new downgrade protection mechanism
that also affects TLS 1.2.

tls-server: Optionally omit CAs in CertificateRequest messages

Usually, the DNs of all loaded CA certificates are included in the
CertificateRequest messages sent by the server.

Alas, certain EAP-TLS clients fail to process this message if the
list is too long, returning the fatal TLS alert 'illegal parameter'.

This new option allows configuring whether CAs are included or an
empty list is sent (TLS 1.2), or the certificate_authorities extension
is omitted (TLS 1.3).  The list only serves as hint/constraint
for clients during certificate selection, they still have to provide
a certificate but are free to select any one they have available.

Closes strongswan/strongswan#187.

tls-eap: Conclude EAP method also after processing packets

With TLS 1.3, the server sends its Finished message first, so the
session is complete after processing the client's Finished message,
without having to send anything else (in particular no acknowledgement
as the last message from the client is no fragment).

libtls: Only run socket tests with EdDSA keys if they are supported

ECDSA support is currently required to run the tests because ECDSA
cipher suites are not filtered when determining the supported cipher
suites.  Also required are ECDH groups.

tls-peer: Don't log anything if we are not sending supported groups

tls-crypto: Only log modified TLS versions if successfully set

If no cipher suites are available, the new versions are the previous
values but reversed (i.e. the versions were not changed but we still
ended up with a log message saying "TLS min/max TLS 1.3/TLS 1.0 ...").

Also switched to using the numeric version names to avoid the repeated
"TLS" prefix.

libtls: Reduce default max version to 1.2

Using TLS 1.3 with various EAP methods is not yet fully standardized, so we
don't enable it by default yet.

libtls: Make min/max TLS version configurable

Except for the tls_test tool, the versions now default to those
configured in strongswan.conf.

test-hkdf: Add two test cases and restructure all tests

RFC 8448 contains multiple TLS 1.3 message traces, this commit adds two
new test cases focusing on key derivation:

- Simple 1-RTT Handshake
- Resumed 0-RTT Handshake

Additionally, the whole test suite is restructured and duplicate code is
removed and consolidated.

tls-hkdf: Implement binder PSK generation

tls-hkdf: Implement resumption key generation

tls-peer: Mutual authentication support for TLS 1.3

tls-peer: Derive application traffic keys after server finished message

The inbound key is used right away, the outbound key only after the
client finished message has been sent.

tls-peer: Use private key enumeration also in TLS versions < 1.2

Until now, key selection was based on tls_client_certificate_type_t and now
uses a simple mapping from these types to tls_signature_scheme_t.

tls-crypto: Share private key search between client and server

This way the client also properly considers the TLS version and the signature
schemes supported by the server.

Co-authored-by: Tobias Brunner <tobias@strongswan.org>

tls-test: Add support to require/verify client certificates

Also add detailed usage output with description of all options.

tls-server: Mutual authentication support for TLS 1.3

This commit also addresses the side effect that additional messages have
an influence on the derivation of the application traffic secrets. Therefore,
key derivation is relocated after the server finished message has been sent,
so the additional messages from the client (Certificate, CertificateVerify)
don't affect the key derivation. Only the outbound key is switched there, the
inbound key remains in use until the client's finished message has been
processed.

tls-server: Terminate connection if peer certificate is required but not sent

This change mainly affects legacy TLS versions because TLS 1.3
connections are terminated by the server once the peer does not send a
CertificateVerify message next to its empty Certificate message.

tls-server: Make CertificateRequest conditional in old TLS versions

The server implementation now only sends a CertificateRequest message if
it has identity information to verify client certificates.

tls-server: Share trusted public key search between client and server

tls-crypto: Move AEAD ownership to the protection layer

This separates key derivation from key switching.

tls-hkdf: Always use correct base key to derive finished message

The cached traffic secrets change once the application traffic secrets
are derived, but we must always use the correct base key to derive the
finished message, which are the handshake traffic secrets (RFC 8446,
section 4.4).

libtls: Add unit tests for Ed25519 and Ed448 keys

TLS 1.0 to TLS 1.3 socket connection tests with each key type.

tls-test: Load keys of any type

Only RSA keys were possible until now.

tls-crypto: Support EdDSA keys with ECDSA cipher suites

Ed25519 and Ed448 are now usable in all TLS versions for connections that
use an ECDSA cipher suite, as per RFC 8422.

tls-server: Consider supported signature algorithms when selecting key/certificate

This won't work if the client doesn't send a `signature_algorithms`
extension.  But since the default is SHA1/RSA, most will send it to at
least announce stronger hash algorithms if not ECDSA.

tls-crypto: Distinguish between signing and verifying signature schemes

strongSwan supports RSA_PSS_RSAE schemes for signing but does not
differentiate between rsaEncryption and rsassaPss encoding. Thus
RSA_PSS_PSS schemes are only used for verifying signatures.

tls-server: Check if peer sent hash and signature algorithms

It is mandatory to receive the `signature_algorithms` extension when a
server is authenticating with a certificate, which is always the case.

tls-crypto: Add missing signature scheme constants

Some peers, e.g. Firefox, send a wide range of signature algorithms. To
prevent numeric identifiers in the log these algorithms are added here.

tls-server: Fix invalid signature algorithm and supported groups parsing

The extension's content length field was wrongly added to the content data.

Fixes: 06109c4717 ("Implemented "signature algorithm" hello extension")

tls-server: Support multiple client key shares

A client can send one or multiple key shares from which the server picks
one it supports (checked in its preferred order).  A retry is requested if
none of the key shares are supported.

libtls: Add TLS version negotiation test cases

These client to server negotiation test cases are implemented:
- TLS 1.0 => TLS 1.3
- TLS 1.1 => TLS 1.3
- TLS 1.2 => TLS 1.3
- TLS 1.3 => TLS 1.3

- TLS 1.3 => TLS 1.0
- TLS 1.3 => TLS 1.1
- TLS 1.3 => TLS 1.2
- TLS 1.3 => TLS 1.3

- TLS 1.0 => TLS 1.2
- TLS 1.1 => TLS 1.2
- TLS 1.2 => TLS 1.2
- TLS 1.3 => TLS 1.2

tls-server: Support HelloRetryRequest (HRR)

Adds support to request and handle retries with a different DH group.

Only the first key share extension sent by the client is currently
considered, so this might result in protocol errors if the server requests
a group for which the client already sent a key share.

tls-crypto: Add support to configure DH groups to use

And add new test cases to test TLS 1.3 connections for each supported DH
group.

diffie-hellman: Add enum names that match proposal keywords

tls-crypto: Generalizing DH group to TLS group mapping

This simplifies writing the key share extension as the TLS group does
not have to be cached.

tls-server: Support KeyUpdate requests and answers

tls-server: Refactor writing of key share extensions

Client and server now share the same code to write this extension.

tls-server: TLS 1.3 support for TLS server implementation

Add basic support to establish a TLS 1.3 connection with a client capable
of the same protocol version.

tls-crypto: Rename parameter to be more consistent

Also add missing parameter in documentation of calculate_finished method.

tls-crypto: Fix invalid signature algorithm list building

List building also added an additional length field which is required by
client-side TLS extensions but not for server-side certificate request
extension. Now the method only returns a list of supported signature
algorithms and the implementation is responsible to add additional
length fields.

Fixes: 07f826af673d ("Fixed encoding of TLS extensions (elliptic_curves and signature_algorithms)")

libtls: Add missing cipher suite and TLS extension constants

- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256

- Encrypt then MAC
- Extended master secret
- Session ticket

and also add missing suites in the unit test.

tls-crypto: Rework cipher suite preference order

The reworked list follows the order of modern browsers such as
Firefox. The new order prefers more secure ciphers over weaker ones.

tls-server: Determine supported/configured suites and versions early

If we don't do this, we might negotiate a TLS version for which we don't
have any suites configured, so that the cipher suite negotiation
subsequently fails.

tls-crypto: Check if TLS versions and cipher suites match

Only suggest TLS versions of supported cipher suites.  For instance, do not
suggest TLS 1.3 if none of its cipher suites (requiring GCM/CCM or
ChaPoly) are available.

tls-peer: Don't initiate TLS connection if no cipher suites are supported

If zero cipher suites are left after all filters, tls-peer does not
try to establish a connection to the server anymore.

tls-test: Make plugin list configurable via environment variable

tls-peer: Return INVALID_STATE after changing TLS 1.3 keys

Even though we return from build(), we are not actually sending a response,
so we can't return NEED_MORE (would send an invalid ClientHello message) and
if we return SUCCESS, the EAP layer treats this as failure (there is a comment
in eap_authenticator_t about client methods never returning SUCCESS from
process()).  Instead we return INVALID_STATE, which allows tls_t.build() to
exit from the build() loop immediately and send the already generated Finished
message.

tls-crypto: Generate MSK for TLS 1.3

We generate material for both MSK and EMSK even though we only need the
former.  Because HKDF-Expand-Label(), on which the export functionality
is based, encodes the requested key length, we have to allocate the same
number of bytes as e.g. FreeRADIUS does (i.e. if we only request 64
bytes, those won't be the same as the first 64 bytes after requesting
128 bytes).

Unfortunately, key derivation for TLS-based methods is currently not
standardized for TLS 1.3.  There is a draft [1], which defines a scheme
that's different from previous versions (instead of individual label
strings it uses a single one and passes the EAP type/code as context
value to TLS-Export()).  The current code is compatible to FreeRADIUS
3.0.x, which doesn't implement it according to that draft yet (there are
unreleased changes for EAP-TLS, not for the other methods, but these only
switch the label, no context value is passed).  In a separate draft
for EAP-TLS [2] there is an altogether different scheme defined in the
latest version (label combined with EAP method, no context and separate
derivation for MSK and EMSK).

So this is a mess and we will have to change this later with the inevitable
compatibility issues (we should definitely disable TLS 1.3 by default).

[1] https://tools.ietf.org/html/draft-ietf-emu-tls-eap-types
[2] https://tools.ietf.org/html/draft-ietf-emu-eap-tls13

tls-hkdf: Add method that allows exporting key material

tls-hkdf: Handle label expansion inside expand_label()

We have to expand arbitrary external labels the same way when exporting
key material.

tls-hkdf: Pass secret to derive_secret() explicitly

tls-hkdf: Store OKM in local variables

tls-crypto: Add support for RSA-PSS signatures

PKCS#1 v1.5 signatures are not defined for use with TLS 1.3 (they can
only appear in certificates, we now send a signature_algorithms_cert
extension to indicate support for them).  So for RSA certificates, we
must support RSA-PSS signatures.

There are two sets of schemes, that are differentiated by the type of
RSA key used for the signature, one is for classic RSA keys (rsaEncryption
OID), which can also be used with PKCS#1 when using TLS 1.2, the other
is for RSA-PSS keys (RSASSA-PSS OID), which are not yet commonly
used (and can't be generated by our pki tool).  According to the RFC,
PSS must also be supported for TLS 1.2 if the schemes are included in
the signature_algorithms extension (e.g. OpenSSL does not use PKCS#1 v1.5
anymore if PSS is proposed).

This changes how these schemes are stored and enumerated (they are not
treated as combination of hash algo and key type anymore).

Legacy schemes (MD5/SHA-1) are removed.

tls-peer: Support answering KeyUpdate requests

tls-socket: Change how EOF of the underlying socket is handled

With the previous code, there was an issue when replying to TLS 1.3
post-handshake messages.  In this case, SUCCESS is eventually returned
from build(), however, no actual data has been received so in_done is 0.
This was interpreted as EOF, plain_eof was set to TRUE and no further data
was read from the socket afterwards.

Returning SUCCESS from build() if the exchange is initiated by
write_(), as is the case with the finished reply, never was a problem
because there the return value of 0 is not interpreted as EOF.

tls-peer: Add support to handle KeyUpdate message

We currently don't support switching our own keys and sending the
message if requested by the server.

tls-crypto: Add method to update application traffic keys

tls-hkdf: Support updating client/server traffic secrets

tls-socket: Don't fail reading if sending data failed

If data is processed that eventually includes a TLS close notify, build()
will fail after a close notify has been sent in turn.  However, propagating
that error immediately when reading prevented ever returning the data
already processed before the close notify was received.

tls-peer: Correctly handle classic ECDH key-share format

Similar to TLS 1.2 but uses a 16-bit length header.

tls-test: Add options to configure TLS versions

tls-socket: Allow configuring both minimum and maximum TLS versions

tls: Allow setting both minimum and maximum TLS versions

This allows to increase the initial minimum version and also prevents
sending a list of versions during retries when 1.3 was already
negotiated.

tls-peer: Handle HelloRetryRequest

Adds support to handle retries with different DH group and/or a cookie
extension.

tls-crypto: Add method to hash handshake data and use result as initial transcript

This is used for HelloRetryRequest.

tls-crypto: Destroy HKDF instance if keys are derived multiple times

This will be the case during a retry.

tls-peer: Refactor writing of extensions and use less hard-coded DH group

Note that this breaks connecting to many TLS 1.3 servers until we support
HelloRetryRequest as we now send a key_share for ECP_256 while still
proposing other groups, so many servers request to use CURVE_25519.

tls-peer: Refactor sending/processing finished message

Also fixes leaks.

tls-peer: Simply ignore certificate request context

This SHALL be zero length for server authentication anyway.

tls-peer: Use existing code to verify certificate and signature

tls-peer: Refactor parsing of TLS extensions

Also adds proper error handling.

tls-peer: Fix parsing of encrypted extensions

tls-peer: Fix parsing of intermediate CA certificates

tls-crypto: Rename methods to calculate finished message

Instead of the version number use "legacy" for the one for earlier TLS
versions.

tls-crypto: Use internal PRF of tls-hkdf to generate finished message

Also adds additional checks.

tls-hkdf: Add helper method to allocate data from the internal PRF

tls-hkdf: Cleanups and refactorings

The main refactoring is how secrets (PSK/DH) are handled.

tls-crypto: Simplify signature creation/verification

tls-crypto: Simplify handshake/application key derivation and rename methods

Also consistently change the ciphers outside of tls_crypto_t and
simplify key derivation in tls_peer_t and fix a memory leak.

tls-hkdf: Make labels enum a proper type

tls-peer: Support x25519/448 for TLS 1.2

These DH groups don't use the point format prefix (RFC 8422 deprecated
any other format anyway).  Since they are enumerated now, they can also
be used by servers for TLS 1.2.

tls-crypto: Enumerate x25519/448 and rename constant for consistency

tls-crypto: Simplify hash algorithm handling

tls-crypto: Delay instantiation of cipher suites

This way we can take into account the version set via setter on tls_t.

tls-crypto: Filter TLS cipher suites by min/max version

There is no point proposing legacy (or future) cipher suites depending on
the proposed TLS versions. It was actually possible to negotiate and use
cipher suites only defined for TLS 1.2 with earlier TLS versions.

tls-crypto: Correctly filter cipher suites based on PRF algorithms

The previous check operated on the first array element.

tls-crypto: Use correct key length for ChaCha20/Poly1305

libtls: Some code style fixes

tls-test: Make address family configurable and simplify DNS/socket handling

libtls: Implement TLS 1.3 handshake on client-side

The code is a minimal handshake with the HelloRetryRequest message
implementation missing.
Can be tested with an OpenSSL server running TLS 1.3. The server must
be at least version 1.1.1 (September 2018).

Co-authored-by: ryru <pascal.knecht@hsr.ch>

libtls: Implement HKDF for TLS 1.3

TLS 1.3 uses HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
as defined in RFC 5869 to compute traffic secrets.

Co-authored-by: bytinbit <meline.sieber@hsr.ch>

libtls: Add support to run unit tests with a custom plugin list

libtls: Add TLS 1.3 implementation of tls_aead_t

The key material, in particular the nonce/IV, is derived differently and
the IV is also generated in a different way.  Additionally, the actual
content type is encrypted and there may be optional padding to mask the
actual size of the encrypted data.

libtls: Allow tls_aead_t to change the content type

The actual content type is encrypted with TLS 1.3, the type in the record
header is always Application Data.

testing: extended sleep time tkm/xfrmproxy tests

Version bump to 5.9.2dr2

testing: Copy /etc/resolv.conf from host in chroot script

This makes installing packages etc. easier.

appveyor: Set timezone on the build system

For some reason, setting the time zone via TZ to `GST-1GDT` in the utils test
doesn't work anymore (the DST zone is not considered, it's as if only `GST-1`
was configured).

appveyor: Create dummy strongswan.conf file to avoid log messages

Only relevant when increasing the verbosity, but causes quite a lot of
them then.