this post was submitted on 03 Oct 2023
241 points (97.3% liked)

Technology

59421 readers
3364 users here now

This is a most excellent place for technology news and articles.

Our Rules

  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots

founded 1 year ago
MODERATORS
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
241
Firefox rolls out ECH enabled by default in 118 (blog.mozilla.org)
submitted 1 year ago by [email protected] to c/[email protected]
18 comments fedilink hide all child comments
 

ECH (encrypted client hello) is going or get enabled by default (already existed in a hidden setting) with version 118.

This page about the version explains a bit better ECH https://support.mozilla.org/fr/kb/understand-encrypted-client-hello

Tho it is still a bit confusing.

From what I understand there is the DNS query > the dns servers sends back an IP. This DNS query can be encrypted with DoH (or DoT?, it seems only DoH from the post).

Then there is a handshake with the website where the website informations can be leaked, and that can be encrypted by ECH (if the website supports it).

Then after that there is a tls connexion established between the website and the user.

The part where I'm confused is : can ECH be used without DoH? If yes that would mean that I can use a DoH capable software and not have to configure it into Firefox? (ex: Nextdns + yogadns)

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 25 points 1 year ago (2 children)

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.

[–] [email protected] 18 points 1 year ago* (last edited 1 year ago)

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.