Need to drop SNI in backend for specified domains #268
Comments
|
While this sounds possible, I think a VPN would be a better solution. I would imagine a firewall could just as easily filter based on the server certificate, or the subject in that certificate. Stripping out the SNI header doesn't seem to buy any meaningful privacy, and encourages increased IP address consumption. Another consideration is increases the complexity of SNIproxy but requiring the TLS protocol module to modify the buffer state. Presently there is no direct dependency between these two modules. Your welcome to SNIproxy as a base for this application. I would start by introducing a |
|
Removing the SNI header would probably also yield a different certificate. I also know of servers that will outright reject clients without SNI. I do agree that a VPN is probably a better solution. I don't share the concern about IP address consumption, since there are plenty of IPv6 addresses out there. |
|
I have tried to remove the server name extension field, and increases the padding extension to keep the total TLS record length as the same. @dlundquist Do you have any idea? |
|
After many times retry, remove the server name extension will lead a Handshake Failure (40), or Decrypt Error(51) by different servers. |
|
@Nefurtity I didn't analyze your TLS handshakes in detail, but my first through is to check that you updated the TLS record length, handshake length and extension length when you remove the SNI extension. Since you can modify the content of the SNI header without breaking the TLS negotiation, I would suspect that the content of the TLS handshake isn't protected by a message digest later in the handshake. I seem to recall some application proxy that modified the cipher suites to ensure complacence requirements, which would also support this. I would start by writing a tests for the TLS handshake mutation function similar to the ones in tests/tls.c with a very simple handshake and ensuring the resulting handshake matches one you've modified by hand exactly. Should be modified into: As for testing handshakes I would look at feeding your requests to OpenSSL s_server with the debug flag for initial testing. |
|
I tried change the first byte of server name (example.com -> axample.com) and finally got a decrypt error from server. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The firewall will look for SNI field to block some websites, because SNI is plain texts in Client Hello, the server name can be detected easily, and the SSL connection would be blocked.
Need to specify a list of domains in config file, when the Client Hello message coming, look for SNI field, if SNI is bellowing one of the specified domains, drop the SNI e.g. hostname at the backend, the Client Hello message without SNI go through the firewall, finally SSL connection established.
However this trick only takes effect for some websites which supports non-SNI SSL, but I believe it is very useful to access a lot of websites behind an SNI sensitivity firewall.
The text was updated successfully, but these errors were encountered: