TLS 1.3 Protocol Support

There are many benefits in changing to the newest version of the TLS specification.

One significant difference you will notice is the reduced number of round-trips when performing a full handshake. Older versions of the TLS protocol require two complete round-trips before the client sends the application data. With TLS v1.3 only 1 round-trip is required! Additionally, the server can send application data in response to the clients first handshake message! This means network latency has less impact on the time required to establish a secure connection.

Another difference is the way session resumption works in TLS v1.3. Previous versions of TLS have the client send a session id which the server has to lookup in its cache. If there was a match then they used the same security parameters. This is a very simplistic mechanism that requires sharing of state on servers.

TLS v1.3 has made significant improvements by re-purposing the ticketing system tacked onto older versions of TLS. The server sends the client a new session ticket after the handshake is complete. This ticket, a blob of data to the client, can be a database lookup key like the old session id. Alternatively, it can be a self-encrypted and self-authenticated value that contains the data for the previous connection. This means the server can be stateless!

Finally, the specification has been evaluated by cryptographic experts in efforts to prove the security of the protocol. While no security proof is perfect, the previous attacks on renegotiation, protocol version downgrading, compression, CBC and padding have been mitigated and the protocol is generally more resistant to attack.

TLS 1.3 Performance

If you are interested in learning more about TLS 1.3 performance, check out our recent 6-part blog series on the topic:

Part 1 (TLS 1.3 Performance – Resumption)
Part 2 (TLS 1.3 Performance – Full Handshake)
Part 3 (TLS 1.3 Performance – Pre-Shared Key (PSK))
Part 4 (TLS 1.3 Performance – Server Pre-Generation)
Part 5 (TLS 1.3 Performance – Client-Server Authentication)
Part 6 (TLS 1.3 Performance – Throughput)

Implementation	TLS 1.0 RFC 2246	TLS 1.1 RFC 4346	TLS 1.2 RFC 5246	TLS 1.3 RFC 8446	DTLS 1.0 RFC 4347	DTLS 1.2 RFC 6347
wolfSSL	Yes	Yes	Yes	Yes	Yes	Yes
BoringSSL	Yes	Yes	Yes	Up to draft 23	Yes	Yes
GnuTLS	Yes	Yes	Yes	Up to draft 26	Yes	Yes
MatrixSSL	Yes	Yes	Yes	Yes	Yes	Yes
OpenSSL	Yes	Yes	Yes	Yes	Yes	Yes
rustls	No	No	Yes	Up to draft 22	No	No

This protocol was defined in RFC 8446 in August, 2018. TLS 1.3 contains improved security and speed. The major differences include:

The list of supported symmetric algorithms has been pruned of all legacy algorithms. The remaining algorithms all use Authenticated Encryption with Associated Data (AEAD) algorithms.
A zero-RTT (0-RTT) mode was added, saving a round-trip at connection setup for some application data at the cost of certain security properties.
Static RSA and Diffie-Helman cipher suites have been removed.
All handshake messages after the ServerHello are now encrypted.
Key derivation functions have been re-designed, with the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) being used as a primitive.
The handshake state machine has been restructured to be more consistent and remove superfluous messages.
ECC is now in the base spec and includes new signature algorithms. Point format negotiation has been removed in favor of single point format for each curve.
Compression, custom DHE groups, and DSA have been removed, RSA padding now uses PSS.
TLS 1.2 version negotiation verification mechanism was deprecated in favor of a version list in an extension.
Session resumption with and without server-side state and the PSK-based ciphersuites of earlier versions of TLS have been replaced by a single new PSK exchange.

wolfSSL has two client/server methods, which can be used to specify TLS 1.3 during creation of a wolfSSL context (WOLFSSL_CTX):

WOLFSSL_METHOD *wolfTLSv1_3_server_method(void);
WOLFSSL_METHOD *wolfTLSv1_3_client_method(void);

The wolfSSL example client and server can be used to easily test TLS 1.3 functionality with wolfSSL. For example, to connect the wolfSSL example client and server to each other using TLS 1.3 and the TLS13-AES128-GCM-SHA256 cipher suite, use the “-v” option with “4” to specify TLS 1.3, and the “-l” option to specify the cipher suite:

$ ./examples/server/server -v 4 -l TLS13-AES128-GCM-SHA256
$ ./examples/client/client -v 4 -l TLS13-AES128-GCM-SHA256

Alternatively, the example client can be used to connect to an external server. For example, to connect to the Cloudflare website with TLS 1.3:

$ ./examples/client/client -v 4 -h www.cloudflare.com -p 443 -d

In this command, “-h” specifies the host, “-p” the port, “-g” causes the client to send an HTTP GET request, and “-d” disables the server authentication.

wolfSSL currently supports the following TLS 1.3 cipher suites:

TLS13-AES128-GCM-SHA256
TLS13-AES256-GCM-SHA384
TLS13-CHACHA20-POLY1305-SHA256
TLS13-AES128-CCM-SHA256
TLS13-AES128-CCM-8-SHA256

Advantages to Using TLS 1.3

Various Implementation Support for TLS 1.3

Differences Between TLS 1.2 and TLS 1.3

Compiling wolfSSL with TLS 1.3 Support

Using TLS 1.3 in wolfSSL

Learn More About TLS 1.3

Support