this post was submitted on 05 Oct 2023
300 points (98.1% liked)

Firefox

17937 readers
36 users here now

A place to discuss the news and latest developments on the open-source browser Firefox

founded 4 years ago
MODERATORS
all 33 comments
sorted by: hot top controversial new old
[–] [email protected] 28 points 1 year ago (1 children)

I'm going to wait for someone more knowledgeable on this subject to come by and correct me, but this seems pretty cool to me.

[–] [email protected] 21 points 1 year ago (1 children)

As someone knowledgeable on the subject, this was my journey:

Mozilla: "While HTTPS encryts web page contents, many middlemen can still see the URL of the sites you visit."

Me: "Yes, we know this is a problem. It has been for a long time. But if you're adding some kind of complex new solution, it's going to cause issues for..."

Mozilla: "We added public key encryption to DNS."

Me: "Oh shit, that's really smart, and it'll just work."

The brilliance of this move is public key encryption is old and widely supported and DNS is old and universally supported. I think we will see broad support roll out quickly on this one (at least compared to glacial scale of changes across the Internet.)

[–] [email protected] 3 points 1 year ago

This should also be done for CA keys. If ACME can make DNS ownership the source of trust, just let me stuff my own root CA cert in a DNS record and skip the middle man.

[–] [email protected] 16 points 1 year ago (5 children)

If a packet is traversing an ISP's network the ISP should have to know where it is coming from and where it is going, right? So even if you "encrypt the first hello" packet, the ISP would still know where it was routed, right?

I'll freely admit I have only a very basic (and likely outdated) understanding of IP networking, but I don't see how this protects my browsing habits from my ISP. Even if they can't understand my "hello" to lemmy.ml, they still know I'm talking to lemmy.ml's IP address about something.

What am I missing?

[–] [email protected] 22 points 1 year ago

Your ISP is mostly going to be seeing AWS, Azure, GCP, Cloudflare, etc IP addresses.

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

They would know you’re talking to that IP, not necessarily lemmy.ml. It is very common for multiple sites to be hosted on the same ip. The reason SNI exists is so the browser can tell the server which site it was looking for in an encrypted session. If it is 1:1 then it would be true.

[–] [email protected] 7 points 1 year ago (2 children)

If I understand correctly, someone other than your ISP could see the name of the website, since it isn't encrypted. I think it would bounce through several servers that could possibly read the data.

[–] [email protected] 4 points 1 year ago (1 children)

This makes it so that your ISP doesn't see the actual name of the server/site you're communicating with, only the IP address. Without Encrypted Hello they're able to see both.

[–] [email protected] 5 points 1 year ago (1 children)

I would think that an IP address tells you the domain name by doing a simple DNS lookup.

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

In many cases you can, but there's never a guarantee that a given IP address will have reverse DNS records configured for resolve it into. On top of that, if it's a major site it's likely hosted behind a content delivery network that may a share a single IP address across thousands or even millions of completely unrelated servers. Cloudflare does some pretty interesting stuff with that approach: https://blog.cloudflare.com/cloudflare-servers-dont-own-ips-anymore/ edit: bad at typing

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

Cloudflare fronts much of the internet, so all your ISP would see is that you connect to cloudflare, not which site you actually connect to.

In fact this was a big reason cloudflare and Amazon were angry with the signal foundation, for using domain front running, using the same trick in fascist countries to still be able to talk to signal servers

[–] [email protected] 7 points 1 year ago (1 children)

When you type in www.example.com, you request the IP of the server for that site using a DNS server. The DNS server sends you the IP and then you connect to it. If they are using https for DNS it means that your ISP or onlookers have to reverse which domain you're accessing from that IP to know that you're accessing www.example.com.

At least I think that's what is happening.

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

The problem doesn’t involve DNS, it’s after that step.

SNI is when your browser connects to the server. A server may host multiple sites on the same IP, so your browser says “I would like to open an encrypted session to lemmy.ml”. It does this in the clear. If it was an unencrypted http site it would be in headers, but in https those headers aren’t passed until after the encrypted session is set up, so there has to be some way for the server to know the specific site. Anybody listening to SNI traffic knows the exact site you connected to, even if there are hundreds at that ip.

This adds a public key to the DNS record, so your browser is able to encrypt that initial hello message before the https session is encrypted. Someone listening might see something like “ECH: randomgibberish” but the server can decrypt it.

[–] [email protected] 5 points 1 year ago (1 children)

Yeah I think it has the same limitations that pretty much anything not through a vpn has because you still have to tell your isp where to send the data. Your isp will still see some things, even if it’s encrypted (metadata, DPI, habits, and things beyond my knowledge). This sounds like a step in the right direction for the majority of people though, even if it’s minor.

I kind of see it like differentiating between them seeing lemmy.ml via this vs lemmy.ml/thing-i-want-private/peronal.html without it, but I could be wrong about that.

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

HTTPS already prevents them from knowing exactly what content you’re looking at. Hiding SNI prevents them from knowing exactly what site you are connecting to via HTTPS.

They can still figure that out if you’re using unencrypted DNS or if there is a 1:1 IP to rDNS mapping though.

[–] [email protected] 8 points 1 year ago (2 children)

Does this rely on DOH? Seems like if I’m running my own recursive DNS that this won’t apply to me.

[–] [email protected] 2 points 1 year ago

Your request still has an unencrypted client hello, so you wasted all that DoH effort by sending the website name in clear text

[–] [email protected] 7 points 1 year ago (2 children)

Ok, but how many servers support it?

[–] [email protected] 15 points 1 year ago (1 children)

All sites that are proxied through Cloudflare, even free tier. So it's safe to say half of internet are supported ECH already.

[–] [email protected] 4 points 1 year ago

That's a low bar. I can't even access most of those sites due to misconfiguration of the antibot settings.

I'm mostly asking for the websites that I run, which are not behind CF.

[–] [email protected] 4 points 1 year ago

All of Cloudflare supports it

[–] [email protected] 6 points 1 year ago (1 children)

ECH is designed to interoperate with these practices and respect the existing DoH opt-outs in Firefox

This makes no sense. Just because I don't want to bypass my local DNS server it shouldn't leave my TLS Hello packets unencrypted.

[–] [email protected] 4 points 1 year ago

I had missed this originally, very disappointing choice by Mozilla.

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

Rare Mozilla Win.
Imagine if they did stuff like this every time.