The `build_rsa_pre_master_secret` function originally called
`verify_chain_and_get_matching_certificate`, which verified the chain
and returned a certificate matching the specified hostname.
Since the first certificate in the chain should always be the one
matching with the hostname, we can simply use that one instead. This
means we can completely remove this method and just use `verify_chain`.
To make sure the hostname is still verified, `verify_chain` now also
checks that the first certificate in the chain matches the specified
hostname. If the hostname is empty, we currently fail the verification,
however this basically never happen, as the server name indication
extension is always used.
With this change the certificate chain sent by the server will actually
be verified, instead of just checking the names of the certificates.
To determine if a certificate is signed by a root certificate, the list
of root certificates is now a HashMap mapping from the unique identifier
string to the certificate. This allows us to take the issuer of a
certificate and easily check if it is a root certificate. If a
certificate is not signed by a root certificate, we will check that it
is signed by the next certificate in the chain.
This also removes the ad-hoc checking of certificate validity from
multiple places, and moves all checking to the verify_chain.
A mistake I've repeatedly made is along these lines:
```c++
auto nread = TRY(source_file->read(buffer));
TRY(destination_file->write(buffer));
```
It's a little clunky to have to create a Bytes or StringView from the
buffer's data pointer and the nread, and easy to forget and just use
the buffer. So, this patch changes the read() function to return a
Bytes of the data that were just read.
The other read_foo() methods will be modified in the same way in
subsequent commits.
Fixes#13687
When the server doesn't signal the Content-Length or use a chunked mode,
it may just terminate the connection after sending the data.
The TLS sockets would then get stuck in a state with no data to read and
not reach the disconnected state, making some requests hang.
We know double check the EOF status of HTTP jobs after reading the
payload to resolve requests properly and also mark the TLS sockets as
EOF after processing all the data and the underlying TCP socket reaches
EOF.
Fixes#12866.
Add the required methods to SECP256r1 to conform to the EllipticCurve
virtual base class. Using this updated version of SECP256r1, support in
LibTLS is implemented.
These changes generalize the interface with an elliptic curve
implementation. This allows LibTLS to support elliptic curves generally
without needing the specifics of elliptic curve implementations.
This should allow for easier addition of other elliptic curves.
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).
