Full TLS proxying

[krizhanovsky]

Protocol

Currently Tempesta can only terminate TLS traffic acting as a TLS accelerator/terminator. However, CDNs and filtering networks do require full TLS, i.e. establish encrypted channel between Tempesta and origin servers. Thousands upstream servers are possible in application delivery network (ADN) scenarios, so connect() over TLS must be fast enough.

Only TLS 1.3 #1031 should be supported.

Following features must be supported:

1. Hostname name validation (see the OpenSSL wiki). We don't want to make DNS queries from the kernel, so the server (upstream) address must also specify the common name of the server (i.e. result of inet_pton()). Alternatively we can use linux/net/dns_resolver.
2. abbreviated handshakes

Cryptography

TLS client side involves ECDSA signature verification, i.e. calculation of m * G + n * Q, which is done by ttls_ecp_muladd() in simplest way. The Shamir's trick and/or multi-exponentiation (Bodo Möller, "Algorithms for multi-exponentiation") should be used. See OpenSSL's ec_wNAF_mul() as the reference.

[krizhanovsky]

It seems 50% of CDN clients require TLS encrypted traffic. Since backends are client-manageable, TLS 1.3 only is enough for client side. Backends are also trusted, so it seems we don't need to do full certificates chain validation and/or can use pre-shared keys. Thus, it seems we don't need neither OCSP stapling #831 nor clients certificates validation #830 for this task,