It has been 4 years since the TLS v1.3 specification came out with Draft 1 and it looks like it has been finalized! With the release of Draft 24 the last of the WG comments have been addressed. Now the IESG will review the document and it is expected that it will soon be ratified as an RFC.
wolfSSL has updated its TLS v1.3 code to include support for Draft 22 and 23. Draft 24 is not significantly different and with the highly anticipated release of the RFC, we are looking forward to finalizing the TLS v1.3 code.
The last time we discussed TLS v1.3 the specification was at Draft 21. Since then a number of changes have been made to deal with middlebox incompatibilities.
Middleboxes are devices that sit between the client and the server that typically inspect, filter or act as a proxy. They are a necessary part of the Internet ecosystem. Inspection middleboxes are used to monitor network traffic and to collect statistics. Filters attempt to detect and remove undesirable network traffic that is malformed or malicious. Proxy-servers are used to terminate TLS connections to better manage the network traffic and spread load.
Middleboxes include embedded devices that are updated by changes to the firmware. Therefore updates are seldom made and the TLS v1.3 specification had to be modified to work with the deployed systems.
Mozilla performed a customer test with their browser connecting to a controlled website supporting Draft 18. The results (https://www.ietf.org/mail-archive/web/tls/current/msg25091.html) were that TLS v1.3 Draft 18 failed 2.91% of the time compared to TLS v1.2 failure rate of 1.58%. This was statistically significant. After some compatibility changes the failure rate fell to 1.63%. It was clear the changes were needed.
The changes required include:
- Changing the ServerHello version and record layer version post ServerHello to 0x0303
- Restoring missing fields from the ServerHello message.
- Merging the HelloRetryRequest into the ServerHello message.
- Ignoring ChangeCipherSpec messages in handshake.
It was first assumed that middleboxes would inspect ClientHello messages and pretty much ignore the responses like ServerHello and HelloRetryRequest messages. This didn’t work out in the real world. Therefore some of the ServerHello changes from TLS v1.2 had to be undone. All required changes are now available in wolfSSL.
Further optional compatibility changes are specified. This includes sending a ChangeCipherSpec before any encrypted data, thus the previous requirement to ignore these messages. wolfSSL has the ability to enable these with the use of the define: WOLFSSL_TLS13_MIDDLEBOX_COMPAT.
A more extensive test was performed by Mozilla after Draft 22 was released. The results (https://www.ietf.org/mail-archive/web/tls/current/msg25179.html) were:
- TLS v1.2 failure rate: 4.85% (3.25% US only)
- TLS v1.3 Draft 22: 5.02% (3.45% US only)
- TLS v1.3 Draft 22 Compat: 4.81% (3.24% US Only)
It is clear that the Draft 22 changes are working.
Draft 23 renumbered the KeyShare extension to allow for compatibility with CANON printers that were based on BSAFE and added a separate extension for negotiating certificate signatures.
wolfSSL by default supports Draft 23 but can be configured to support Draft 22 with: –enable-tls13-draft22. Also, for backwards compatibility for early adopters, Draft 18 support can be configured with: –enable-tls13-draft18.
If you have any questions or issues with wolfSSL’s TLS 1.3 implementation, please email us at facts@wolfssl.com, or our support team at support@wolfssl.com.