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>
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)")
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.
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.
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.
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.
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.
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>
While the server signs the ephemeral DH parameters, it can be tricked to its
lowest supported DH group by a man-in-the-middle:
https://weakdh.org/imperfect-forward-secrecy.pdf
While we at least use 2048-bit DH groups as server, the client accepts any
DH prime the server sends. If it supports export ciphers, only a 512-bit prime
may be used.
As TLS does not define nor negotiate a DH group for cipher suites, the client
actually must accept what the server offers. To avoid downgrades to weak
DH groups, we must reject what we consider insecure. We set this limit to
1024-bit primes. While this breaks compatibility with TLS servers using weaker
primes, this is what we expect servers at least use. Most browser vendors use
the same limit in a similar fix.
In case a CA certificate uses the same subject DN as the server the
previous code could end up trying to verify the server's signature with
the CA certificate's public key. By comparing the certificate with the
one sent by the peer we make sure to use the right one.
Fixes#849.
While a hardcoded 1.2 version is fine when we offer that in Client Hello, we
should include the actually offered version if it has been reduced before
starting the exchange.
Tobias Brunner