Hacker News Reader

Comment by mholt | Hacker News Reader

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 centralized CDNs for adoption)?

Edit: I realize ESNI and IPv6 are orthogonal, however, I wanted to ask since I know that lack of IP space and using NAT/SNI are correlated.

View on HN

You could ignore the eSNI on the web server completely if you wished. But even on HTTP servers serving only a single IP it is still typical to only respond to requests targeting the correct hostname (i.e. direct IP requests are bounced).

There's numerous reasons to bounce direct (non-hostname) requests including:

- Discourage users visiting via the IP Address, adding that to favorites, sharing it, etc. Making it difficult/impossible to migrate.

- Make it harder for databases to associate that IP Address with your site (for user privacy).

- Security. Ignoring that several modern techniques don't even work with IP Addresses, it also stops someone taking over the IP after you migrate and stealing cookies associated with that address, etc.

Point being is, that SNI is useful on IPv6. It is useful on single web-site servers. It isn't going anywhere.

I understood the question wasn't whether SNI is useless, but whether its primary goal of making it difficult to track website connections is being at least partially subverted by IPv6.

>- Discourage users visiting via the IP Address, adding that to favorites, sharing it, etc. Making it difficult/impossible to migrate

That's not a reason to reject. That's a reason to issue a redirect. No regular user that would make the mistake of bookmarking an IP instead of a domain is going to know how to use an IP to get there in the first place.

>- Make it harder for databases to associate that IP Address with your site (for user privacy).

You're misunderstanding how these crawlers work. They don't just walk all IP addresses because that's a good way to get an abuse letter and because if there is no redirect to a domain they don't get the domain. These crawlers just follow links like any other and log the IPs they resolve to. The only way this helps user privacy is if there are no links to your site anywhere on the internet.

>No regular user that would make the mistake of bookmarking an IP instead of a domain is going to know how to use an IP to get there in the first place. System admins probably have caught up to this now, but a decade back I remember non-techy people doing just that. Turns out their sysadmins had blocked some social networks and people found out that you can still access the site using an IP address of their servers. The IP addresses themselves were spread across the office and many people ended up with bookmarked IP addresses. So yes, it could and has happened.

I think SNI will remain in fashion even after IPv6 is introduced globally. SNI works fine for plain IPv6 address.

If you run multiple websites on a single server for example you can move your server to another IP address / host / datacenter, update the IP address in your DNS settings and you're done. If you use IPv6 for this purpose, every domain and subdomain need to be configured with a new IP address and need a special line in the DNS config. This leads to administrative overhead, which leads to mistakes.

Unless someone writes a CLI tool that automatically sets it up for you.

More than that, why bother?

If I use SNI -- which at this point is fully supported on anything that matters -- I just have to setup all the hosting definitions and make sure my server can find all the certificates.

If I want to use one IP per site without SNI, now I have to also manually manage the mappings of IP-to-certificate for each host, and also be sure they're all synchronized with DNS.

More work, more potential for trouble, and no real benefit.

Certificates are tied to hostnames, and hostnames resolve to IPs. You could have a server with 50 IPv6 IPs, have a different hostname resolve to each one, and load all of the SSL certs onto the machine along with the appropriate webserver configs. You could then add IPs to the server and DNS without touching the certs. Or replace a cert without changing anything else. You don't need SNI in this scenario, you just have to ensure you add the new IPs to the server configs before updating DNS, so it will serve the correct default certificate.

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 resumption lifetime of seven days, as recommended upper limit in the draft for TLS version 1.3, 65% of all users in our dataset can be tracked permanently."

Not exactly looking forward to TLS1.3, it appears to be a move forward in security but with no (or worse) privacy benefits that I've seen so far.

[0]https://twitter.com/durumcrustulum/status/105293632402455757...

[1]http://front.math.ucdavis.edu/1810.07304

> with the standard setting of the session resumption lifetime in many current browsers

> seven days, as recommended upper limit

Do we fix this by changing that setting to a few hours?

Edit: the report discusses this: "The recommended upper limit of the session resumption lifetime in TLS 1.3 [19] of seven days should be reduced to hinder tracking based on this mechanism. We propose an upper lifetime limit of ten minutes based on our empirical observations"

Is this a configurable option in Firefox?

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!

I do not think most webservers will be set up with one IPv6 address per website. As is, most IPv6 enabled sites that share an IPv4 with another site and also share their IPv6 address with those same sites. Assigning one IPv6 address per site would add complexity for little benefit.

Does Apache or nginx still have issues with serving lots of ip's at once. I know a long, long time ago it could be a performance issue.

How long ago are we talking? Apache 1.3? That used to have a few nuances but it's now been superseded several times over. I didn't use 2.0 a whole lot but I don't recall it ever being an issue with 2.2 and we're onto yet another engine rewrite with version 2.4 (which has been available a few years now too).

> So what's the plan for when IPv6 gains more adoption

Our great great grandchildren will surely figure something out.

Right now > 30% of US traffic uses IPv6 so it's already happening.

> 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

Say sometimes I love to visit a very private website for my personal pleasure when I'm alone at night.

Without eSNI, when I type-in pornhub.com and hit enter, my buddy Bob who working for the ISP immediately knows and be very sure that I'm trying to accessing none other than pornhub.com. And then, with great confident, he greedily calling me for a live chat.

Bob is a ... special person. He might tell my mom about the pleasure thing, but not just that, he also secretly tracks my pleasure activities only to figure out the pattern using some sort of weird thing called machine learning, so he can show up in front of my door at the exact right time to share the pleasure with me.

I don't like that.

With eSNI, Bob only knows that I'm accessing 216.18.168.0. But when he tries to access the 216.18.168.0:80, he be greeted by a 403 error which says "Invalid Host".

A website may have many IP addresses, and an IP address can serve many websites. Because of that, now Bob can only know MAYBE I'm watching my little pleasure, oh wait, or maybe it's imworkingverylateatnight.com? He just can't be sure now.

If Bob works at your ISP, he could see the DNS queries before you even connect to the site. There’s work arounds for that as well but the average Joe isn’t going to set any of them up.

Of course. But what if DNS can also be encrypted?

You mean with DoH? Serviced for example from Googles public DNS servers?

Im more partial to DNS over TLS myself.

I have a great new idea! DNS over TLS Co-location Open Mesh. That way, we can all be back in the DOTCOM era

Maybe I'm misunderstanding, but isn't the point of the GP that as IPv6 takes over, eSNI becomes practically useless since it's possible for every site to have its own IP address? If I'm connecting to an IP address that only maps to one site, then Bob is going to be able to figure out what that site is.

You're right that eSNI is a nice to have (though years late) for IPv4, but I and the GP would like to know what we can do to protect our anonymity with IPv6.

I might be misinterpreting this, but on IPV6 do CDNs keep separate addresses for different sites? I suppose it would move things up a protocol level - instead of specifying it in HTTP we can specify it in IP. However, the key issue is CDNs here. In almost no other circumstances do different websites keep the same IPV4 address.

> In almost no other circumstances do different websites keep the same IPV4 address.

I have multiple domains hosted on my personal site. Similarly, facebook.com and facebook.co.uk could very well point to the same IPs.

ESNI doesn't solve for a future where ipv6 takes over and suddenly every site has a huge block of dedicated IPv6s for just that site/fqdn.

ESNI as it has been developed to essentially require two other components to work properly:

1) a large scale cdn 2) a trusted dns infrastructure (i.e. DNS-over-HTTPs or DNS-over-TLS).

So people are absolutely right that in distant future when IPv4 fronted sites go extinct, it may be possible that site hostnames can be correlated to a set of IPv6 address(s). ESNI doesn't and can't solve for that. I imagine that as the internet continues to become more and more centralized, a few large CDNs will host most (or very close to all) internet traffic through a few sets stabilized anycast addresses (thus obfuscating any individual hostname among many hundreds or thousands of other sites as they would all correlate to the same ip blocks).

That being said, I still don't understand why it's so important to have the SNI on the "outside" of the tunnel. Seems like we should have another layer before the symmetric key exchange where the sni is exchanged on its own.

Just because you'll have enough ipv6 addresses for every website doesn't mean you'll want to actually do that.

It's a lot of extra hassle to set up dozens of IPv6 addresses when (e)sni can do the same job.

Moreover, (e)sni has an advantage over using ip mapping; events if someone is snooping on your connection and can see that you are connecting to some ip address they won't be able to determine what site that might be.

If you are simply mapping IPs, they can visit that to see what you are visiting.

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.

After IPv6 adoption it can be made a legal requirement to have unique IPv6 address for every unique domain name.

Having AAA records be one-to-one would be a massive change to DNS.

The same problem exists with IPv4, and there are many ways to address it: Cloudfare, IPFS, Tor, web proxies, etc.

Problem is with IPv6 encrypted SNI won't mean anything because an IP address directly translates to a website so your ISP still knows what website you are on.

0/10. IPv6 with never be the front runner.

IPv6 will never gain universal adoption.

Nobody wants their home or their datacenter machines exposed to the whole Internet all the time.

NAT is a feature, not a bug.

That side effect of NAT is easily replaced with a simple firewall. Even today, many home routers have this capability already by virtue of running linux. Enabling it would be a pretty simple step for manufacturers.

NAT is not a firewall, it's a hack to keep ipv4 working today.

You need state tracking to build a masquerading NAT (or it won't know which machine to route reply packets to), and if you have state tracking, you can also build a stateful firewall, which will achieve the same thing.

Stateful firewalls still work, have always worked, and work the same in IPv6 as they do in IPv4. Having a public, globally-routable, unique address on your internal machine, whether that's an IPv4 address or an IPv6 one, doesn't mean that anyone can connect to it. It still has to go through your router. That router can be running a stateful firewall.

NAT is awful.

Hosters could play games with IPv6-hopping to make tracking/reverse association more resource-intensive. Their nameservers could even return different addresses for different regions. I doubt many will do that, then again hiding behind SNI never gave you any added anonymity in the first place unless you happend to end up on some shared reverse proxy in the first place.

Reply on news.ycombinator.com