Transport Layer Security (TLS) is an encryption and authentication protocol designed to secure Internet communications. TLS encrypts data sent over the Internet to ensure that cybercriminals will not be able to see private and sensitive information that is transmitted over the internet.
What is a TLS handshake?
The TLS handshake is an essential step in establishing a secure connection between a client and server via TLS (Transport Layer Security). It involves four crucial actions: acknowledging each other, authenticating identities, selecting cryptographic algorithms for encryption, and generating session keys for secure communication. This process is fundamental to the security of HTTPS connections, ensuring data privacy and integrity.
Throughout the TLS handshake process, the client and server collectively undertake the following actions:
- Determine the TLS version (e.g., TLS 1.0, 1.2, 1.3) to be used
- Select the cipher suites to be employed (see below)
- Confirm the server's identity using the server's public key and the digital signature from the SSL certificate authority
- Create session keys for the application of symmetric encryption once the handshake concludes
Depending on the key exchange mechanism chosen (RSA or Diffie-Hellman) and the cipher suites both parties support, the specific steps of the TLS handshake might vary.
PKI: Are You Doing It Wrong?
How a TLS handshake works
During the TLS handshake, the client generally initiates a request to set up a secure link with the website's server. Following this, the server dispatches a public key (protocol) to the user's device, which then verifies this key against a predetermined list of protocols/certificates. Subsequently, the device creates its own key and encrypts it using the server's public key.
The basic steps of a TLS 1.3 handshake are:
- Client hello: The process begins when the client sends a 'client hello' message, detailing the desired protocol version, a client-generated random number, and a selection of cipher suites. This message also outlines the parameters for generating the premaster secret, essentially anticipating the server's preferred method for key exchange, thereby streamlining the handshake duration.
- Server creates the master secret: Upon receiving the client's random value, parameters, and cipher suite preferences, the server is equipped to formulate the master secret.
- Server response and conclusion: The 'server hello' message conveys the server's digital certificate, its digital signature, a server-generated random number, and the selected cipher suite. With the master secret already established, the server proceeds to issue a "Finished" message.
- Completion and client confirmation: The client authenticates the server's signature and certificate, derives the master secret on its own, and dispatches a "Finished" message in response.
- This culminates in the establishment of secure symmetric encryption.
TLS 1.3 handshake process
TLS vs. SSL handshakes
TLS has now replaced SSL as the security protocol for HTTP. As the protocols have evolved, certain differences have become apparent in the ways that SSL and TLS establish connections through the handshake process. In general, TLS (and particularly TLS 1.3) have worked to streamline the handshake process to increase the speed of connections. For example, it would take more time for the SSL handshake to make explicit connections via a port. Whereas TLS attempts to shortcut that process by facilitating implicit connections via protocol.
TLS Session Resumption
An established method for accelerating TLS connections involves a process known as resumption. This occurs when a client, having previously established a connection to the server, leverages its memory of the prior interaction to abbreviate the initial handshake phase.
In the context of TLS 1.2, the server provides the client with either a Session ID or a Session Ticket. The Session ID serves as an identifier that the server uses to recall a specific session, whereas the Session Ticket is a cryptographically secured, serialized session data kept on the client side rather than on the server.
When the client reconnects, it includes this Session ID or Ticket within the ClientHello message. This allows the server to quickly verify the client's identity, bypassing several steps to directly reach the "finished" phase, thereby eliminating the need for an additional exchange. The following illustration from Cloudflare demonstrates the session resumption mechanism in TLS 1.2.
Resumption in TLS 1.3 (0-RTT Resumption)
Within TLS 1.2, a mechanism exists for 1-RTT (one round-trip time) connections for clients that have previously established a connection, a scenario that is quite prevalent. With the advent of TLS 1.3, this process is further streamlined, enabling 0-RTT connections where resumption is utilized, effectively reducing the round-trip time to zero. This means that if you're reconnecting to a server that supports TLS 1.3, it's possible to initiate the transmission of encrypted data, such as an HTTP request, immediately upon connection, without any preliminary exchange, thereby rendering the TLS process virtually without latency.
During the initial connection between a TLS 1.3 client and server, they negotiate a resumption key (also known as a pre-shared key or PSK), and the server issues a Session Ticket to the client. This ticket aids in the client's memory of the session, either through an encrypted version of the PSK to minimize server memory use or via a reference number.
Upon reconnection, the client includes this Session Ticket in its ClientHello message and proceeds to send an encrypted HTTP request using the PSK directly afterward, eliminating the need for a round-trip. The server, recognizing the PSK from the Session Ticket, decrypts the 0-RTT data.
Additionally, the client presents a key share, facilitating the transition to a new, secure key for the forthcoming HTTP response and subsequent communication, ensuring the connection's security is maintained throughout.
What does TLS Handshake Failed mean?
An error message that reads "TLS Handshake Failed" arises when there's an incompatibility during the protocol exchange phase, also known as the "handshake", between a client and a server using Transport Layer Security (TLS) for encryption. This discrepancy arises when the client and server are unable to find a common ground for the same TLS version, they both support. When this mutual understanding fails, the connection cannot be encrypted properly, triggering the "TLS Handshake Failed" error message. Identifying and addressing such protocol mismatches is a critical step towards ensuring secure, encrypted communication.
Diffie-Hellman structure
During the TLS handshake, using different types of asymmetric encryption can introduce minor variations in the procedure. Notably, Diffie-Hellman and RSA achieve identical outcomes through somewhat divergent mechanisms.
The Diffie-Hellman algorithm employs exponential operations to generate a consistent premaster secret. By utilizing the Diffie-Hellman parameters along with the random numbers generated by both client and server, these two entities can collaboratively deduce a mutual, confidential private key. Each party contributes a unique parameter to the operation, leading to distinct calculations by each party, yet yielding matching results.
TLS Handshake Vulnerabilities
A significant concern regarding the handshake process is the volume of data transmitted in plaintext. Clearly, this vulnerability can lead to issues, making it imperative to encrypt as much of the handshake as possible to enhance security.
TLS 1.2 Vulnerabilities
Examining the negotiation phases of the TLS 1.2 handshake, it becomes apparent that these segments were not encrypted. Instead, a simple Message Authentication Code (MAC) was deployed to verify the integrity of the transmitted data, which encompasses:
- The range of cipher suites the client is willing to use, as stated in the Client Hello message.
- The cipher suite chosen by the server, along with the key share, TLS certificate, and digital signature, as announced in the Server Hello message.
This lack of encryption has led to several notable security flaws. Attacks such as FREAK, LogJam, and CurveSwap exploited two critical weaknesses:
- The persistence of obsolete, weak ciphers from the 1990s (known as export ciphers) in many browsers and servers, and
- The negotiation phase for selecting a cipher suite was not protected by a digital signature.
Termed downgrade attacks, these strategies enable "man-in-the-middle" adversaries to coerce communication parties into utilizing the least secure cipher available to both, disregarding the availability of more secure options. In this scenario, the attacker manipulates the cipher suite list communicated from the client to the server to only feature these weak export ciphers. Consequently, the server selects one of these inferior options, and the attacker can then decipher the key through brute force, thus managing to falsify the MACs for the handshake.
Such downgrade attacks pave the way for further vulnerabilities specific to the compromised protocol version, marking them as especially perilous.
Regarding session resumption, investigations have shown that websites could exploit this TLS protocol feature to track users' browsing histories, highlighting another security concern within session management practices.
TLS 1.3 Vulnerabilities
In TLS 1.3, a critical improvement addresses the vulnerability that facilitated downgrade attacks, as the server now authenticates the entire handshake process, including the cipher suite negotiation, with its signature. This effectively blocks the avenue for such attacks.
However, the introduction of 0-RTT in TLS 1.3 is accompanied by specific concerns. A primary issue is that 0-RTT lacks Forward Secrecy in the event of a Session Ticket key compromise. This scenario would allow an attacker to decrypt the initial 0-RTT data transmitted by the client, although the remainder of the connection remains secure. To mitigate this risk, frequent rotation of session keys is recommended. Despite this flaw, TLS 1.3 represents a significant step forward in security, especially when compared to TLS 1.2, which does not fully support Forward Secrecy.
Another significant concern with TLS 1.3's 0-RTT feature is the susceptibility to replay attacks. Given that servers use Session Tickets to remain stateless, they lack the mechanism to verify whether a piece of 0-RTT data has been previously submitted, making it a potential target for such attacks.
If attackers can intercept a 0-RTT packet, then they could resend it multiple times—this is called a replay attack—without the server knowing the request is forged. If that 0-RTT data is not an HTTP GET message but an HTTP POST executing a transaction, then the attacker can escape with many thousands of dollars or euros.
The latest version of TLS won't matter if your certificates expire.
The challenge of expired certificates
Certificates are issued with a validity period that ends on a specified expiration date. Failure to renew a certificate before its expiration can lead to a certificate-related system outage, rendering the certificate unusable for establishing a TLS connection during the handshake process.
Such an unexpected outage and its resultant downtime persist until a new certificate is procured and implemented. Identifying the cause of certificate-related disruptions can be exceptionally challenging without precise knowledge, such as the locations where each certificate is deployed, the details it encompasses, and who has the authorization to manage that system.
The automation of the complete machine identity lifecycle, which includes handling requests for certificates, their issuance, deployment, renewal, and substitution, is crucial. This approach eliminates the likelihood of errors and the demand for labor-intensive manual processes that could jeopardize the integrity of your TLS connections. Automation not only minimizes the possibility of vulnerable TLS handshakes but also enhances various critical security operations within your organization.
Here are some of the benefits of automating your machine identity security:
- Avoid certificate-related outages by eliminating manual errors and automating the entire certificate life cycle to ensure machine identities are renewed before they expire. Information on certificate location and ownership quickly targets renewal requests with automated escalations as needed.
- Prevent breaches by automating the collection of risk intelligence required to quickly identify and respond to machine identity vulnerabilities, weaknesses, or security events. Automated policy-enforcement and life cycle management ensure unused or old keys and certificates are decommissioned.
- Accelerate incident response by automating the identification of impacted keys and certificates as well as the actions needed to remediate large groups of machine identities, so you can dramatically increase the speed of your response to large-scale security events.
- Streamline operations by automating routine administrative tasks to eliminate manual, error-prone processes and reduce the expertise and resources needed to manage the growing number of machine identities.
- Ensure compliance by automating policy enforcement to improve audit readiness, offering automated validation of TLS machine identity security, and generating scheduled or on-demand compliance reports.
Enhancing TLS Machine Identity Security through Automation with Venafi Control Plane
Automating your management and security processes is the most effective way to build and maintain a successful TLS machine identity security program. The Venafi Control Plane for Machine Identities give you observability of machine identities across all environments so that you can verify that all your certificates have the proper attributes and use the most appropriate cipher suites for your business.