-
Notifications
You must be signed in to change notification settings - Fork 564
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What if it deal with the server side? #27
Comments
Thanks for the update on the GFW's evolution. We assume that the GFW has separate TCBs for each direction (outbound: client->server, inbound: server->client), and our current approach can only tear down the outbound TCB. If there's sensitive data in the server's response, it will still trigger RST. In that case, we may either seek server's support for deploying the tool or find some method to tear down the inbound TCB from client-side. |
It is not like what you think. GFW does NOT filter Server side certificate names, instead it filters SNI in SSL Client Hello request |
I just added the support for HTTPS protocol, so now INTANG can deal with SNI field censorship. But I can see the domain name also appears in the certificate in the ServerHello message, which means the GFW may look into that field in the future (and seems it doesn't do that for now). |
Since October 2017,it seems that the GFW deployed a new policy that it analyzed the name of certification from the ACK of server.
If it contained like google.com ,then sent RST to server and dropped all packages from the client to that IP address.
Someone said that it needed to wait for tls1.3 online that encrypted the certification name.
So,does this tool still work?
The text was updated successfully, but these errors were encountered: