Time and Time Again: Leveraging TCP Timestamps to Improve Remote Timing Attacks

Time and Time Again: Leveraging TCP Timestamps to Improve Remote Timing Attacks

Speakers: Vik Vanderlinden

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=EtzxxNOKJcE

Overview

Remote timing attacks are limited by network jitter, which adds noise to roundtrip time measurements and requires many observations to distinguish timing differences. This talk demonstrates that TCP timestamps -- an optional TCP feature enabled on 88% of internet hosts -- can be leveraged to dramatically improve remote timing attack precision. By measuring the difference between server-side TCP timestamps on immediate acknowledgments versus responses, the attacker obtains server-side processing time measurements that are completely independent of network jitter.

The technique improves accuracy from 25 microseconds (roundtrip time) to 5 microseconds with millisecond timestamps, and down to 750 nanoseconds with the microsecond timestamps available in newer Linux kernels. A runtime multiplication enhancement coalesces up to 1,000 HTTP requests in a single connection to amplify timing differences. The attack is distributable across geographically distant clients, potentially circumventing rate limiting. Case studies include the first known transatlantic Lucky 13 exploit against TLS (using microsecond timestamps) and user enumeration against SSH and FTP.

Background

▶ Watch: Background: timing attacks and network jitter limitations (0:00)

Timing attacks exploit the fact that programs processing different secret values may take different amounts of time. In remote timing attacks, the attacker measures server processing time over the network, but network jitter (delay variation across routers and middleboxes) adds significant noise. Prior work improved remote timing using HTTP headers (Date, Server-Timing) and Timeless Timing Attacks (TTA), which coalesce two requests to compare processing order rather than absolute timing.

TCP timestamps are a TCP option designed to improve roundtrip time measurements for congestion control. When enabled, each TCP segment carries a Timestamp Value (TSval) and Timestamp Echo Reply (TSecr). Implementations started with randomized initial values (to prevent uptime measurement) but maintain consistent incrementing granularity -- typically milliseconds. Newer Linux kernels (Ubuntu 24.10+) support microsecond-granularity timestamps configurable via ip route.

The critical observation: when a server immediately acknowledges receipt of a request (before processing), then later sends the response, the TCP timestamps on these two segments reflect the server's processing time with zero network jitter contribution.

Key Findings

▶ Watch: Microsecond timestamps in newer Linux kernels (4:00)

• 88% of internet hosts have TCP timestamps enabled (measured across 500,000+ hosts)
• 99% of timestamp-enabled hosts send immediate acknowledgments, enabling the basic attack
• 95% support persistent connections, enabling the runtime multiplication enhancement
• 5 microsecond accuracy with millisecond timestamps (5x improvement over 25-microsecond RTT baseline)
• 750 nanosecond accuracy with microsecond timestamps (33x improvement over RTT baseline)
• 5-50x reduction in required requests to achieve the same accuracy as roundtrip timing
• Distributable: Three geographically distant clients produce near-identical results, enabling rate limiting circumvention
• First transatlantic Lucky 13 exploit: Against the ELLL library using microsecond timestamps (responsibly disclosed)
• User enumeration successfully reproduced against SSH and FTP, including under server load

Technical Deep Dive

▶ Watch: Results: 5x to 33x accuracy improvement over roundtrip timing (8:00)

Basic Attack Mechanism: The attacker establishes a TCP connection, sends a request, and observes two server responses: (1) an immediate ACK confirming receipt, and (2) the actual response after processing. Both carry TCP timestamps. The difference between these timestamps equals the server-side processing time, independent of network path delay.

Runtime Multiplication Enhancement: Using HTTP/1.1 persistent connections, the attacker coalesces up to 1,000 requests (the Nginx connection limit) in a single TCP connection. The server processes them sequentially, and each response carries a timestamp. The difference between the last and first timestamps represents the cumulative processing time for all requests. If each request has a timing difference of D microseconds, N requests amplify this to N*D microseconds, making even tiny differences measurable.

Request Coalescing Methods:

• TCP segment filling: Pack requests into maximum-segment-size TCP segments (~1,460 bytes)
• TLS frame filling: Fill a 16KB TLS frame (10x more space)
• Receive buffer filling: Send out-of-order segments to fill the ~6MB receive buffer on a default AWS instance, then send the first segment to trigger sequential processing

Distribution: Because the timing information comes from server-side timestamps (independent of network path), multiple clients at different geographic locations can independently collect measurements and combine datasets. This circumvents per-IP rate limiting.

Lucky 13 Exploitation: Lucky 13 is a timing side-channel in CBC-mode TLS where padding validation takes different time for different padding lengths. The transatlantic exploit (client in one location, server on another continent) used microsecond timestamps to measure the padding oracle remotely -- the first known demonstration of Lucky 13 across such distances.

Demo / Proof of Concept

▶ Watch: First transatlantic Lucky 13 exploit against TLS (10:00)

Extensive testing on controlled servers demonstrated the 5x-33x accuracy improvement. Real-world applicability was validated through three case studies:

1. Lucky 13 (TLS): Transatlantic exploitation against the ELLL library using microsecond timestamps. Responsibly disclosed to the library maintainers (no response received).
2. SSH user enumeration: Successfully distinguishing valid from invalid usernames based on authentication processing time differences.
3. FTP user enumeration: Demonstrated even under server load conditions, showing the attack is robust to competing workloads.

The distribution experiment used three geographically distant AWS clients, confirming that combining datasets produces near-identical results to single-client measurements at 50-microsecond timing differences.

Defensive Implications

▶ Watch: Defenses: disabling timestamps, obfuscation, and middlebox concerns (12:00)

• Disable TCP timestamps: The most effective defense, but loses performance optimizations (congestion control improvements, PAWS). Enabled by default on Ubuntu Server.
• Send timestamps less frequently: Not sending timestamps on every segment slightly hinders the attacker but doesn't fully prevent the attack.
• Obfuscated timestamps: Replace actual timestamp values with opaque identifiers, maintaining a server-side mapping. This would completely disable the attack but requires kernel support and may break middlebox functionality.
• Microsecond timestamps risk: The recent addition of microsecond-granularity TCP timestamps in newer Linux kernels (Ubuntu 24.10+) dramatically increases the attack's precision, making previously unexploitable timing differences exploitable.
• All TCP-based protocols are potentially vulnerable: Any protocol running over TCP with timestamps enabled is susceptible, including HTTPS, SSH, FTP, database protocols, and any custom TCP services.

Key Takeaways

• TCP timestamps (enabled on 88% of internet hosts) leak server-side processing times independent of network jitter
• 5x accuracy improvement with millisecond timestamps, 33x with microsecond timestamps, compared to roundtrip timing
• Runtime multiplication coalesces up to 1,000 HTTP requests to amplify timing differences
• The attack is distributable across geographic locations, circumventing rate limiting
• First transatlantic Lucky 13 exploit demonstrates practical impact against TLS
• Microsecond TCP timestamps in newer Linux kernels (Ubuntu 24.10+) significantly increase risk
• Obfuscated timestamps are proposed as a complete defense but require kernel support

About the Speaker(s)

Vik Vanderlinden (Vic) delivered a clear, well-structured presentation with confident handling of technical questions about middlebox implications and defense deployability. The research is planned for open-source release on the university's GitLab. The work was built using TCPdump for packet capture and analysis.