This will verify that the signature of the ephemeral key used in the
DHE and ECDHE key exchanges is actually generated by the server.
This verification is done using the first certificate provided by the
server, however the validity of this certificate is not checked here.
Instead this code expects the validity to be checked earlier by
`TLSv12::handle_certificate`.
This adds support for the Elliptic Curve Diffie-Hellman Ephemeral key
exchange, using the X25519 elliptic curve. This means that the
ECDHE_RSA_WITH_AES_128_GCM_SHA256 and ECDHE_RSA_WITH_AES_256_GCM_SHA384
cipher suites are now supported.
Currently, only the X25519 elliptic curve is supported in combination
with the uncompressed elliptic curve point format. However, since the
X25519 is the recommended curve, basically every server supports this.
Furthermore, the uncompressed point format is required by the TLS
specification, which means any server with EC support will support the
uncompressed format.
Like the implementation of the normal Diffie-Hellman Ephemeral key
exchange, this implementation does not currently validate the signature
of the public key sent by the server.
This commit converts TLS::TLSv12 to a Core::Stream object, and in the
process allows TLS to now wrap other Core::Stream::Socket objects.
As a large part of LibHTTP and LibGemini depend on LibTLS's interface,
this also converts those to support Core::Stream, which leads to a
simplification of LibHTTP (as there's no need to care about the
underlying socket type anymore).
Note that RequestServer now controls the TLS socket options, which is a
better place anyway, as RS is the first receiver of the user-requested
options (though this is currently not particularly useful).
The callback should be called as soon as the connection is established,
and if we actually set the callback when it already is, we expect it to
be called immediately.
This adds two methods, handle_dhe_rsa_server_key_exchange and
build_dhe_rsa_pre_master_secret, to TLSv12 and a struct,
server_diffie_hellman_params, to Context, which are used to implement
the DHE_RSA key exchange algorithm. This grants us the benefits of
forward secrecy and access to sites which support DHE_RSA.
It is worth noting that the signature of the server provided
Diffie-Hellman parameters is not currently validated. This will need to
be addressed to prevent man-in-the-middle attacks.
The old enumeration didn't allow discriminating the key exchange
algorithms used, but only allowed the handshake with the server. With
this new enumeration, we can know which key exchange algorithm we are
actually supposed to use :^)
Also sort the existing cipher suites, and remove the unsupported ones.
We don't support any of these recommended ciphers, but at least we now
know which ones we should focus on :^)
Instead of sprinkling the definition of the ciper suites all over the
TLS implementation, let's regroup it all once and for all in a single
place, and then add our new implementations there.
At some point since Sep 2018, OpenSSL added a ~~bug~~ feature that makes
the default set of signature algorithms defined in TLSv1.2 unusable
without reducing what they call the "security level", which caused
communication with servers using more recent versions of openssl to
fail with "internal error".
This commit makes LibTLS always send its supported sigalgs, making the
server not default to the insecure defaults, and thus enabling us to
talk to such servers.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
According to RFC6066, empty extension_data for an SNI extension is
absolutely one of the possibilities - so let's support this instead of
spamming the debug log.
The user may now request specific cipher suites, the use of SNI, and
whether we should validate certificates (not that we're doing a good job
of that).
