Live data from Hacker News

An unidentifiable mechanism that helps bypass the Great Firewall of China

github.com

31–40 of 40 posts

Re: An unidentifiable mechanism that helps bypass the Great Firewall of China

#31

I don't think it would be very difficult for the Chinese government to demand a compromised root cert authority be installed on every device sold there.

They certainly can try, but major vendor will resist. Kazakhstan government has tried this method[1]. They sure can try sneaky ways, but any imported laptop connecting to hotel Wi-Fi could reveal it. [1]: https://blog.mozilla.org/security/2019/08/21/protecting-our-...

>They certainly can try, but major vendor will resist

It's China. Apple/Microsoft isn't going to resist. Google might not resist because they're already banned there so they've got nothing to lose. Regardless, it doesn't really matter because there's a bunch of homegrown chromium forks that can readily replace Chrome.

Re: An unidentifiable mechanism that helps bypass the Great Firewall of China

#32
post #7

Earlier quoted context omitted.

A given server might be hosting multiple websites, each with a different certificate (e.g. a CDN endpoint). It needs to know which certificate to present to the user. Therefore, during the initial TLS handshake, the client sends the server name (hostname) in plaintext in a field called the Server Name Indication (SNI). This is mandated by the fact that a certificate identifies a website, not a server. This is distinc…

SNI is an optional extension and is legal to be missing. No SNI - no problem.

Nearly all browsers support SNI, there's most likely not even a hidden config to disable it.

Re: An unidentifiable mechanism that helps bypass the Great Firewall of China

#33
post #15

Earlier quoted context omitted.

Nope, encrypted SNI cannot work against GFW or pretty much any state censorship as the whole idea is bullshit and relies on everyone a) tunneling DNS queries to a centralized party, which itself only operates under the state's mercy, and b) everyone hosting on a single centralized party and c) this party randomizing IP addresses of web sites (none of the CDNs do that, because they want to avoid risking all of their I…

Oh gosh that sounds awful. I have to admit I was using "Encrypted SNI" in a general sense, I hadn't looked at the details of ESNI, the proposed solution. In my head encrypted SNIs was a somewhat straightforward problem to solve but thinking about it more it's a bit tricky. What you describe of ESNI sounds horribly convoluted :(

The key exchange and identification for encrypted X is always the hard part.

For encrypted SNI, keys are expected to be published via DNS, which GFW is happy to disrupt.

Once you get a key, you have to send the key identifier in the clear (otherwise, the service doesn't know how to decrypt; unless you want to just do trial decryption with all available keys and hope that doesn't use too much CPU); the key identifier becomes the enforcement target at this point, unless you're on a host that shares ESNI keys among the many sites it hosts and is not acceptable collateral damage.

Re: An unidentifiable mechanism that helps bypass the Great Firewall of China

#36
post #2

I think anything looking to serve China should at least avoid hosting on github pages until encrypted SNI is widely available. When someone visits the online documentation at trojan-gfw.github.io, the FQDN is sent plaintext as part of HTTPS. If the data is plainly on github.com (like the wiki), it would at least require an MITM to see what you are reading. Of course an MITM might be likely in China regardless. It's a…

I remember the disappointment and discussions of people when Amazon announced the deprecation of the S3 "path-style" hosting in favor of supporting only "virtual-host" style hosting. It was about the same concern (ISPs being able to see which static S3-hosted sites are visited). The discussion even lead to a small change of the AWS S3 roadmap.

HN discussion: https://news.ycombinator.com/item?id=19821406

AWS blog post as answer to the discussions: https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-...

Re: An unidentifiable mechanism that helps bypass the Great Firewall of China

#37
"unidentifiable mechanism" I'm not sure this is actually true.

You can determine that it is a VPN by checking the amount of exchanged packets between interval of time (e.g. if 5 kbps are routinely sent every 30 seconds for 5 minutes this is totally abnormal)

Another alternative for the government could be to limit the bandwidth and time of hosts who have a big standard deviation in the amount of the packets per second they transmit.

So undetectable I don't think so and I believe smarter people here can find even better ideas.

That being said it's a very nice tool, certainly useful in corporate environments as well (except of course, that it'll be suspicious that one single host is exchanging so much data and keeping so long connections)

Re: An unidentifiable mechanism that helps bypass the Great Firewall of China

#38
post #27

Earlier quoted context omitted.

SNI is an optional extension and is legal to be missing. No SNI - no problem.

You won't be able to reach any web server that is sharing more than one hostname per IP that way. This includes all sites on a free Cloudflare plan to my knowledge.

Cloudflare terminates ssl at the edge, no? Then it has the private key and has no need to care about the site certificate. It just sends a certificate with all hosts in alt names.

Re: An unidentifiable mechanism that helps bypass the Great Firewall of China

#39
post #32

Earlier quoted context omitted.

SNI is an optional extension and is legal to be missing. No SNI - no problem.

Nearly all browsers support SNI, there's most likely not even a hidden config to disable it.

Browser is not the only program that uses internet. For example, openssl doesn't send SNI by default.

Re: An unidentifiable mechanism that helps bypass the Great Firewall of China

#40
post #27

Earlier quoted context omitted.

You won't be able to reach any web server that is sharing more than one hostname per IP that way. This includes all sites on a free Cloudflare plan to my knowledge.

Cloudflare terminates ssl at the edge, no? Then it has the private key and has no need to care about the site certificate. It just sends a certificate with all hosts in alt names.

Cloudflare has way more customers/hostnames than what would fit into a single X.509 certificate. (They actually do seem to do what you describe to support non-SNI clients, but not on their free tier.)

SNI also allows decoupling TLS and TCP termination, which in turn allows for shared IP addresses and load balancers without necessarily delegating TLS termination and exposing certificates to some shared host.

Post reply on HN