Spirent has been
leading the way in providing companies with the tools they need to prepare for
TLS v1.3. I had a chance to sit down with David DeSanto, Director, Products and
Threat Research for Spirent to talk about the transition to TLS v1.3 and some
of the hurdles that organizations face as they make the switch to the new de
facto standard.
Jim Carroll, OND: Tell me about the evolution of TLS. How did we get to this point?
David DeSanto, Spirent: Transport Layer Security, or TLS, is a cryptographic protocol used by many applications and services such as web browsing, email communications, and multimedia communications. It made Secure Sockets Layer, or SSL, obsolete as it offered better encryption properties such as perfect forward secrecy (PFS), newer cipher suites, etc.
TLS v1.2 is a considered the current de facto standard for cryptography when paired with a strong cipher suite and large private key (i.e., asymmetric key). However, this comes at an impact to the user’s experience, as the protocol itself and the cipher suites offering elliptic curve with PFS and large asymmetric keys come at a performance hit. Even in today’s world of data breach roulette, organizations choose to go with a lower encryption standard or cipher suite such that cryptographic steps do not overburden the user and potentially have them stop using their services altogether.
TLS v1.3 looks to address the concerns commonly seen with TLS v1.2. This new standard includes performance improvements such that the user does not have as much overhead or burden in initializing the secure connection. It also makes additional insecure cryptographic practices obsolete, which can lead to attackers improperly gaining access to the encrypted communication.
Jim Carroll, OND: What's the current status of TLS v1.3 and what is the next phase of specification development?
David DeSanto: TLS v1.3 is still in draft—specifically draft-28—and this draft has been submitted as the official standard. This was submitted in March to the IETC and is going through the IETF process to be a ratified standard. It is expected to be ratified this year, and you can track its progress at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/.
Jim Carroll, OND: What is the market reaction so far? Are customers implementing TLS v1.3 in big numbers?
David DeSanto: The market adoption has varied depending on the specific technology and vertical.
As TLS v1.3 is a cryptographic protocol used by a client and server to provide privacy and data integrity, users can be put into a “forced adoption” model without realizing it. The best example of this is with one of the bigger champions of TLS v1.3: Google. Google rolled out TLS v1.3 earlier this year within its services and consumer solutions. If you have a Gmail account and access it using the Chrome browser, you are using TLS v1.3 and may not even know it.
There is a parallel effort—started by development at Google in 2016—to build a new transport layer protocol named QUIC (short for Quick UDP Internet Connections). It was first submitted to the IETF in 2016 and is currently still in draft with draft-12 being the current working draft. QUIC has encryption requirements built right into its standard and these requirements are based on TLS v1.3.
You can track the status of QUIC at https://datatracker.ietf.org/doc/draft-hamilton-quic-transport-protocol/.
Just these two examples show strong adoption of TLS v1.3 so far and it is expected to grow at a consistent rate. TLS v1.3 is expected to be adopted at a much faster rate than previous iterations of the TLS protocol—due in large part to the providers we rely on today who are actively making the switch to support it quickly. Google is joined by many others who have already implemented and have enabled support by default.
Jim Carroll, OND: What technical hurdles are there to implementing TLS v1.3?
David DeSanto: There are three crucial considerations that organizations need to keep in mind as they prepare to migrate to TLS v1.3. Every organization should be thinking about three crucial considerations:
1. How to handle zero round trip time resumption (0-RTT)
2. Preparing for downgrades to TLS v1.2
3. The need for infrastructure and application testing
The 0-RTT option has the potential to significantly increase performance during an encrypted session between endpoints. With TLS v1.2, secure web communications requires two round trips between the client and server prior to the client making an HTTP request and the server generating a response. TLS v1.3 reduces this requirement to one round trip and offers the ability to inherit trust to accomplish zero round trips, or 0-RTT. 0-RTT potentially provides better performance, but it also creates a significant security risk. With 0-RTT, a transaction could be easy prey for a replay attack, in which a threat actor can intercept an encrypted client message and resend it to the server, tricking the server into improperly extending trust to the threat actor and thus potentially granting the threat actor access to sensitive data. Organizations should be wary of allowing or using 0-RTT due to the potential security risks. Unless your application or service is highly latency sensitive, the new option is simply not worth the security risk.
Another concern is that TLS v1.3 is backward compatible to TLS v1.2 to allow for interoperability with legacy clients and servers during the transition to the new standard. It’s important to configure the security settings to ensure fallback to TLS v1.2 uses higher security standards. Organizations should disable lower cryptographic algorithms to prevent security breaches such as man-in-the-middle attacks. Select strong cipher suites, including ones that leverage elliptic curve key exchange, use large asymmetric keys, and implement PFS.
Testing is also crucial. The change to TLS v1.3 may be disruptive, and it’s important to discover and address issues proactively. Businesses should test for interoperability, security, and performance in a combined, holistic manner. Use a realistic load, generating, inspecting, and processing appropriate levels of encrypted traffic. Validate how internal and external users will interact with your systems and consider what this change in encryption may mean for an employee, customer, partner, or any other relevant stakeholder. You also have to test all clients—including mobile devices and tablets, and the entire network infrastructure, such as identity and access management systems, firewalls, web proxies, etc.
<Jim Carroll, OND: How can Spirent help with the transition to TLS v1.3?
David DeSanto: Spirent added functional security testing for TLS v1.3 to its industry-leading CyberFlood product line in July of 2017 when adding TLS v1.3 support to its Advanced Fuzzing solution. This allowed protocol developers, QA teams, and security researchers to confirm the stability and reliability of the TLS v1.3 implementations they have built or are validating. This includes hunting for software defects within the implementation, which could lead to software vulnerabilities.
We entered the market one year ago and extended our TLS v1.3 support in February of this year when we added performance security testing for TLS v1.3 to our CyberFlood product line. Spirent’s goal is to provide thought leadership and be a partner to allow customers to launch new solutions with confidence in network functionality, performance, and security at scale. Others are now following our lead in providing solutions to help enterprises validate their security posture.
