TurboTLS: TLS connection establishment with 1 less round trip

Read original: arXiv:2302.05311 - Published 7/16/2024 by Carlos Aguilar-Melchor, Thomas Bailleux, Jason Goertzen, Adrien Guinet, David Joseph, Douglas Stebila
Total Score

78

🗣️

Sign in to get full access

or

If you already have an account, we'll log you in

Overview

  • Presents a new approach called TurboTLS to establish TLS connections using one less round trip
  • Sends the initial client-to-server and server-to-client flows of the TLS handshake over UDP instead of TCP
  • Simultaneously carries out the three-way TCP handshake in the same flights
  • Completes the final flight of the TLS handshake over the established TCP connection
  • Avoids UDP fragmentation issues using request-based fragmentation
  • Offers substantial latency improvements, especially on reliable connections

Plain English Explanation

The paper introduces a new technique called TurboTLS that can establish TLS connections more efficiently by reducing the number of round trips required. Typically, establishing a secure TLS connection involves a back-and-forth exchange between the client and server over a TCP connection.

In the TurboTLS approach, the initial steps of this TLS handshake are sent over a UDP connection instead of TCP. At the same time, the three-way TCP handshake to set up the underlying connection is also happening. Once the TCP connection is ready, the final step of the TLS handshake can be completed over that TCP link, and then the application data can be sent.

This allows the TLS connection to be established more quickly, effectively eliminating one round trip compared to the traditional approach. To avoid issues with UDP packet fragmentation, the system uses a clever technique where the client sends enough initial UDP requests to give the server enough space to fit its full response in a single packet.

Experiments show that this TurboTLS approach can provide substantial latency improvements, especially on reliable network connections where the round trip time savings are most impactful. Even on less reliable networks, the system has mechanisms to quickly fall back to the standard TCP-based TLS handshake if needed, ensuring adequate performance.

Technical Explanation

The core innovation in this paper is the TurboTLS technique, which modifies the standard TLS handshake process to leverage UDP in addition to TCP.

Traditionally, the TLS handshake occurs over a TCP connection, requiring multiple round trips between the client and server. In the TurboTLS approach, the initial client-to-server and server-to-client flows of the TLS handshake are sent over UDP rather than TCP. Simultaneously, the three-way TCP handshake to establish the underlying connection is also carried out in these same message flights.

Once the TCP connection is established, the client and server can complete the final flight of the TLS handshake over the TCP link and then use that connection for application data transfer. No changes are made to the contents of the TLS handshake protocol itself - only the delivery mechanism is modified.

To address potential issues with UDP packet fragmentation, the authors employ a request-based fragmentation technique. The client sends a series of UDP requests in advance, providing enough space for the server to fit its full response within a single response packet per request packet.

The authors also describe how clients can detect server support for TurboTLS without an additional round trip, by having the server advertise its capabilities in a DNS HTTPS resource record.

Experimental results demonstrate that TurboTLS can provide substantial latency improvements, especially on reliable network connections where the round trip time savings are most impactful. To ensure adequate performance on less reliable connections, the system employs lightweight packet ordering and buffering mechanisms, allowing the client to quickly fall back to the standard TCP-based TLS handshake if needed.

Critical Analysis

The TurboTLS approach presented in this paper offers a novel and promising solution for reducing the latency associated with establishing secure TLS connections. By leveraging UDP in addition to TCP, the authors are able to effectively eliminate one round trip from the standard TLS handshake process.

One key strength of this approach is its compatibility with existing TLS infrastructure - the paper does not require any changes to the TLS protocol itself, only the delivery mechanism. This should make it easier to adopt and deploy TurboTLS in real-world environments.

The authors also demonstrate thoughtful solutions to potential challenges, such as the UDP fragmentation issue. The request-based fragmentation technique seems well-designed to address this problem without adding significant complexity.

That said, the paper does not extensively explore the security implications of using UDP for the initial TLS handshake flows. While the authors note that no changes are made to the TLS protocol, it would be valuable to have a more thorough security analysis to understand any potential vulnerabilities or attack vectors introduced by this approach.

Additionally, the paper focuses primarily on latency improvements, but does not delve deeply into other performance metrics like throughput or CPU/memory usage. Further research could investigate the broader performance characteristics of TurboTLS to fully understand its tradeoffs and limitations.

Overall, the TurboTLS technique presented in this paper represents a promising step forward in optimizing TLS connection establishment. The authors have identified an important problem and developed an innovative solution. However, as with any new approach, ongoing research and real-world deployment will be necessary to fully evaluate its strengths, weaknesses, and long-term viability.

Conclusion

This paper introduces a novel technique called TurboTLS that can establish secure TLS connections using one less round trip than the traditional approach. By sending the initial TLS handshake flows over UDP while simultaneously setting up the underlying TCP connection, TurboTLS is able to reduce the latency of the connection establishment process.

The authors' experimental results demonstrate substantial performance improvements, especially on reliable network connections. The use of request-based fragmentation and other mechanisms to address potential UDP-related issues further bolsters the practicality of this approach.

While the paper does not explore all aspects of TurboTLS's performance and security implications in depth, it presents a compelling and innovative solution to an important problem in network communications. As web protocols continue to evolve and the demand for low-latency, secure connections grows, techniques like TurboTLS may play an increasingly important role in optimizing the underlying infrastructure.



This summary was produced with help from an AI and may contain inaccuracies - check out the links to read the original source documents!

Follow @aimodelsfyi on 𝕏 →

Related Papers

🗣️

Total Score

78

TurboTLS: TLS connection establishment with 1 less round trip

Carlos Aguilar-Melchor, Thomas Bailleux, Jason Goertzen, Adrien Guinet, David Joseph, Douglas Stebila

We show how to establish TLS connections using one less round trip. In our approach, which we call TurboTLS, the initial client-to-server and server-to-client flows of the TLS handshake are sent over UDP rather than TCP. At the same time, in the same flights, the three-way TCP handshake is carried out. Once the TCP connection is established, the client and server can complete the final flight of the TLS handshake over the TCP connection and continue using it for application data. No changes are made to the contents of the TLS handshake protocol, only its delivery mechanism. We avoid problems with UDP fragmentation by using request-based fragmentation, in which the client sends in advance enough UDP requests to provide sufficient room for the server to fit its response with one response packet per request packet. Clients can detect which servers support this without an additional round trip, if the server advertises its support in a DNS HTTPS resource record. Experiments using our software implementation show substantial latency improvements. On reliable connections, we effectively eliminate a round trip without any noticeable cost. To ensure adequate performance on unreliable connections, we use lightweight packet ordering and buffering; we can have a client wait a very small time to receive a potentially lost packet (e.g., a fraction of the RTT observed for the first fragment) before falling back to TCP without any further delay, since the TCP connection was already in the process of being established. This approach offers substantial performance improvements with low complexity, even in heterogeneous network environments with poorly configured middleboxes.

Read more

7/16/2024

🤿

Total Score

0

A Quantum of QUIC: Dissecting Cryptography with Post-Quantum Insights

Marcel Kempf, Nikolas Gauder, Benedikt Jaeger, Johannes Zirngibl, Georg Carle

QUIC is a new network protocol standardized in 2021. It was designed to replace the TCP/TLS stack and is based on UDP. The most current web standard HTTP/3 is specifically designed to use QUIC as transport protocol. QUIC claims to provide secure and fast transport with low-latency connection establishment, flow and congestion control, reliable delivery, and stream multiplexing. To achieve the security goals, QUIC enforces the usage of TLS 1.3. It uses authenticated encryption with additional data (AEAD) algorithms to not only protect the payload but also parts of the header. The handshake relies on asymmetric cryptography, which will be broken with the introduction of powerful quantum computers, making the use of post-quantum cryptography inevitable. This paper presents a detailed evaluation of the impact of cryptography on QUIC performance. The high-performance QUIC implementations LSQUIC, quiche, and MsQuic are evaluated under different aspects. We break symmetric cryptography down to the different security features. To be able to isolate the impact of cryptography, we implemented a NOOP AEAD algorithm which leaves plaintext unaltered. We show that QUIC performance increases by 10 to 20% when removing packet protection. The header protection has negligible impact on performance, especially for AES ciphers. We integrate post-quantum cryptographic algorithms into QUIC, demonstrating its feasibility without major changes to the QUIC libraries by using a TLS library that implements post-quantum algorithms. Kyber, Dilithium, and FALCON are promising candidates for post-quantum secure QUIC, as they have a low impact on the handshake duration. Algorithms like SPHINCS+ with larger key sizes or more complex calculations significantly impact the handshake duration and cause additional issues in our measurements.

Read more

5/16/2024

🚀

Total Score

0

Performance Analysis of Transmission Control Protocol (TCP) Variants

Mansukh Pamarath, Dweep Gogia

There are various TCP variants such as Reno, Tahoe, Vegas, SACK and so on. These variants implement algorithms that handle congestion control. In our experiments we have used these variants to measure their performance such as throughput, delay (latency), and drop rate with respect to time and Constant Bit Rate (CBR) - no congestion control, specified bandwidth and sends packets at a specified rate. We have used the NS2 network simulator to perform all our experiments to analyze TCP performance.

Read more

7/22/2024

Session Types for the Transport Layer: Towards an Implementation of TCP
Total Score

0

Session Types for the Transport Layer: Towards an Implementation of TCP

Samuel Cavoj (University of Glasgow), Ivan Nikitin (University of Glasgow), Colin Perkins (University of Glasgow), Ornela Dardha (University of Glasgow)

Session types are a typing discipline used to formally describe communication-driven applications with the aim of fewer errors and easier debugging later into the life cycle of the software. Protocols at the transport layer such as TCP, UDP, and QUIC underpin most of the communication on the modern Internet and affect billions of end-users. The transport layer has different requirements and constraints compared to the application layer resulting in different requirements for verification. Despite this, to our best knowledge, no work shows the application of session types at the transport layer. In this work, we discuss how multiparty session types (MPST) can be applied to implement the TCP protocol. We develop an MPST-based implementation of a subset of a TCP server in Rust and test its interoperability against the Linux TCP stack. Our results highlight the differences in assumptions between session type theory and the way transport layer protocols are usually implemented. This work is the first step towards bringing session types into the transport layer.

Read more

4/9/2024