ERR_ECH_FALLBACK_CERTIFICATE_INVALID
I’m not sure if I’ve blabbed about it before, but I have a collectd instance running in a container which shits RRD files into a shared directory, then I have another container that runs a Python script which spits out a bunch of MRTG-style graphs and a static HTML page to view them in. I do this because sometimes I want to show random people on the internet my graphs, and something like Grafana is actually a bit of a security nightmare when all I really want is a modern MRTG.
Occasionally, I want to look at one of these graphs from my work Mac, and in some cases I’ll get the error ERR_ECH_FALLBACK_CERTIFICATE_INVALID and it will refuse to load. After a time, the error goes away, and everything’s happy again.
I finally got to the bottom of it today, from a post on the pihole subreddit of all places!
ECH is “encrypted client hello”, which I don’t really give a shit about, but one of the hints that it’s usable is the HTTPS record type (which is DNS record number 65). Let’s back up a bit - one of the ways I make sure things will work even if our internet breaks is local services, such as Mastodon, etc, all have DNS overrides at our router - effectively split-horizon DNS, so when you’re on the public internet, I see an internet IP (either a Linode VM or CloudFlare, depending on the service and how much I care about people walloping it), when you’re in my house, you seen an RFC1918 address going directly to the service.
To accomplish this, I have a series of overrides in the dnsmasq configuration, so which one you see depends entirely on which DNS server you’re using.
But these DNS records don’t override the HTTPS request type, which occasionally gets passsed through to the upstream provider, and since that domain is hosted at CloudFlare, they do ECH on the free plans and you have to pay to turn it off, they return a happy response. Chrome (on my work machine, I’m a Firefox user otherwise) happily obeys, and then screams that the certificate isn’t the one specified specified in the HTTPS record (I think that’s what the base64 ech value is anyway) and refuses to connect. After a time the TTL of the HTTPS record expires, and the issue goes away.
Adding additional entries for each hostname dns-rr=some.hostname.fwaggle.org,65,000100 tells dnsmasq to respond to HTTPS queries with a record that’s a zero entry, one byte in length, with only a null byte for the contents.
And it appears to work?
There are apparently other ways I can turn off ECH at the browser level, but this is just for one specific domain so I think it’s fine. Is it the right way to do it? Probably not, “yeah we have a record for this” “jokes, it’s empty” is not really being conservative in what you send but as long as browsers do the right thing and silently reject it it’ll probably keep working.
