5 ms·

Can an expert comment on side-channel attacks on HTTPS and whether they're less viable on HTTP/2? My assumption is that because wikipedia has a known plaintext

Can an expert comment on side-channel attacks on HTTPS and whether they're less viable on HTTP/2? My assumption is that because wikipedia has a known plaintext and a known link graph it's plausible to identify pages with some accuracy and either block them or monitor who's reading what. I also assume that the traffic profile of editing looks different from viewing.

cyphar 9y ago
And one thing to note is that people generally don't randomly pad the length of articles, so it's not _very_ difficult to figure out what articles you might be reading -- even over TLS.
- colmmacc 9y ago
  Random padding wouldn't really help; an active attacker can force retries, so the random distribution can be mapped (and then subtracted). To defeat TA you need to pad to a fixed length for all cases, or for a very large amount of cases. E.g. if every wikipedia page, plus all of the content it includes, came to exactly 10K, 20K, 30K, ... in size, then you could obscure what the user is reading.
- giobox 9y ago
  I've seen the theory that you could work out which pages are loaded from wikipedia over SSL by looking at other metrics like content length etc, but thanks to stuff like gzip compression, caching headers etc, this is much harder to exploit in practice. Plus there's the huge overhead of maintaining a database to link the frequently changing metrics back to the appropriate page on wikipedia. There's a great link somewhere (which of course I now can't find) where somebody prototyped this idea and found it really pretty hard to implement. In the event this was even tried, it would presumably be trivial to defeat with injection of random content somewhere in the server responses anyway. This of course all assumes we can trust the root certificate authority though :P
  - cyphar 9y ago
    Yeah, good point. I presumed it would be a pain, but I never thought to see if someone actually tried it. Though you shouldn't be compressing things over TLS. I think the only proper solution is to pad out all articles (and images) to the nearest 2kB or something so that you can't figure out the length (randomness can be thwarted by forcing refreshes).
chimeracoder 9y ago
> My assumption is that because wikipedia has a known plaintext and a known link graph it's plausible to identify pages with some accuracy At least in theory, the latest versions of TLS should not be vulnerable to a known plaintext attack. TLS also is capable of length-padding, which would reduce the attack surface here as well for an eavesdropper. My understanding is that HTTP/2 makes it even more difficult to construct an attack on this basis, because HTTP/2 means multiple requests can get rolled into one. Of course, all this is assuming an eavesdropper without the ability to intercept and modify traffic. In practice, governments will probably just MITM the connection - we have precedent for governments abusing CAs like this in the past - and unless Wikipedia uses HPKP and we trust the initial connection and we trust that the HPKP reporting endpoint isn't blocked, then it's still possible to censor pages, without anybody else knowing[0]. [0] ie, the government censors will know, and the person who attempted to access the page will know, but neither Wikipedia nor the browser vendor would be able to detect the censorship automatically.
- colmmacc 9y ago
  TLS1.2 doesn't have an effective padding scheme, and with most sites (including Wikipedia) moving to AES-GCM and ChaCha20, it is actually less effective than the primitive CBC padding, which provided some protection. TLS1.3, which is still a draft, does have support for record-level padding, but I haven't seen any of the experimental deployments using it. HTTP/2 does have support for padding, but again, it's not common to see it being used, at least not in the kind of sizes it would take to obscure content fingerprints. Wikipedia is a particularly hard case for traffic analysis fingerprinting. First, the combination of page size and image sizes are just highly unique, even modulo large block/padding sizes. But more importantly, anyone can edit a wikipedia page, so if the size of a target page isn't unique, it's very easy to go ahead and edit it to make it so. It would take very large amounts of padding to defeat this. So it's definitely possible to fingerprint which wikipedia someone is browsing. But it's probably not easy to block it; the fingerprint is only detectable after the page has been downloaded. So it's not very useful for censorship.
  - chimeracoder 9y ago
shif 9y ago
The government could force pc manufacturers to deploy a root CA that they control and then do a MITM proxy to read everything the user is doing, they could also redirect wikipedia domain to another domain that just acts as a reverse proxy and deploy a legit cert on that other site
- tonysdg 9y ago
  Governments already deploy root CAs -- see here: https://security.stackexchange.com/questions/71171/is-there-anything-preventing-the-nsa-from-becoming-a-root-ca https://security.stackexchange.com/questions/71171/is-there-...
- tonyztan 9y ago
  Most Wikipedia/Wikimedia domains have HSTS preloaded in browsers, preventing redirection without a valid certificate.
  - theEXTORTCIST 9y ago
    AFAIK HSTS doesn't break TLS MITM. A valid x509 certificate is generated by the attacker (using a Certificate Authority trusted by the victim's browser) for the domain the victim is visiting and all is well for both TLS sessions (Client<->Attacker, Attacker<->Server). This all relies on the attacker having access to sign certs from the trusted CA. Certificate pinning in the HTTPS client would mitigate TLS MITM (HPKP).

cyphar 9y ago

And one thing to note is that people generally don't randomly pad the length of articles, so it's not _very_ difficult to figure out what articles you might be reading -- even over TLS.

colmmacc 9y ago
Random padding wouldn't really help; an active attacker can force retries, so the random distribution can be mapped (and then subtracted). To defeat TA you need to pad to a fixed length for all cases, or for a very large amount of cases. E.g. if every wikipedia page, plus all of the content it includes, came to exactly 10K, 20K, 30K, ... in size, then you could obscure what the user is reading.
giobox 9y ago
I've seen the theory that you could work out which pages are loaded from wikipedia over SSL by looking at other metrics like content length etc, but thanks to stuff like gzip compression, caching headers etc, this is much harder to exploit in practice. Plus there's the huge overhead of maintaining a database to link the frequently changing metrics back to the appropriate page on wikipedia. There's a great link somewhere (which of course I now can't find) where somebody prototyped this idea and found it really pretty hard to implement. In the event this was even tried, it would presumably be trivial to defeat with injection of random content somewhere in the server responses anyway. This of course all assumes we can trust the root certificate authority though :P
- cyphar 9y ago
  Yeah, good point. I presumed it would be a pain, but I never thought to see if someone actually tried it. Though you shouldn't be compressing things over TLS. I think the only proper solution is to pad out all articles (and images) to the nearest 2kB or something so that you can't figure out the length (randomness can be thwarted by forcing refreshes).

chimeracoder 9y ago

> My assumption is that because wikipedia has a known plaintext and a known link graph it's plausible to identify pages with some accuracy At least in theory, the latest versions of TLS should not be vulnerable to a known plaintext attack. TLS also is capable of length-padding, which would reduce the attack surface here as well for an eavesdropper. My understanding is that HTTP/2 makes it even more difficult to construct an attack on this basis, because HTTP/2 means multiple requests can get rolled into one. Of course, all this is assuming an eavesdropper without the ability to intercept and modify traffic. In practice, governments will probably just MITM the connection - we have precedent for governments abusing CAs like this in the past - and unless Wikipedia uses HPKP and we trust the initial connection and we trust that the HPKP reporting endpoint isn't blocked, then it's still possible to censor pages, without anybody else knowing[0]. [0] ie, the government censors will know, and the person who attempted to access the page will know, but neither Wikipedia nor the browser vendor would be able to detect the censorship automatically.

colmmacc 9y ago
TLS1.2 doesn't have an effective padding scheme, and with most sites (including Wikipedia) moving to AES-GCM and ChaCha20, it is actually less effective than the primitive CBC padding, which provided some protection. TLS1.3, which is still a draft, does have support for record-level padding, but I haven't seen any of the experimental deployments using it. HTTP/2 does have support for padding, but again, it's not common to see it being used, at least not in the kind of sizes it would take to obscure content fingerprints. Wikipedia is a particularly hard case for traffic analysis fingerprinting. First, the combination of page size and image sizes are just highly unique, even modulo large block/padding sizes. But more importantly, anyone can edit a wikipedia page, so if the size of a target page isn't unique, it's very easy to go ahead and edit it to make it so. It would take very large amounts of padding to defeat this. So it's definitely possible to fingerprint which wikipedia someone is browsing. But it's probably not easy to block it; the fingerprint is only detectable after the page has been downloaded. So it's not very useful for censorship.
- chimeracoder 9y ago

shif 9y ago

The government could force pc manufacturers to deploy a root CA that they control and then do a MITM proxy to read everything the user is doing, they could also redirect wikipedia domain to another domain that just acts as a reverse proxy and deploy a legit cert on that other site

tonysdg 9y ago
Governments already deploy root CAs -- see here: https://security.stackexchange.com/questions/71171/is-there-anything-preventing-the-nsa-from-becoming-a-root-ca https://security.stackexchange.com/questions/71171/is-there-...
tonyztan 9y ago
Most Wikipedia/Wikimedia domains have HSTS preloaded in browsers, preventing redirection without a valid certificate.
- theEXTORTCIST 9y ago
  AFAIK HSTS doesn't break TLS MITM. A valid x509 certificate is generated by the attacker (using a Certificate Authority trusted by the victim's browser) for the domain the victim is visiting and all is well for both TLS sessions (Client<->Attacker, Attacker<->Server). This all relies on the attacker having access to sign certs from the trusted CA. Certificate pinning in the HTTPS client would mitigate TLS MITM (HPKP).