TLS 1.3

[krizhanovsky]

TLS 1.3 is defined in RFC 8446 and partially implemented in our donor, mbedTLS. Current Tempesta TLS moves far from mbedTLS, so a new features from mbedTLS can not be ported as is.

The task requires some of the items from #1335 for the cypro math, but in this task we can start just with borrowing some code from mbed TLS and leave performance optimizations for #1335.

At least following functionality must be implemented in the first pull request. Probably it makes sense to make a separate pull request for each of the points.

• The new handshakes FSM. 0-RTT (also see TLS sessions resumption #1054 for TLS 1.2 tickets) is just an extension/optimization of the basic full handshake. TLS 1.3 removes PSK cipher suites and replaces them by a new PSK mode used for 0-RTT, so the commit a1ca985 which removed PSK is fine. It seems mbedtls_ssl_psk_derive_premaster() must be completely different as well as format of the PSK extension in key exchange record. Anyway, we still don't need out-of-band distributed keys - the main part of the removed code. It seems none of a real clients, like browswers, actually support 0rtt due to it's security issues - please check this for Chrome and Firefox and move this to a separate issue.
• Hash Key Derivation Function is required and can be borrowed from mbedTLS (the link references Apache licensed code, only GPLed code can be used)
• Encrypted SNI is important, already frequently used, feature. ESNI is a separate standard, not a part of RFC 8446. Also it's still in draft state. Probably it's better to leave the feature until we get a request for it.)
• RFC 8470 "Using Early Data in HTTP" must be implemented
• Adjust JA5t computation with the TLS 1.3 version (TTLS_MINOR_VERSION_4), see JA5 fingerpringing computation and filtration #2052

The implementation must consider QUIC #724 requirements (RFC 9001) and develop necessary TLS 1.3 routines for it. Basically QUIC isn't a layered protocol, so it requires specific TLS 1.3 interfaces. See picotls and its usage in quant for an example of QUIC/TLS1.3 interoperability.

According to RFC 8740 we must not support post-handshake CertificateRequest messages, but must implement key updates and NewSessionTicket messages.

Move Tempesta TLS to 0.4.0 version on implementing the extension.

Related project for the Linux kernel TLS 1.3 handshakes https://github.com/lxin/tls_hs/

Testing

As part of the issue (during the debugging) please develop functional tests tls/ for TLS 1.3 like #737 . Note that the current scapy-ssl_tls implementation of TLS 1.3 is outdated, so the native Sapy TLS layer must be used.

• The GnuTLS vulnerability scenario
• The handshake deadlock scenario: TCP write windows/buffers don't allow a client to fully write a request and server to write NewSessionTicket.
• Different SNI and ESNI values can work for domain hiding

[krizhanovsky]

An implementation should (not must, https://tools.ietf.org/html/rfc8446#section-9.1) implement ChaCha20 and the algorithm is slow (the only reason for it is that its pure software implementation is faster than AESs):

$ openssl speed -elapsed -evp chacha20
....
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
chacha20        274069.48k   519363.26k  1022813.35k  2116939.78k  2215616.51k  2121307.48k

$ openssl speed -elapsed -evp aes-128-gcm
...
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-gcm     377061.18k   936625.90k  1908564.48k  3045661.35k  3836799.66k  3876809.39k

$ openssl speed -elapsed -evp aes-256-gcm
...
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-256-gcm     326535.54k   833587.56k  1561193.39k  2327310.68k  2718223.02k  2836157.78k