3 ms·
Since that we're talking practicals, let's look at China's answer: just block the IP, we already knew what's behind it anyways. Besides, in an SNI-less world th
by zinekeller 4y ago
Since that we're talking practicals, let's look at China's answer: just block the IP, we already knew what's behind it anyways. Besides, in an SNI-less world the censors would just visit the IP address - that's not significantly different on today's checking of SNI. Besides, some email filtering now also checks the IP address' associated domains, which not just includes the rDNS (that's easy) but also using a DNS datafeed that shows which domains point to that IP.
- bawolff 4y agoIn fairness - counterexample: at various times china has blocked zh.wikipedia.org, but doesnt want to block en.wikipedia.org as that makes them look draconian to visiting foreigners. Both sites are on the same IP with same wildcard cert. Their options are basically only SNI sniffing or DNS poisioning.
- zinekeller 4y ago> In fairness - counterexample: at various times china has blocked zh.wikipedia.org, but doesnt want to block en.wikipedia.org as that makes them look draconian to visiting foreigners. While I'll accept this as a hypothetical, I've just verified this one since I remember Wikimedia has a rather complicated structure (https://wikitech.wikimedia.org/wiki/Data_centers https://wikitech.wikimedia.org/wiki/Data_centers), and I can verify that in the US you'll see an Let's Encrypt-issued wildcard certificates, while the Singaporean datacenter sends Digicert certificates that is apparently separated (except for desktop and mobile one - so for example accessing en.wikipedia sends you en.wikipedia and en.m.wikipedia), and the European ones (if my understanting is the current setup) uses Globalsign-issued certs, so probably they're dealing with censorship in a methodical matter.
- bawolff 4y agoYou still get a wildcard cert. e.g. if i do: echo -e 'GET / HTTP/1.1\r\nHost: en.wikipedia.org\r\nConnection: close\r\n\r\n' | openssl s_client -connect text-lb.eqsin.wikimedia.org:443 -ign_eof -noservername -showcerts I get a cert with: X509v3 Subject Alternative Name: DNS:\*.wikipedia.org, DNS:wikimedia.org, DNS:mediawiki.org, DNS:wikibooks.org, DNS:wikidata.org, DNS:wikinews.org, DNS:wikiquote.org, DNS:wikisource.org, DNS:wikiversity.org, DNS:wikivoyage.org, DNS:wiktionary.org, DNS:wikimediafoundation.org, DNS:w.wiki, DNS:wmfusercontent.org, DNS:\*.m.wikipedia.org, DNS:\*.wikimedia.org, DNS:\*.m.wikimedia.org, DNS:\*.planet.wikimedia.org, DNS:\*.mediawiki.org, DNS:\*.m.mediawiki.org, DNS:\*.wikibooks.org, DNS:\*.m.wikibooks.org, DNS:\*.wikidata.org, DNS:\*.m.wikidata.org, DNS:\*.wikinews.org, DNS:\*.m.wikinews.org, DNS:\*.wikiquote.org, DNS:\*.m.wikiquote.org, DNS:\*.wikisource.org, DNS:\*.m.wikisource.org, DNS:\*.wikiversity.org, DNS:\*.m.wikiversity.org, DNS:\*.wikivoyage.org, DNS:\*.m.wikivoyage.org, DNS:\*.wiktionary.org, DNS:\*.m.wiktionary.org, DNS:\*.wikimediafoundation.org, DNS:\*.wmfusercontent.org, DNS:wikipedia.org I suspect the different certs are just to have a backup cert that is always being tested that can quickly be swapped to if something goes wrong.