Hacker News Reader

Comment by cperciva | Hacker News Reader

You don't even need (3) if you can do enough trials and have an accurate clock. Compression by its very nature drips timing side channels.

View on HN

Due to the padding of even compressed SSL segments only having timing data will significantly complicate things. You'll be trying to measure the variance in deflate compressing different blocks with single byte differences. You better have an extremely low jitter connection!

> You better have an extremely low jitter connection!

Like AWS. (Cite: http://dl.acm.org/citation.cfm?id=1653687.)

I doubt youd even have to break SSL using that attack. Lots of people do SSL termination at the load balancer.

Okay, but people don't run web browsers on AWS.

except when they do! http://www.amazon.com/gp/help/customer/display.html/?nodeId=...

Doesn't do HTTPS, also I am skeptical of cross-site javascript shenanigans happening on the server-end of silk.

People do run HTTPS clients on AWS, though. Web APIs tend to [1] require exactly that.

[1] Lala people never send sensitive data over plain HTTP I'M NOT HEARING YOU.

Sure, they might use HTTPS, but how often do they load arbitrary pages with uncontrolled javascript?

Pretty much never. How often do they make requests that are at least partially attacker-controlled, though? (Note that variants on https://www.someapi.com/...?username=foo contain attacker-controlled data...)

Low jitter is not a requirement for timing side-channel attacks. As long as the jitter is uncorrelated with the timing difference that you're after, you can filter the signal from the noise.

Reply on news.ycombinator.com