Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Encrypted SNI Comes to Firefox Nightly

blog.mozilla.org

Post reply on HN
Print view View original

71–80 of 155 posts

Re: Encrypted SNI Comes to Firefox Nightly

#71

Post by phaer »

tombrossman wrote: post #54
mholt wrote: post #27

So what's the plan for when IPv6 gains more adoption and we don't need SNI as much since every site can have its own public IP address (thus making tracking easier, subverting the benefits of encrypted SNI). Do you think encrypted SNI and NAT will become preferred to using IPv6 for routing because of the privacy benefits of ESNI (either real or imagined, depending on who you trust, since this seems to be relying on c…

Interesting that you mention the privacy risk of tracking, as this[0] just appeared in my Twitter feed at about the same time I was reading HN. "Tracking Users across the Web via TLS Session Resumption"[1]. A snippet from the abstract: "Our results indicate that with the standard setting of the session resumption lifetime in many current browsers, the average user can be tracked for up to eight days. With a session r…

The links to the full paper in your second link led me to a 404 page. Found it here: https://svs.informatik.uni-hamburg.de/publications/2018/2018...

looks interesting, thanks!

Re: Encrypted SNI Comes to Firefox Nightly

#72

Post by the8472 »

eridius wrote: post #68
vetinari wrote: post #61

Earlier quoted context omitted.

There isn't anything that would prevent the local resolver to talk upstream using DoH. Same privacy, minus cloud companies that try to insert themselves as middleman.

DOH does not rely on cloud companies. The requirement for DOH has nothing to do with cloud companies "try[ing] to insert themselves as middleman". You certainly could argue that ESNI should be used even if DNS isn't done over DOH, in case you trust the network path to your recursive resolver and you trust the recursive resolver itself to be using DOH, but that also has nothing to do with cloud companies. I admit I'm…

> Ideally, using an OS-level resolver would have a way to tell the browser that the recursive resolution was encrypted

A simple flag to configure this would have done the job. I don't like how browsers are pretending that they have security needs that are special compared to any other application and thus need to pull in the whole network stack and bypass the OS on everything.

It causes duplicate effort if you want to secure your whole network instead of only the browser. It also limits technology choice. I'm forced to use DoH even though there are other options.

Re: Encrypted SNI Comes to Firefox Nightly

#73

Post by [deleted] »

cremp wrote: post #34
drb91 wrote: post #21

Earlier quoted context omitted.

DNS over HTTPS is still handled at the OS level? Related, it should be possible to have “correct” dns in userland that behaves as you describe sans falling back to the system resolver. In my understanding the whole point of DNS over https is to avoid the DHCP assigned DNS address (and of course encrypt) Finally, I’m pretty sure Firefox at least does its own dns caching. I’ve had to force reload to pick up dns changes…

DoH isn't done by the OS. But that's my point. In order to use DoH, you have to (purposefully) use an extension/browser addon/browser setting. As a system admin myself; if user applications started overriding the DHCP DNS that I give them, not only could intranet sites be broken, but I'd start having fights with users about it. Edit: Rather, not overriding but querying the DoH instead of the provisioned DHCP DNS. I'm…

[deleted]

Re: Encrypted SNI Comes to Firefox Nightly

#74

Post by vetinari »

eridius wrote: post #68
vetinari wrote: post #61

Earlier quoted context omitted.

There isn't anything that would prevent the local resolver to talk upstream using DoH. Same privacy, minus cloud companies that try to insert themselves as middleman.

DOH does not rely on cloud companies. The requirement for DOH has nothing to do with cloud companies "try[ing] to insert themselves as middleman". You certainly could argue that ESNI should be used even if DNS isn't done over DOH, in case you trust the network path to your recursive resolver and you trust the recursive resolver itself to be using DOH, but that also has nothing to do with cloud companies. I admit I'm…

DoH by itself does not, but the way it is getting implemented, most users will just happen to be dependent on them. That's why I wrote that.

Instead of pushing this functionality into OS resolvers and standalone resolvers used by networks, it is being pushed into commonly used applications, with cloud companies providing the other end by default.

ESNI doesn't require DoH, but there's no point of using it without one, if your network can check the DNS records you are asking for, and then check the ecrypted SNI against it (it will have the same key you are using to encrypt, so it can do the same and match).

Some resolvers (systemd-resolved, ducks and hides) do use custom API to attach properties to responses. That was the only way to get DNSSEC status, so it can be reused to indicate upstream protocol too. However, not many applications use that, they rely on standard gethostbyname(), which doesn't provide anything similar.

Re: Encrypted SNI Comes to Firefox Nightly

#75

Post by [deleted] »

cremp wrote: post #34
drb91 wrote: post #21

Earlier quoted context omitted.

DNS over HTTPS is still handled at the OS level? Related, it should be possible to have “correct” dns in userland that behaves as you describe sans falling back to the system resolver. In my understanding the whole point of DNS over https is to avoid the DHCP assigned DNS address (and of course encrypt) Finally, I’m pretty sure Firefox at least does its own dns caching. I’ve had to force reload to pick up dns changes…

DoH isn't done by the OS. But that's my point. In order to use DoH, you have to (purposefully) use an extension/browser addon/browser setting. As a system admin myself; if user applications started overriding the DHCP DNS that I give them, not only could intranet sites be broken, but I'd start having fights with users about it. Edit: Rather, not overriding but querying the DoH instead of the provisioned DHCP DNS. I'm…

[deleted]

Re: Encrypted SNI Comes to Firefox Nightly

#76

Post by vetinari »

zamadatix wrote: post #70
vetinari wrote: post #67

Earlier quoted context omitted.

I'm concerned mostly with 2, but in small businesses category. Many of them do not have proxy, SSL intercept or MDM (they manage their computers using plain old AD, plus some BYOB devices), and having to get one significantly ups the ante for them.

They've always had to get one if they wanted the security/monitoring, this just makes an implementation of how to get around lazy security a standard.

However, neither of them is fully transparent or autoconfigurable, especially for users that roam among networks. Local DNS resolver, while not 100% bulletproof, did the job acceptably.

Re: Encrypted SNI Comes to Firefox Nightly

#77

Post by eridius »

vetinari wrote: post #74
eridius wrote: post #68

Earlier quoted context omitted.

DOH does not rely on cloud companies. The requirement for DOH has nothing to do with cloud companies "try[ing] to insert themselves as middleman". You certainly could argue that ESNI should be used even if DNS isn't done over DOH, in case you trust the network path to your recursive resolver and you trust the recursive resolver itself to be using DOH, but that also has nothing to do with cloud companies. I admit I'm…

DoH by itself does not, but the way it is getting implemented, most users will just happen to be dependent on them. That's why I wrote that. Instead of pushing this functionality into OS resolvers and standalone resolvers used by networks, it is being pushed into commonly used applications, with cloud companies providing the other end by default. ESNI doesn't require DoH, but there's no point of using it without one,…

Most users will just happen to be dependent on cloud providers for DoH not because of anything inherent to DoH, but because at the moment only cloud providers are offering DoH-enabled resolvers. If you don't like this, then instead of decrying the usage of DoH, you should be pushing for more DNS providers to offer DoH.

I do agree that pushing DNS functionality into apps instead of the OS level is suboptimal, and I certainly hope that, if Firefox proves that DoH works well, it will be adopted by the major OS's (along with a way to query the OS resolver to check if it's using DoH or not) so that all apps can benefit from it instead of just web browsers that reimplement DNS.

Of course, IIRC Chrome at least (not sure about Firefox) has already been implementing DNS resolution itself for a long time rather than relying on the OS resolver, so the idea of a web browser doing DNS directly instead of relying on the OS is not a new one. I'm not sure why Chrome does this though.

Re: Encrypted SNI Comes to Firefox Nightly

#78

Post by tialaramex »

AndyMcConachie wrote: post #38
the8472 wrote: post #25

Earlier quoted context omitted.

It's even worse. To use ESNI you need DOH. To use DOH you need a resolver with a server certificates, which is kindly offered by the same cloud providers. So now all your base are belong to cloudflare.

It's even worse because they talk like ESNI is some kind of standard, but there's only been a single draft at the IETF written by a Mozilla employee, and that draft is still at version 1. Calm down Mozilla, maybe other people would like to comment on the design before you go and implement it? Doing it like this is a great way to end up in interopeability hell down the road when different parties have implemented diff…

> but there's only been a single draft at the IETF written by a Mozilla employee

I can see why it might look that way, but actually draft-ietf-tls-esni-01 is the third draft of this document, and has been co-written by at least four named authors including Chris Wood at Apple. Also that "Mozilla employee" was one of the Working Group chairs.

draft-ietf-tls-esni-01 was preceded by draft-ietf-tls-esni-00 (it is usual for early drafts to have zero zero versions)

draft-ietf-tls-esni-00 was preceded by draft-rescorla-tls-esni which was Eric Rescorla's first write-up of this idea

Finally, though this document didn't exist twelve months ago, the "issues and requirements" document did. This document imports the thinking behind that document, it just provides an implementation and now Firefox is testing it.

The reason for the name change is a thing called "adoption". The TLS Working Group agreed by consensus to adopt this piece of work, rather than it just being independent stuff by a handful of people who coincidentally were working group members. When that happens the draft's name changes, to reflect the adoption (removing a single person's name) and sometimes to use more diplomatic naming (e.g. the "diediedie" draft got a name that didn't tell TLS 1.0 to "die" any more when it was adopted).

Re: Encrypted SNI Comes to Firefox Nightly

#79

Post by dewiz »

mholt wrote: post #27

So what's the plan for when IPv6 gains more adoption and we don't need SNI as much since every site can have its own public IP address (thus making tracking easier, subverting the benefits of encrypted SNI). Do you think encrypted SNI and NAT will become preferred to using IPv6 for routing because of the privacy benefits of ESNI (either real or imagined, depending on who you trust, since this seems to be relying on c…

I'd expect proxies, CDNs, VPNs to become a common setup, although we'd have to trust these service providers not to track our traffic. TOR might be a better option for privacy, doubtful if that will ever succeed on large scale though.
Post reply on HN