Loads of changes that are tightly connected... :/
* Change lambdas to static functions
* Add spec docs to those functions
* Keep the current scope around as a parameter
* Add wrapping classes for some Certificate members
* Parse ec and ecdsa data from certificates
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
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.
Apologies for the enormous commit, but I don't see a way to split this
up nicely. In the vast majority of cases it's a simple change. A few
extra places can use TRY instead of manual error checking though. :^)
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 :^)
