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.
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.
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 <[email protected]>
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 <[email protected]>
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.
Only the tests with client authentication failed, the client accepted
the trusted self-signed certificate even when it was expired. On the
server the lookup (based on the pre-configured SAN) first found the ECDSA
cert, which it dismissed for the RSA authentication the client used, and
since only the first "pretrusted" cert is considered the following RSA
cert was verified more thoroughly.
The lookup on the client always uses the full DN of the server certificate
not the pre-configured identity so it found the correct certificate on
the first try.
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.
Tobias Brunner