Currently HTTPS sends domain in clear-text before establishing a connection. It allows to host (and block) website by domain, not by IP. May be HTTPS should have optional extension to send URI in clear-text before establishing a connection. This way, if censors decide to block Wikipedia, users can opt-in into this behaviour and have unblocked Wikipedia except few selected articles.
Wikipedia’s Switch to HTTPS Has Successfully Fought Government Censorship
61–70 of 126 posts
Re: Wikipedia’s Switch to HTTPS Has Successfully Fought Government Censorship
#62It won't last, at least for China. Their government is working on a clone of wiki, scheduled for 2018[0]. Once that's done they'll likely completely ban the original.
Wikipedia publishes database dumps every couple of days[1]. So it shouldn't be that expensive for smaller governments to create and host their own censored mirror. You'd maintain a list of banned and censored articles, then pull from wikipedia once a month. You'd have to check new articles by hand (maybe even all edits), but a lot of that should be easily automated, and if you only care about wikipedia in your native tongue (and it's not english) that's much less work.
The academics will bypass censorship anyway, since it's so easy[2], so an autocrat won't worry about intellectually crippling their country by banning wikipedia. Maybe they don't do this because the list of banned articles would be trivial to get.
Better machine translation might solve this by helping information flow freely[3]. We have until 2018 I guess.
[0] https://news.vice.com/story/china-is-recruiting-20000-people...
[1] https://dumps.wikimedia.org/backup-index.html
[2] https://www.wired.co.uk/article/china-great-firewall-censors...
[3] https://blogs.wsj.com/chinarealtime/2015/12/17/anti-wikipedi...
Re: Wikipedia’s Switch to HTTPS Has Successfully Fought Government Censorship
#63Earlier quoted context omitted.
Because Wikipedia is too useful. Note that it required a certain self-confidence that this was the case for Wikipedia to implement this strategy. And it's self-fulfilling - if Wikipedia allowed itself to be censored, then it would have fewer contributors and its usefulness would suffer. There's a rather interesting analogy to be made with the GPL here. Critics argue that companies shy away from it because they cannot…
> Critics argue that companies shy away from it because they cannot control it. No, they don't. Critics point out that companies avoid it, and non-critics ascribe this avoidance to "can't control it", which is false, because nothing under a third-party copyright under any non-exclusive license can be controlled by the licensee, but businesses avoiding the GPL don't generally avoid all non-exclusive licenses.
Insofar as companies avoid it, they do so because it constrains their behaviour in some way. Call it what you will; my wording was perhaps sloppy.
For the increasing number of companies that do participate in the GPL ecosystem, they do so because the opportunity cost of not participating outweighs the concomitant behavioural constraints. This produces a strong network effect as GPL software gains contributors, making GPL software more useful.
Wikipedia's anti-censorship strategy is analogous in that the switch to HTTPS raised the opportunity cost of censorship to the loss of the entire Wikipedia "ecosystem", which for many regimes is more severe than the "cost" of not censoring. This too produces a network effect as Wikipedia gains more contributors, thus further increasing its value.
Re: Wikipedia’s Switch to HTTPS Has Successfully Fought Government Censorship
#64Currently HTTPS sends domain in clear-text before establishing a connection. It allows to host (and block) website by domain, not by IP. May be HTTPS should have optional extension to send URI in clear-text before establishing a connection. This way, if censors decide to block Wikipedia, users can opt-in into this behaviour and have unblocked Wikipedia except few selected articles.
Two problems:
- Unlike the host, URIs are a property of the request, not the connection, so sending it as part of the connection handshake doesn't really make sense.
- Unlike the host, there is a very long history of putting secret things into the URI. Even if the extension is built with this in mind, the number of security breaches that will result is greater than zero, with probability one. That's probably not the correct price to pay for convenient censorship infrastructure.
Re: Wikipedia’s Switch to HTTPS Has Successfully Fought Government Censorship
#65Currently HTTPS sends domain in clear-text before establishing a connection. It allows to host (and block) website by domain, not by IP. May be HTTPS should have optional extension to send URI in clear-text before establishing a connection. This way, if censors decide to block Wikipedia, users can opt-in into this behaviour and have unblocked Wikipedia except few selected articles.
Absolutely not. The response to censorship should not be to make things easier for the censor.
Anyway, the idea is unworkable as the user's client could simply lie about what URI it's going to send after the encrypted connection is setup.
Re: Wikipedia’s Switch to HTTPS Has Successfully Fought Government Censorship
#66Can 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.
> 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.
Re: Wikipedia’s Switch to HTTPS Has Successfully Fought Government Censorship
#67It won't last, at least for China. Their government is working on a clone of wiki, scheduled for 2018[0]. Once that's done they'll likely completely ban the original. Wikipedia publishes database dumps every couple of days[1]. So it shouldn't be that expensive for smaller governments to create and host their own censored mirror. You'd maintain a list of banned and censored articles, then pull from wikipedia once a mo…
Why hasn't it been done yet? It's not like Wikipedia is a new thing.
Re: Wikipedia’s Switch to HTTPS Has Successfully Fought Government Censorship
#68Can 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.
> 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 const…
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.
Re: Wikipedia’s Switch to HTTPS Has Successfully Fought Government Censorship
#69Can 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.
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.
Re: Wikipedia’s Switch to HTTPS Has Successfully Fought Government Censorship
#70Earlier quoted context omitted.
> 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 const…
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 comm…
> 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.