Cache Timing Attacks 2.0: Higher Speed, Lower Traces, and Cross-Platform Surveillance

Executive Summary

TL;DR: Researchers have weaponized the standard browser cache into a high-speed surveillance tool. By leveraging HTML5 Web Workers for parallelism and high-resolution timeouts to prevent "cache pollution," they've achieved a 15x performance boost over previous methods. This attack doesn't just see your history; it can de-anonymize your social media profiles, steal real-time search queries from your address bar, and even peek into your Operating System's local file search traces.

Context: Far from being a solved theoretical problem, this work elevates Cache Timing Attacks (CTAs) from a "noisy nuisance" to a viable tool for cyber-espionage against individuals and corporate intranets.

The "Pollution" Problem: Why Previous Attacks Failed

The core intuition of a CTA is simple: measuring how long a browser takes to load a resource.

• Fast load (<5ms): Resource was in the cache (user visited it before).
• Slow load (>50ms): Resource was fetched from the network (user hasn't visited it).

However, previous attacks suffered from Cache Contamination. To check if an image was in the cache, the attacker had to request it. This request would then put the image in the cache. You could only probe a URL once; subsequent tests would always return a "hit," destroying the ability to perform iterative or brute-force searches (like guessing a search query letter-by-letter).

Methodology: Speed and Stealth

The authors introduced two breakthrough improvements to turn the browser into a high-speed scanner:

1. Web Workers for Massive Parallelism

By using Web Workers, the attack can run multiple background threads. This allows for probing at rates of 300 requests per second. This is critical for brute-forcing search queries or de-anonymizing users against a large set of candidate profile pictures.

2. The Timeout Trick (Anti-Pollution)

This is the "secret sauce." The attack uses XMLHttpRequest with an extremely short timeout (e.g., 5ms for browser cache).

• If the resource is cached, the browser provides it almost instantly—before the timeout triggers.
• If it's not cached, the network fetch takes longer than 5ms, the timeout triggers, and the request is aborted before the data is written to the cache.

This keeps the "crime scene" clean, allowing the attacker to probe the same state repeatedly without altering it.

Fig 1: The shared nature of caches across Browser, OS, and Proxy layers.

High-Stakes Case Studies

Case A: Breaking RSA Anti-Phishing

Many banks use "Site-to-User" images. You pick an image, and the bank shows it to you at login so you know it's the real site. The authors proved they could probe the entire bank's image gallery against your cache to find your specific image, then display it on a phishing site to gain your trust.

Case B: Real-time Search Sniffing

Modern "Omniboxes" (address bars) send AJAX requests for every character you type to provide suggestions. These JSON/XML responses are often cached. The authors successfully leaked search queries by probing these suggestion URLs.

Fig 2: Performance gap between the proposed method and the previous SOTA (CoreDump).

The Hidden Danger: OS and Proxy Caches

Perhaps the most alarming discovery is that the attack extends beyond the browser:

• Windows SmartSearch: On Windows 8.1, even local desktop searches for files trigger web-based suggestion calls that are stored in a global system cache (INET cache). A malicious website can probe your OS-level search history.
• Corporate Proxies: In many companies, users share a network proxy. A malicious site visited by Employee A can probe the proxy cache to see what sensitive internal URLs Employee B has been visiting.

Critical Analysis & Conclusion

The Verdict: This paper exposes a fundamental architectural flaw in how we handle web state. We have historically treated "same-origin policy" as a gate for data content, but we ignored the timing metadata of the hardware/software container.

Limitations: The timeout values (5ms vs 15ms) are sensitive to the victim's hardware and network latency. A "one-size-fits-all" script might fail without a calibration phase.

Future Outlook: Standard defenses like HTTPS and "Private Browsing" fail here because they still utilize the shared cache for performance. The only structural solution is Cache Segmentation: the address bar, the OS search, and different web domains must never share the same physical cache bucket. Until then, adding unique nonces to sensitive URLs is the most practical bandage for developers.