Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An unidentifiable mechanism that helps bypass the Great Firewall of China

github.com

Post reply on HN
Print view View original

21–30 of 40 posts

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

#21

Post by zzzcpan »

geocar wrote: post #17
callahad wrote: post #6

Earlier quoted context omitted.

No. It's part of the cleartext SNI header. There is a proposal to encrypt the SNI information, but afaik, it's not yet widely used. https://en.wikipedia.org/wiki/Server_Name_Indication

If I can assume Bob has Alice's public key (and that DNS was gold and whatever; i.e. the same axiom ESNI has), then: - 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 lib…

> Oh and they need to walk back this stupid shit

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.

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

#22

Post by slantyyz »

marcus_holmes wrote: post #12
fnord77 wrote: post #9

it took me a few minutes to figure out what "GFW" meant

I honestly thought Games For Windows

I was thinking it was either Games for Windows or Git for Windows, and missed "Great Firewall" on first skim of the Readme.

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

#23

Post by kohtatsu »

zzzcpan wrote: post #15
kohtatsu wrote: post #13

Earlier quoted context omitted.

Back in the day there was mostly only 1 website per IP, so when you connected over port 443 for HTTPS, the server would only have the one cert to give you. 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 gla…

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 :(

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

#24

Post by GoblinSlayer »

nneonneo wrote: post #7
thisgoodlife wrote: post #4

Earlier quoted context omitted.

> the FQDN is sent plaintext as part of HTTPS. Can you please elaborate on that? domain name is sent after ssl handshake, no? Why is it sent plaintext?

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.

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

#26

Post by eplanit »

fnord77 wrote: post #9

it took me a few minutes to figure out what "GFW" meant

It used to be a standard of good writing to always expand acronyms at first use. That seems to be gone now as frequently I don't see that in practice much anymore.

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

#27

Post by lxgr »

GoblinSlayer wrote: post #24
nneonneo wrote: 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.

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.

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

#28

Post by netheril96 »

exabrial wrote: post #18

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.

This software allows you to specify your own CA to verify certificate. The system CA store won't matter in that case.

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

#30

Post by aasasd »

netsharc wrote: post #3

This page has more details than the "executive summary" https://github.com/trojan-gfw/trojan/blob/master/docs/protoc... 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…

Yeah, afaik many DPI tools advertise being able to detect protocols behind TLS/HTTPS or SSH.

OTOH if you just wrap HTTP(S) requests to a different server into this, then it probably should look pretty natural.

Post reply on HN