Advantages to Using TLS 1.3
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)
Various Implementation Support for TLS 1.3
|BoringSSL||Yes||Yes||Yes||Up to draft 23||Yes||Yes|
|GnuTLS||Yes||Yes||Yes||Up to draft 26||Yes||Yes|
|rustls||No||No||Yes||Up to draft 22||No||No|
Differences Between TLS 1.2 and TLS 1.3
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.
Compiling wolfSSL with TLS 1.3 Support
To compile wolfSSL with TLS 1.3 support, use the “--enable-tls13” ./configure option:
$ unzip wolfssl-X.X.X.zip
$ cd wolfssl-X.X.X
$ ./configure --enable-tls13
Using TLS 1.3 in wolfSSL
wolfSSL has two client/server methods, which can be used to specify TLS 1.3 during creation of a wolfSSL context (WOLFSSL_CTX):
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:
Learn More About TLS 1.3
Learn more about TLS 1.3 from the RFC. The most recent version can be found here:
Or, browse some of our recent blog posts on TLS 1.3:
Please direct any questions about using wolfSSL with TLS 1.3, or about our current TLS 1.3 support to firstname.lastname@example.org. We also appreciate any comments or feedback. Thanks!