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

11–20 of 40 posts

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

#11

Post by JoachimSchipper »

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…

Yes; there is some discussion of attacks in https://github.com/trojan-gfw/trojan/issues/14.

Personally, I'd be very careful telling people to rely on my software for avoiding the Chinese surveillance - traffic analysis is terrifyingly powerful.

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

#13

Post by kohtatsu »

thisgoodlife wrote: post #4
kohtatsu wrote: 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…

> 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?

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 glaring privacy hole that most people aren't aware of. Encrypted SNI needs to come sooner.

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

#15

Post by zzzcpan »

kohtatsu wrote: post #13
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?

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 IP ranges being banned by states because of a single website).

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

#16

Post by amdavidson »

swiley wrote: post #5
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?

He’s probably talking about the DNS lookup.

He is probably not. See your sibling comments.

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

#17

Post by geocar »

callahad wrote: post #6
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?

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 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...

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

#19

Post by zhaoweny »

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.

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-...

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

#20

Post by yorwba »

JoachimSchipper wrote: post #11
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…

Yes; there is some discussion of attacks in https://github.com/trojan-gfw/trojan/issues/14 . Personally, I'd be very careful telling people to rely on my software for avoiding the Chinese surveillance - traffic analysis is terrifyingly powerful.

For the people currently using random forks of ShadowsocksR they purchased via shady backchannels, an alternative that is less likely to get blocked is probably more important than absolute security guarantees. After all, most users of censorship circumvention tools aren't secretly plotting revolution, they just want to watch YouTube.
Post reply on HN