Support dropping ESNI records for blocked domains


#1

When combining Pi-Hole with pixelserv-tls , the encrypted blocked connections can be answered by an HTTPS server instead of being completely dropped ( BLOCKINGMODE=IP ).

The way this works is that pixelsrv-tls generates a certificate dynamically that will match the Server Name sent in the SNI extension, which should end up passing verification by the client (if the CA used to generate such certificates is trusted).

With ESNI (Encrypted Server Name Indication) that is now getting tested by CloudFlare and Mozilla, the client sends the server name encrypted so pixelsrv would be unable to generate a matching certificate.

While the connection will ultimately be blocked, the browser will attempt to establish such connections until it ultimately fails.

What would be great is if for blocked domains, there could be an option to also block the corresponding ESNI record. Right now this could mean answering with NXDOMAIN to _esni.blocked.domain.

It might be safe enough to enable by default when responding with an IP (BLOCKINGMODE=IP or IP-NODATA-AAAA)

Dropping all ESNI records with a regex is not an option as that would impact non-blocked domains.

While this is obviously the very beginning of this spec, I anticipate browser support to pick up soon. Both Firefox and Safari have preliminary implementations. And since CloudFlare supports basically 10% of internet traffic, I’m sure there are some commonly blocked domains already supporting this.

Original GitHub issue


#2

@DL6ER, I’ve also read the GitHub discussion

For now, this can still be disabled in the browser, however this may change in the future.

What worries me more is the usage of ESNI in devices you cannot control, such as built in telemetry, chromecast, …

I think that it would be very wise to anticipate this new spec will be implemented sooner or later and already have a defense against it.

@mathieuh
Unfortunately, I’m NOT smart enough to make a case for this to be implemented in dnsmasq. I would suggest to propose this enhancement to Simon Kelley.

@DL6ER to avoid a possible conflict with the changes made to dnsmasq in pihole-FTL, your input for this request may (will?) be required…


#3

It’s unlikely to impossible that dnsmasq makes a change that pihole-FTL could not incorporate.

I agree, but I also see that this should be done inside dnsmasq instead of having to add another hack in pihole-FTL. Implementing regex blocking was one thing, but adding this would have to be done in an even deeper region of the dnamsq cache code which is something I really don’t like to do.