> 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.

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.

> 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

Well, it's detectable after the request has been made and Wikipedia sends the response. Assuming that a government has the capabilities to block delivery of that response (which they do), they can still implement censorship at this level, before the page reaches the end user.

> In practice, governments will probably just MITM the connection

If they routinely MITM connections they will quickly be found out, and the CA would be removed from browsers.

Except China has their own browser made by a state controlled company that a lot of people use. This browser is already demonstrated to accept the government CA and ordinary people in China don't care.

What's the browser, or do you mean Opera?

360 Secure Browser by Qihoo, we saw back in 2014 that it was already compromised then: https://en.greatfire.org/blog/2014/oct/china-collecting-appl...

If some websites will break down in this browser while working in other browsers, people will probably notice.

Why would they break? If the MITM certificate is trusted at the local level, everything should work fine in their browsers.

Except some pages won't be there (that's what censorship is isn't it?)

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.

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.

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

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).

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

Governments already deploy root CAs -- see here: https://security.stackexchange.com/questions/71171/is-there-...

Most Wikipedia/Wikimedia domains have HSTS preloaded in browsers, preventing redirection without a valid certificate.

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).