Slashdot Mirror
Wikipedia's Switch To HTTPS Has Successfully Fought Government Censorship (vice.com)
Determining how to prevent acts of censorship has long been a priority for the non-profit Wikimedia Foundation, and thanks to new research from the Harvard Center for Internet and Society, the foundation seems to have found a solution: encryption. From a report: HTTPS prevents governments and others from seeing the specific page users are visiting. For example, a government could tell that a user is browsing Wikipedia, but couldn't tell that the user is specifically reading the page about Tiananmen Square. Up until 2015, Wikipedia offered its service using both HTTP and HTTPS, which meant that when countries like Pakistan or Iran blocked the certain articles on the HTTP version of Wikipedia, the full version would still be available using HTTPS. But in June 2015, Wikipedia decided to axe HTTP access and only offer access to its site with HTTPS. [...] The Harvard researchers began by deploying an algorithm which detected unusual changes in Wikipedia's global server traffic for a year beginning in May 2015. This data was then combined with a historical analysis of the daily request histories for some 1.7 million articles in 286 different languages from 2011 to 2016 in order to determine possible censorship events. [...] After a painstakingly long process of manual analysis of potential censorship events, the researchers found that, globally, Wikipedia's switch to HTTPS had a positive effect on the number censorship events by comparing server traffic from before and after the switch in June of 2015.
It's a little worse than that. Because the url's are different, the Chinese government has blocked the zh.wikipedia.org but not the en.wikipedia.org, presumably because most Chinese people can not read English too a high enough level. They should move the language into the end part of the URL i.e. wikipedia.org/en/some-article
any decent overlord is using SSL inspection (seemlessly via compromised root certs)
Cite?
There have been occasional instances of compromised root certs, which have fairly quickly been removed from default trust stores, but I see no evidence of ongoing vulnerability -- excepting when the overlord controls the trust store. That is common in corporate scenarios but not really possible without removing admin rights from users' computers, which is hard for any nation other than North Korea to do.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Also except for the fact that ISP can see your destination AND the url request... Yep they can not see it at all.
No. The ISP, etc., can see the hostname in the DNS request and they can see the IP address of the server you connect to, but that's all. The first messages exchanged with the server establish the encrypted channel and then the GET (or similar) request that specifies everything after the hostname in the URL is inside the secure channel. They cannot see the URL.
Governments that wish to censor HTTPS sites with proper TLS configurations and decent CAs really have only one option: to block the sites entirely. The only thin exception to this is if they can inject their own CA certificates in the TLS trust stores. That enables a man in the middle attack. Doing that is easy for corporations on corporate-owned and controlled machines, but harder for governments to do at scale, since it essentially requires taking away the ability to install arbitrary software on the end-user machine.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
The web client will reuse the connection to the server, and to a 3rd-party observer it will all look like one massive blob of data so that all they could really get out of it is the content length of the whole thing, which due to gzip compression (which is enabled for Wikipedia, I checked), caching of resources, etc, means it will vary considerably from one fetch of a given page to the next.
If that isn't enough, http servers and TLS ciphers themselves actively hide the length of the content they transmit with techniques such as padding and adding additional random bytes to the beginning or end of a HTTPS transmission.
All up, I'd say this vector would be pretty much impossible to exploit.
Windows is a bonfire, Linux is the sun. Linux only looks smaller if you lack perspective.
How would you ever know if the US government went to Verisign and ordered them to create a valid cert for any domain? If you didn't have some form of client cert pinning you would never know.
Even if they could have a duplicate created and signed by Verisign, the public and private key pair would necessarily be different because these are generated at the time of certificate creation using a cryptographically strong random prime number pair generator. Thus, the signature on the certificate would be different than the one that Verisign previously generated for the original recipient. So, even though the new certificate would be "trusted", because it was issued by Verisign, the signature hashes would be different so a sharp user or a browser that queried a database of known public hashes would be able to spot the discrepancy and warn the user that the certificate is fishy. Remember, these certificates were designed to prevent precisely the sort of behavior that you're suggesting, namely creating identical forged copies of originally issued certificates.
You're likely delusional to believe that there are no CA Root or Intermediate certificates in possession of various governments of the world.
I wouldn't claim there are none, but we have pretty strong evidence that if there are any, they're used sparingly and in a very targeted way. If such unauthorized keys were being used broadly, someone would notice that the public key certificates received by end users are not the same ones being served by the sites.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Of course countries simply respond by censoring ALL of Wikipedia.
Seven puppies were harmed during the making of this post.