If the default group listed in the cipher suite is not supported, we try
to use any other supported group (the groups are negotiated separately
so we are not locked in to a specific group).
Since DH groups (or with TLS < 1.3 curves) are negotiated separately,
it doesn't matter which one is listed in the cipher suite as any one could
be used.
This was previously treated like a resumption, which it is clearly not.
Also added a check that verifies that the same cipher suite is selected
during the retry, as per RFC 8446, section 4.1.4.
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.
Closesstrongswan/strongswan#187.
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).
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.
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.
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.
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>
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.
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.
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).
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.
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.
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.
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.
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: 07f826af67 ("Fixed encoding of TLS extensions (elliptic_curves and signature_algorithms)")
- 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.
Tobias Brunner