An unidentifiable mechanism that helps bypass the Great Firewall of China
github.com
github.com
As far as I understand it:
1. Client connects to the standard HTTPS port.
2. If it provides a packet with the right (encrypted) password, then the server acts as a SOCKS5 proxy.
3. If it doesn't provide the right password, the server responds like a normal HTTP server over the TLS connection.
Seems pretty clever, the hard bit is making sure the passwords don't leak and the firewall starts bombarding suspect servers with requests (brute-forcing passwords). Also if there are timing differences between a genuinely confused HTTP server and a "Trojan" server faking the confusion, they'd figure that out too.
Also, things like continuous back-and-forth between the client and a simple webserver would be suspicious, because usually clients send small requests in bursts, get the response, and activity would stop (it doesn't apply to streaming sites, obviously, but there the clients won't be as chatty either). So things like Skype calls might be easily recognized...
Personally, I'd be very careful telling people to rely on my software for avoiding the Chinese surveillance - traffic analysis is terrifyingly powerful.
OTOH if you just wrap HTTP(S) requests to a different server into this, then it probably should look pretty natural.
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 also worth noting the Tor project has done a lot of work in this area: https://2019.www.torproject.org/docs/pluggable-transports.ht...
Can you please elaborate on that? domain name is sent after ssl handshake, no? Why is it sent plaintext?
- DNS lookup for _esni.domain CNAME _esni.cloudflare.net,
- client connect to _esni.cloudflare.net via HTTPS and negotiate TLS with SNI rejected
- HTTP Host header contains desired target
Servers can trivially support the above "new" protocol (chances are they already do), no changes to DNS clients libraries or servers, and clients can support the new "encrypted SNI" by using OpenSSL APIs that already exist. GFW can't do anything unless cloudflare give them the key for _esni.cloudflare.net.
Everyone wins except the nerds who really wanted to make a new protocol. Oh and they need to walk back this stupid shit:
https://support.cloudflare.com/hc/en-us/articles/36002977947...
And the reason this stupid shit of preventing domain fronting was put in place is the exact reason why eSNI doesn't work, i.e. because it prevents state censorship and forces the state to instead block all the IP addresses in turn forcing companies to either cooperate with the state or expose enough identifying info to not interfere with state censorship.
This is distinct from the HTTP Host: header, which is sent inside the TLS session and therefore is encrypted along with the rest of the HTTP request.
This includes all sites on a free Cloudflare plan to my knowledge.
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.
Cloudflare can explain it much better than me.
One day people wanted to serve multiple websites from one IP, so they had browsers tell the server which site they are looking for (Server Name Indication); that way the server would know which SSL cert to send for the handshake.
SNI is still plaintext, it's a glaring privacy hole that most people aren't aware of. Encrypted SNI needs to come sooner.
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.
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-...
[1]: https://blog.mozilla.org/security/2019/08/21/protecting-our-...
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.
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)