Encrypted Client Hello is something I'd come up with if I was trying to wildly guess an acronym haha
this post was submitted on 03 Oct 2023
241 points (97.3% liked)
Technology
60084 readers
3170 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 2 years ago
MODERATORS
So, currently when you visit a https secured website the initial request to the server is not encrypted. I suspect the reason for this is that say you run a web server on 1.2.3.4. But there's 4 different websites hosted on that server each with their own SSL/TLS keys.
The server doesn't have a way to know which keys/certificates to use until it knows what site you want to access. So, the initial request is encrypted with a server key, and that server key is fetched via DNS over HTTPS.
Now, here's the question. Why MUST it be DoH? For email, DKIM, SPF and DMARC settings (including public keys) are configured using standard DNS (with DNSSEC). Why do they not allow DNSSEC AND/OR DoH?
Other than that weird limitation, I think it's a good thing.
currently when you visit a https secured website the initial request to the server is not encrypted.
It is encrypted, just not all of it. Back upon a time all of it was encrypted but it created a problem. It was impossible to host multiple different domains on the same IP over HTTPS because chicken and egg: couldn't get the domain from the host header without completing the encryption handshake, but to do that you had to know which domain's certificate to use.
To solve the problem they came up with a TLS extension called SNI that indicates the certificate during handshake, but does so by pulling the domain name out in the clear.
ECH aims to encrypt these parts left in the clear, but can't do it with the TLS certificate (chicken and egg above). So they resorted to the encryption used by DoH instead.
ECH relies on DNS over HTTPS (DoH) for its functionality, using it to fetch the key needed for encryption.
Seems like it's only DoH. Which is kinda lame in a situation like mine where I'm running a DoH proxy (cloudflared), using a PiHole behind that, and pointing my LAN clients at the PiHole using unencrypted DNS. So everything leaving my network is DoH but it's not done directly in the browser, so I can't take advantage of ECH.
Probably because DNS is unencrypted and would allow tampering of the key needed for ECH to work
PiHole doesn't support DoH? I mean as a server? Is there a feature request open for that?
If pihole is still using dnsmasq then I have no idea if DoH will be supported tbh...
TIL about cloudflared being a DoH proxy. Nice, will be looking into this later...
It works well, and it's easy to set up. Previously I had used dnscrypt-proxy since it supports DoH as well.
You mean, you're running a DoT proxy?
No, DoH (DNS-over-HTTPS). I'd also previously set up a DoT proxy for use on my phone (since Android only supports DoT) but I decided to do something else for that.
So will HTTPS sites actually open in HTTPS now? It's the one thing that annoys the hell out of me since switching back to FF.
You can set Firefox to just do that for everything:
https://support.mozilla.org/en-US/kb/https-only-prefs
Chrome has a similar option here:
https://support.google.com/chrome/answer/10468685#https-only-mode
It's already on. The problem is going to a HTTPS site gives the "this site isn't actually secure, would you like to open it in HTTP instead?" And doesn't actually load the sites, which I know work, in HTTPS.
Like this:
This site (SNAP homepage) works in HTTPS just fine on Chrome.
Their webserver is probably misconfigured I think?
Chrome does a bunch of stuff in the background (trying no www, with www, etc) to try and get you to the https website, which firefox doesn't. It's a reason I like firefox as a developer, makes it super obvious when you've messed something up
I sometimes get this too. It's a bit annoying on mobile (not happening on desktop), but I often just need to reload the page.