-
Notifications
You must be signed in to change notification settings - Fork 11
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
Encrypted SNI #4
Comments
@mrbluecoat thanks for your report Tested with firefox 70. Cloudfare DoH + ESNI via about:config :
Test page : https://cloudflare.com/cdn-cgi/trace Unfortunately, firefox does not fallback to unencrypted SNI and the connection is dropped. |
I wait for encrypted SNI to be a standard to support encrypted SNI in a better way |
Thanks for the update. Dropping Cloudflare traffic for hosts using ESNI is a tolerable stopgap but is there any long-term solution for monitoring home/work traffic with ESNI? Perhaps client cert approach like mitmproxy? |
key to encrypt SNI is provided by DNS. In Cloudflare current implementation of the draft RFC, the key is obtained by requesting a DNS TXT entry of the root domain name prefixed by _esni.
Current draft says that a ESNI DNS type is used instead of TXT. Since ESNI key is provided by DNS, if you control the DNS, you can deny client from receiving the SNI key so that the browser does not encrypt the SNI |
It seems bind has no option to block DNS request type but unbound has It's worth looking at unbound |
Very promising! Thanks for your research, I really appreciate it. I'm working on an embedded system with only 512MB of memory so I wonder if unbound or knot-resolver would be lightweight enough. I'll look into them and FTL/dnsmasq: https://github.com/pi-hole/FTL/blob/master/dnsmasq_interface.c#L47 |
I'm not an iptables expert so I'm not sure if a variation of this would help: https://serverfault.com/a/843805 |
I would not use iptables for filtering DNS type query. I presume it would take too much ressource. Filtering by the server should be more performant. To be tested with unbound
If you have a procedure to install unbound, please share it |
Using https://docs.pi-hole.net/guides/unbound/ as a guide:
|
I haven't found an example to block type |
Another relevant CoreDNS reference: https://coredns.io/plugins/rewrite/ |
I'm slowly making progress on this. I've been able to install and configure Knot-Resolver to confirm the proposed approach above works. Install the latest Knot-Resolver:
Configure Knot-Resolver:
Start Knot-Resolver on a couple CPU cores: Run basic tests:
Prerequisites for ESNI test: compile ESNI-enabled OpenSSL and curl Run ESNI test:
|
P.S. I confirmed your Firefox testing. It only works as desired if
Example bypass:
Further testing will be needed to see if we can IP spoof the common public DNS endpoint IPs via #6 to force DNS resolution via our local knot-resolver install that blocks ESNI. Not a perfect solution since the list of those IPs will be constantly growing but it's a start at least and will capture most DNS circumnavigation attempts. |
Filtering TLS packet with ESNI field is not a good approach in long term because there will be no fallback to plaintext SNI in case connection with ESNI does not work. It would result in fitering legitimate website, which we do not want to. I think the best approach would be to sync with the local DNS to get the ESNI entry in DNS request in addition to A/AAAA entries that associate domain name to IP address. Keep in cache couple of IP address / computed ESNI for domain name so that we can take the decision whether to filter ESNI in middle as we do currently with plaintext SNI |
But if the browser bypasses DNS entirely (like the Firefox example above) how will syncing with the local DNS server help us? |
We should maintain a blacklist of DoH DNS so that browser fallbacks to the DNS set in OS by DHCP |
I see. Something like https://github.com/bambenek/block-doh |
Any options for dealing with encrypted SNI? https://blog.cloudflare.com/encrypted-sni/
The text was updated successfully, but these errors were encountered: