6 ms·

There seems to be little point of doing this, in my opinion, when SNI doesn't secure the hostname.

by gnode 8y ago

zzzcpan 8y ago
Agreed, SNI and DNS need to be fixed together, not separately. And definitely without centralized services, like Cloudflare. Otherwise why not just go all the way with centralization and provide secure proxy for everyone in the browser.
- phicoh 8y ago
  They are completely independent protocols, with their own issues in this area. For the DNS, the specification for DNS over TLS is almost trivial. DNS over HTTPS is a bit more tricky because their are more possibilities, interactions with HTTPS, etc. But still not very hard from a protocol point of view. Operationally, DNS over TLS/HTTPS is mostly unknown. So it will take quite a bit of time before it is well know how to actually run that as a service at scale. Encrypting the SNI in TLS is mostly the other way around. Fixing that has significant impact on the protocol. There is no point in making very complex changes in TLS, which is already a tricky protocol without the DNS community committing to provide DNS over TLS/HTTPS at scale. At the same time, securing traffic between a DNS stub resolver and the recursive resolver prevents are lot of middle box issues (but also creates a completely new set of issues). So it is worth deploying the even if TLS still leaks the SNI.
  - zzzcpan 8y ago
    They cannot be independent if actual privacy is concerned. At least sharing a threat model that touches both layers.
    - phicoh 8y ago
      They are mostly independent. Your privacy loss is by and large the sum (or max) of the privacy loss caused by DNS and TLS individually. For TLS, the threat model is relatively simple: only an on path attacker has access to a plaintext SNI. In the context of route hijacks, 'on path' is not as simple as it sounds, but route hijacks are relatively rare. For DNS the situation is much more complex. You have to consider not only traffic between stub resolver and recursive resolver, but also between recursive resolver and the various auth. resolvers. At the end of the day, you need to consider all places where information is leaked and whether you want to do something about that or not. And in that sense DNS is independent from TLS.
- gnode 8y ago
  Ironically, some amount of centralisation can improve privacy. Security is about confusion and diffusion; to get lost in a crowd you need to not be differentiated, and to not be the whole crowd. Encrypted SNI would mean ISPs could tell you were contacting Cloudflare servers, but not which of the many hosted websites you were requesting (assuming you also plug the DNS privacy gap too).
arghwhat 8y ago
You can't wiretap the DNS and obtain data about all site visits from there. That's really quite nice. It still means that your ISP or a wiretap on your own internet pipe can check your browsing activity by monitoring SNI's, but then again, they can also figure that out for a lot of sites by just checking the IP. Then you could argue that all sites should use CDNs to hide this, but then you open the argument of whether the internet should be centralized or decentralized. Encrypted SNI would be nice, but are tricky (wouldn't work well in multi-tenant setups), and those that can sniff the SNI probably know where you were going anyway.
st3fan 8y ago
You have to start somewhere. Security is the sum of all parts. This is a small part, but it may have a big impact already. I'm sure SNI is next on the list, it will just take a bit longer. Until then, let's harden other parts of the infrastructure.
- QasimK 8y ago
  I was curious about TLS1.3’s attempt to encrypt SNI, and found that it is genuinely a hard problem. The best solution seemed to be to use a proxy/fronting service, but that isn’t the ideal solution.
- tialaramex 8y ago
  Encrypted SNI is very hard. The TLS working group agreed a problem statement, seeing out what should be achieved, but they haven't found any viable way forward on achieving that. If I'm in a city square and I want to tell Bob something, but I refuse to let anybody know that I want to communicate with Bob, it's hard to see what I can do. Bob has no way to know I'm even trying to contact him, so he can't help.
  - zzzcpan 8y ago
    > If I'm in a city square and I want to tell Bob something, but I refuse to let anybody know that I want to communicate with Bob, it's hard to see what I can do You can tell a few people near you that "someone" wants to tell something to Bob and an answer from Bob. They tell people near them and so on, until it reaches Bob. He then answers and tells people near him, they tell those who told them and so on, until the answer is delivered back to you. And since no one can hear what people tell each other, no one can assume that "someone" is you and not someone else talking to you in secrecy, many connections away from you. Think overlay peer-to-peer networks. But the minimum viable threat model is ISP appliances that do classification and identification of traffic, both passively and actively, like trying to probe for protocols and hostnames. If you are not targeting them, you are effectively doing nothing, but pretend privacy PR. Which is the case with Cloudflare's DNS.
  - falcolas 8y ago
tialaramex 8y ago
SNI doesn't encrypt the hostname but in TLS 1.3 it does secure it against middleboxes. If a MitM tries to alter the SNI then the connection fails. TLS 1.3 also encrypts the server certificate. So if you want to send bonus SNI but get back real certificates that's just a matter between client and server. The use case for Encrypted SNI remains sketchy. If I am the secret police of some authoritarian nation, who would block diebartdie.example why wouldn't I instead block the IP addresses of servers offering diebartdie.example? Only because it causes collateral damage? But why do I care, teach them not to associate with my enemies.
- gnode 8y ago
  > Only because it causes collateral damage? But why do I care Because the collateral damage may not be worth it. The website a handful of dissidents use may not be worth blocking everything running on Cloudflare for all your citizens, for instance.
jedisct1 8y ago
Encrypted SNI for TLS 1.3 is being worked on: https://github.com/ekr/draft-rescorla-tls-esni/blob/master/draft-rescorla-tls-esni.md https://github.com/ekr/draft-rescorla-tls-esni/blob/master/d...
LudoA 8y ago
Doesn't DNScrypt (DNS over HTTPS) fix this issue?

There seems to be little point of doing this, in my opinion, when SNI doesn't secure the hostname.

by gnode 8y ago

There seems to be little point of doing this, in my opinion, when SNI doesn't secure the hostname.

Agreed, SNI and DNS need to be fixed together, not separately. And definitely without centralized services, like Cloudflare. Otherwise why not just go all the way with centralization and provide secure proxy for everyone in the browser.

phicoh 8y ago
They are completely independent protocols, with their own issues in this area. For the DNS, the specification for DNS over TLS is almost trivial. DNS over HTTPS is a bit more tricky because their are more possibilities, interactions with HTTPS, etc. But still not very hard from a protocol point of view. Operationally, DNS over TLS/HTTPS is mostly unknown. So it will take quite a bit of time before it is well know how to actually run that as a service at scale. Encrypting the SNI in TLS is mostly the other way around. Fixing that has significant impact on the protocol. There is no point in making very complex changes in TLS, which is already a tricky protocol without the DNS community committing to provide DNS over TLS/HTTPS at scale. At the same time, securing traffic between a DNS stub resolver and the recursive resolver prevents are lot of middle box issues (but also creates a completely new set of issues). So it is worth deploying the even if TLS still leaks the SNI.
- zzzcpan 8y ago
  They cannot be independent if actual privacy is concerned. At least sharing a threat model that touches both layers.
  - phicoh 8y ago
    They are mostly independent. Your privacy loss is by and large the sum (or max) of the privacy loss caused by DNS and TLS individually. For TLS, the threat model is relatively simple: only an on path attacker has access to a plaintext SNI. In the context of route hijacks, 'on path' is not as simple as it sounds, but route hijacks are relatively rare. For DNS the situation is much more complex. You have to consider not only traffic between stub resolver and recursive resolver, but also between recursive resolver and the various auth. resolvers. At the end of the day, you need to consider all places where information is leaked and whether you want to do something about that or not. And in that sense DNS is independent from TLS.
gnode 8y ago
Ironically, some amount of centralisation can improve privacy. Security is about confusion and diffusion; to get lost in a crowd you need to not be differentiated, and to not be the whole crowd. Encrypted SNI would mean ISPs could tell you were contacting Cloudflare servers, but not which of the many hosted websites you were requesting (assuming you also plug the DNS privacy gap too).

arghwhat 8y ago

You can't wiretap the DNS and obtain data about all site visits from there. That's really quite nice. It still means that your ISP or a wiretap on your own internet pipe can check your browsing activity by monitoring SNI's, but then again, they can also figure that out for a lot of sites by just checking the IP. Then you could argue that all sites should use CDNs to hide this, but then you open the argument of whether the internet should be centralized or decentralized. Encrypted SNI would be nice, but are tricky (wouldn't work well in multi-tenant setups), and those that can sniff the SNI probably know where you were going anyway.

st3fan 8y ago

You have to start somewhere. Security is the sum of all parts. This is a small part, but it may have a big impact already. I'm sure SNI is next on the list, it will just take a bit longer. Until then, let's harden other parts of the infrastructure.

QasimK 8y ago
I was curious about TLS1.3’s attempt to encrypt SNI, and found that it is genuinely a hard problem. The best solution seemed to be to use a proxy/fronting service, but that isn’t the ideal solution.
tialaramex 8y ago
Encrypted SNI is very hard. The TLS working group agreed a problem statement, seeing out what should be achieved, but they haven't found any viable way forward on achieving that. If I'm in a city square and I want to tell Bob something, but I refuse to let anybody know that I want to communicate with Bob, it's hard to see what I can do. Bob has no way to know I'm even trying to contact him, so he can't help.
- zzzcpan 8y ago
  > If I'm in a city square and I want to tell Bob something, but I refuse to let anybody know that I want to communicate with Bob, it's hard to see what I can do You can tell a few people near you that "someone" wants to tell something to Bob and an answer from Bob. They tell people near them and so on, until it reaches Bob. He then answers and tells people near him, they tell those who told them and so on, until the answer is delivered back to you. And since no one can hear what people tell each other, no one can assume that "someone" is you and not someone else talking to you in secrecy, many connections away from you. Think overlay peer-to-peer networks. But the minimum viable threat model is ISP appliances that do classification and identification of traffic, both passively and actively, like trying to probe for protocols and hostnames. If you are not targeting them, you are effectively doing nothing, but pretend privacy PR. Which is the case with Cloudflare's DNS.
- falcolas 8y ago

tialaramex 8y ago

SNI doesn't encrypt the hostname but in TLS 1.3 it does secure it against middleboxes. If a MitM tries to alter the SNI then the connection fails. TLS 1.3 also encrypts the server certificate. So if you want to send bonus SNI but get back real certificates that's just a matter between client and server. The use case for Encrypted SNI remains sketchy. If I am the secret police of some authoritarian nation, who would block diebartdie.example why wouldn't I instead block the IP addresses of servers offering diebartdie.example? Only because it causes collateral damage? But why do I care, teach them not to associate with my enemies.

gnode 8y ago
> Only because it causes collateral damage? But why do I care Because the collateral damage may not be worth it. The website a handful of dissidents use may not be worth blocking everything running on Cloudflare for all your citizens, for instance.

jedisct1 8y ago

Encrypted SNI for TLS 1.3 is being worked on: https://github.com/ekr/draft-rescorla-tls-esni/blob/master/draft-rescorla-tls-esni.md https://github.com/ekr/draft-rescorla-tls-esni/blob/master/d...

LudoA 8y ago

Doesn't DNScrypt (DNS over HTTPS) fix this issue?