Or we finally switch to IPv6
where we don't need ugly hacks like SNI.
Over the weekend, at the IETF Hackathon in Montreal, Canada, software engineers from Apple, Cloudflare, Fastly and Mozilla made some progress toward closing a privacy gap affecting network communications. The programmers built an preliminary implementation of a privacy-oriented draft protocol called Encrypted Server Name …
That would be ideal, since IPv6 handles multiple IPs per host very gracefully. Unfortunately even if everyone dual-stacked their servers tomorrow IPv4 would still be with us a long time. Many organizations that have very large v4 allocations haven't even started deploying IPv6, because address exhaustion isn't a pain point for them yet. (The university I work for, which has an entire class B for their wired network, is in this category. I think they should deploy IPv6 anyway, but it's not my call.)
I doubt it. For starters a typical IPv6 delegated prefix is a /56. There are about 72 quadrillion of these, so it would take us a while to get through them.
A /56 is a pretty decent amount of address space, so a typical home or small business customer isn't going to care about buying anything bigger. In fact IPv6 mostly makes the whole concept of a netmask automatic and invisible to end users. (Besides, what's this idea of ISPs needing "selling points" other than "we're the ISP that serves your address, you'll take what we give you"?)
After further thought, I think you are right and SNI isn't necessary over IPv6 -- but it may not be for the reason you might think.
With IPv6 and every device having its own globally unique address, snooping on the packet for SNI would be pointless because the unique IPV6 address would have already given away any of the information you would have otherwise gained by snooping on the host header.
Congratulations, you just gave me another reason to dislike IPv6, and I didn't realize that was possible.
The fact IPv6 doesn't have IP address restrictions make you hate it more?
There's absolutely no reason why you can't share IP6 addresses amongst many different hosts, but you know that.
In fact, it was only because of the lack of IP4 addresses that SNI became a thing, but you know that too.
Anyway, SNI is getting a bit of an unfair rap here, as before SNI, the requirement for unique IPv4 addresses (combined with port if you want to be pedantic) meant that you could tell a virtual server just by looking at the IP address.. SNI having the host in the clear therefore didn't compromise on any of the security at the time.
You certainly *can* pile lots of sites onto one IPv6 address and use a hack like SNI. You just don't necessarily have to. People who run privacy-conscious services will probably want to stick with an SNI-like scheme, and most other people probably will out of force of habit. (One address per server is pretty ingrained now, and it's so convenient for administration to just point a bunch of CNAME records at one A record.)
For that matter, given the large address space in even a minimum IPv6 allocation, there's no reason you can't round-robin to lots of different ones and effectively force a choice between blocking the whole prefix or not blocking at all.
effectively force a choice between blocking the whole prefix or not blocking at all
Right, and the censoring nation-states will block the whole prefix. Why wouldn't they?
So IPv6 utterly fails to solve the original problem, and indeed makes things easier for the attacker (the state, in this case).
I've seen this mentioned a few times, including in this article, that SNI visibility can be used by DNS providers for censorship. I question the accuracy of that statement.
I fully get that a "man in the middle" can listen and censor, but that is someone in the middle, not the DNS provider. SNI visibility, or lack thereof, has no impact of the ability of a DNS provider to censor.
First, when talking about SNI we are generally talking about requests to the web server, and those do not go to the DNS server.
Second, in order to resolve the request the DNS provider has to know the host name. DNS protocol transmits the hostname in the clear, but even if the protocol was enhanced to send it encrypted to avoid a man-in-the-middle attack the DNS server would still have to be able to decrypt the packet in order to resolve or forward -- and either way it would have the hostname and could do whatever filtering or censorship desired by the operators.
I get that -- but that isn't what the article says. Encryption between you and the DNS provider is a good thing, but at the provider level censorship can still occur and SNI visibility has nothing to do with it one way or the other.
It works like this:
This is the current system, assuming I live in China:
Me: [to DNS server that is not censored] I'd like the address to www.chinadoesntlikeme.com please.
DNS: Here you go.
Me: [to internet system run by China] I'd like to contact the server found at x.x.x.x (insert xxxx:xxxx:xxxx:... if you want) and request the page located at www.chinadoesntlikeme.com/ please.
Me: [to internet system run by China] I'd like to contact the server found at x.x.x.x and request the page located at /
Server at x.x.x.x: Welcome to amazon AWS. You can get to this server; just not the sites China doesn't like.
This is the replacement system:
Me: [to DNS server that is not censored] I'd like the address to www.chinadoesntlikeme.com please.
DNS: Here you go.
Me: [to internet system run by China] I'd like to contact the server found at x.x.x.x (insert xxxx:xxxx:xxxx:... if you want) and request the page located at "Q2Vuc29yc2hpcCBpcyB0ZXJyaWJsZS4="/ please.
China: Oh no. We need to let people get to the server, because there are plenty of useful things there. But maybe they're going to get something we don't want them to have. What can we do?
China: We'll let you through for now.
That's how it's supposed to work. However, I'm doubtful. I haven't read the system, so I am not familiar with the way the encryption is being used. However, I have to ask the following questions, and if I actually get the time to read about the system then hopefully I'll find the answers.
1. Why can't China do the encryption themselves and find out what the request for a site they don't like would look like? That implies that it changes in such a way that the originating computer knows how to send such a request, but the system China's using doesn't.
2. Will China change over to just retrieving the site requested, then comparing it to a request that they send. They could just compare them and if they are the same or similar (random junk produced to look different) they could decide to not send the page to the machine.
3. Could China block all these encrypted requests such that only standard requests get through? Is there a way to force them to accept it?
4. Does China have enough power to prevent the big cloud providers from using this? They have enough power for apple to crash their own phones when the Taiwanese flag is seen, AWS to give root accounts on all Chinese servers to a third party, and similar for pretty much every company that does business there. I assume they'd find a way for such a system not to be installed.
Scenarios 1 and 2 are only possible if China has the server's certificate and private key. Now, even without those things China could always MITM and provide their own certificate to the client, but that would be extremely obvious and would create lots of breakage. 3 would also break lots of stuff since so much of the web uses HTTPS now.
4 is somewhat mitigated by the fact that the server isn't necessarily one in China itself. The goal here is to make it harder to block requests at the network level without lots of collateral damage. It makes it more difficult (although not impossible) to run a "Great Firewall" type censorship system.
> Why can't China do the encryption themselves and find out what the request for a site they don't like would look like?
The way asymmetric encryption usually works is that the client would generate a random encryption key to use with a symmetric encryption algorithm (like AES). Think of this like a randomly chosen password, only with massively better entropy. This key is then encrypted with the public key (eg RSA), so only the server with the private key can derive the randomly chosen key and can then derive the content. So each request to chinadoesnotlikeme.com will look different.
So points 1 and 2 aren't a problem on this account. The real problem is knowing who owns the private key that corresponds to the public key you have just used.
> Could China block all these encrypted requests such that only standard requests get through?
They almost certainly would.
> Does China have enough power to prevent the big cloud providers from using this?
Certainly within their borders.
There's a pretty big elephant that they've managed to move if they've got this far, but I'm not following how they've solved it.
Let's rewind, why SNI? Well in HTTPS, the server needs to provide it's certificate in the serverhello message. This certificate needs to match the hostname that the client requested or it can't be trusted.
In days of old, you would bind an IP address and port to a given site, and that was how you knew which certificate to return. Port for a website was in practice restricted to 443 because no one wants colons in their URL, so you basically needed a dedicated IP address per site. That's expensive, not to mention equally easy to block undesired hosts by their IP address alone (reverse DNS lookup).
Fast forward to SNI, and the clienthello message now indicates the hostname that the server will need. Now the server can send down the right certificate, so everyone is happy, save for the fact that the clienthello is letting world+dog know about the host, and here we arrive at the elephant.
In order to encrypt, we need to either:
(a) have pre shared a key; or
(b) use the server's public key so that only that server can determine what host we want
Clearly a is out. The whole point of the TLS handshake is to get such a session key so the much faster symmetric encryption can be used (AES). So now we are talking about (b). So what is the server's public key? How can you be sure that the key provided to you doesn't belong to Mallory?
There's a hole in my bucket ....
Is it wrong of me to point out that in the time it took to compose that post, you probably could have simply read the ESNI draft?
Anyway, from the draft:
First, the provider publishes a public key which is used for SNI encryption for all the domains for which it serves directly or indirectly (via Split mode). This document defines a publication mechanism using DNS, but other mechanisms are also possible.
Retrieving the key via unsecured DNS is clearly problematic (though it does shift the attack to a different branch, which has some value), but there's DNSSEC or, as the draft says, other possible mechanisms.
Problematic is one way to put it. Not actually solving the elephant is another.
Censorship bypass requires that the censoring authority cannot know the private key. And if they intercept 22.214.171.124 (for example) then the public key given to the client doesn't have to be the real server's one. The terrific firewall™ can simply MitM the client hello and decide whether to drop your packets; you just used their key.
The headline implies that this is a SNI fix, whereas this solution kicks off to the never never the actual magic needed to solve it.
Biting the hand that feeds IT © 1998–2022