wolfSSL, a security company focusing on embedded systems security solutions, has recently announced that TLS 1.3 (Transport Layer Security protocol 1.3) is now supported in the wolfSSL Embedded SSL/TLS Library for servers and clients.
It is one of the first libraries to support the new protocol, with the beta release being available since May. The significance of TLS 1.3 is both in its more robust security, as well as improved speed. The protocol was approved earlier this year in March 2018 by the Internet Engineering Task Force (IETF), an organization that develops and promotes open standards for TCP/IP, which are voluntarily followed by users. The IETF deliberated the details of TLS 1.3 over a two year span, outlined in the Draft 28.
As of August 2018, the protocol has been officially published as TLS 1.3 and is expected to become the default for Internet-based communication.
Image courtesy of wolfSSL.
What Is TLS? What Happened to SSL?
The TLS protocol was first established by IETF in 1999, with the main purpose of preventing the tampering and eavesdropping of communication between clients and servers over a network. Over the years, the way we have communicated over the Internet has changed, along with the sensitivity of the information being communicated. To address known security issues, and adapt to the evolving communication environment, TLS has been updated a few times since its inception: first in 2008, then 2011, and most recently in 2018.
TLS is a little bit of an outlier in communication protocols since it is not officially part of the TCP/IP model, nor the Open Systems Interconnections (OSI) model. These models describe the standards in which computers over a network communicate, so that simply adhering to these standards allows varied systems to work together. TLS operates just above a transport level, or as a transport layer itself.
TLS secures communication between two systems by ensuring three things:
- The connection is secure and private (encrypted)
- The identities of the communicating parties can be authenticated
- The authenticity of the transmissions can be verified to ensure tampering and data loss have not occurred
Before communication between a server and client begins, a handshake must be completed, which is the stage where a shared secret and encryption type is agreed upon. This shared secret and the chosen encryption type is then used to encrypt and decrypt transmissions until the connection closes.
Before TLS, there was Secure Socket Layer (SSL). SSL 1.0 was never released publicly, but SSL 2.0 was released in 1995, and SSL 3.0 in 1996. TLS is built from SSL 3.0.
Just as each release of TLS has addressed security issues, so has been the case with SSL until all SSL protocols were declared as deprecated by the IETF.
It is worth noting that both SSL and TLS are protocols and has no implication on the certificates (certificate of identity and certificate of authority), which can be used for either protocol.
Under the TLS 1.3 Hood
So what makes TLS 1.3 different from TLS 1.2? Two of the most touted features of TLS 1.3 are the enhanced security and improved performance, achieved through a combination of changes.
The first noticeable difference is that the initial handshake between a client and server requires one less round trip before the connection can transmit application data when using server-only authentication. This is achieved through changing the order in which certain messages are sent during the handshake, and when encryption occurs. By re-arranging operations so that independent operations can be performed simultaneously, less time is spent waiting.
TLS 1.2 handshake protocol. Image courtesy of wolfSSL.
TLS 1.3 handshake protocol. Image courtesy of wolfSSL.
For a server and client connecting for the first time, the connection is secured faster due to it’s faster handshake. However, when a server and client are resuming a connection (for example, you visit a website, leave briefly, and then come back), by default TLS 1.3 is not faster than TLS 1.2. However, a 0-RTT mode is supported that allows the resumption to be performed using a Pre-Shared Key,
Cautions are made about 0-RTT mode: it is unable to provide full forward secrecy (past messages cannot be decrypted or replayed), and the 0-RTT message can be replayed. However, on networks with high latency, 0-RTT can significantly speed up transmission times, and could be especially useful for mobile devices.
Encryption, Algorithms, and Ciphers
The options and handling of encryption and cypher suites have also changed. A number of legacy encryption algorithms have been removed from the list of supported algorithms, leaving behind only Authenticated Encryption with Associated Data (AEAD) algorithms. This enhances security, and in some cases, performance as well.
Forwarded secrecy is maintained by the removal of Diffie-Hellman and Static RSA cipher suites, and all messages sent after the Server Hello step are encrypted.
wolfSSL provides a thorough review of TLS 1.3 vs TLS 1.2 performance on their website in a six-part blog series.
The wolfSSL Library
wolfSSL’s support of TLS 1.3 covers quite a few bases.
wolfCrypt encryption supports FIPS 140-2 encryption, which is an encryption standard that is certified by the government and meets NIST (National Institute of Standards and Technology) guidelines. As of this summer, wolfSSL’s library is the only one so far to provide both TLS 1.3 and FIPS 140-2 support together.
The stunnel TLS proxy is also supported, which allows already existing servers and clients to establish two-year connections without having to change the program’s source code. This is useful for securing connections for email exchange, remote shell connections, and web hosting.
Keeping network communications secure is certainly the work of a community, as evident by the work of organizations like IETF, and companies like wolfSSL.