4 ms·

Small bit of background: TLS typically works via per-hostname certificates. If you have only a single host on an end-point then no problem. But what if you wan

Small bit of background: TLS typically works via per-hostname certificates. If you have only a single host on an end-point then no problem. But what if you want to host two or more domains with different certificates on a single end-point? It's a problem. So Server Name Indication (SNI) was invented. In effect you send, in plain text, the hostname name you wish to contact to the end-point, who is then able to use that information to route the request. The correctly routed request can then utilize the right certificate. At the time this didn't have large security implications because unencrypted DNS was already leaking requests like crazy. But with DNS slowly getting more secure and TLS gaining a huge market share (<3 Let's Encrypt), SNI is starting to stand out as an "easy" way to spy on what someone is requesting. While IP Addresses themselves can be used for spying, encrypted DNS, protected SNI, and TLS all increase the cost and complexity of that spying, and make the results harder to trust (particularly on shared hosts or sites using a shared load balancing system). If encrypted SNI becomes a reality, it is a huge win against ISPs spying on us and selling our browsing histories.

dorfsmay 8y ago
Worded differently: With non-SNI TLS (traditional) the server name is only sent ONCE the connection is encrypted, you can have several severs by using Subject Alternate Names (SAN), with a de facto maximum of about a 100. All the names have to be in a single cert though, because at time of establishing the encrypted connection, there is no way to know which cert to use. With SNI, the hostname is sent before the encryption starts, so you can have more than one cert on the same server. This makes life easier for the admins as they no longer have to coordinate a bunch of hostname within a single cert, but it means that the target hostname travels through your ISP etc... in clear.
- deleted 8y ago
  [deleted]
- peterwwillis 8y ago
  tl;dr the only reason to care about SNI in TLS 1.3 is if you are a privacy freak. It's not a security concern. (Incidentally, your ISP can still learn what hosts you visit with traffic analysis)
  - 394549 8y ago
    > tl;dr the only reason to care about SNI in TLS 1.3 is if you are a privacy freak. It's not a security concern. You also need to care about SNI if you're trying to evade a firewall in a repressive country that blocks encrypted messaging services and VPNs that are used to bypass censorship and surveillance. Some of those firewalls were looking at the SNI to figure out if the traffic was something they wanted to block or not. https://arstechnica.com/information-technology/2018/04/google-disables-domain-fronting-capability-used-to-evade-censors/ https://arstechnica.com/information-technology/2018/04/googl...
    - peterwwillis 8y ago
      Trying to circumvent a repressive regime's laws is not a great design spec for the internet. Why not make Tor mandatory for all TLS 1.4 connections? Either they'll use traffic analysis to find out where you're going anyway or they'll just ban all HTTPS connections. Not that they need to as Russia is fine with just blocking whole IP ranges, making SNI irrelevant.
    - dingaling 8y ago
      They can still check the SNI string, since initial encryption is negotiated with the proxy. They can't subsequently masquerade as the actual SNI host since they don't have a valid cert for it, but by that point they've probably learned enough to terminate the connection and log the attempt. Well unless they have their root cert in your browser... SNI encryption is useful against ISPs and casual snooping, not state actors.
- schoen 8y ago
  > with a de facto maximum of about a 100 100 is the exact maximum by policy from Let's Encrypt, but if you're interested in more details about what CAs can do, there is a great thread on the Let's Encrypt Community Forum about the nature of the limitations: https://community.letsencrypt.org/t/is-there-an-rfc-that-covers-cert-size-limits/63122 https://community.letsencrypt.org/t/is-there-an-rfc-that-cov... Two resources mentioned there are https://1000-sans.badssl.com/ https://1000-sans.badssl.com/ https://10000-sans.badssl.com/ https://10000-sans.badssl.com/ which you can use to experiment with TLS client behavior in the presence of unusually large numbers of SANs.

dorfsmay 8y ago

Worded differently: With non-SNI TLS (traditional) the server name is only sent ONCE the connection is encrypted, you can have several severs by using Subject Alternate Names (SAN), with a de facto maximum of about a 100. All the names have to be in a single cert though, because at time of establishing the encrypted connection, there is no way to know which cert to use. With SNI, the hostname is sent before the encryption starts, so you can have more than one cert on the same server. This makes life easier for the admins as they no longer have to coordinate a bunch of hostname within a single cert, but it means that the target hostname travels through your ISP etc... in clear.

deleted 8y ago
[deleted]
peterwwillis 8y ago
tl;dr the only reason to care about SNI in TLS 1.3 is if you are a privacy freak. It's not a security concern. (Incidentally, your ISP can still learn what hosts you visit with traffic analysis)
- 394549 8y ago
  > tl;dr the only reason to care about SNI in TLS 1.3 is if you are a privacy freak. It's not a security concern. You also need to care about SNI if you're trying to evade a firewall in a repressive country that blocks encrypted messaging services and VPNs that are used to bypass censorship and surveillance. Some of those firewalls were looking at the SNI to figure out if the traffic was something they wanted to block or not. https://arstechnica.com/information-technology/2018/04/google-disables-domain-fronting-capability-used-to-evade-censors/ https://arstechnica.com/information-technology/2018/04/googl...
  - peterwwillis 8y ago
    Trying to circumvent a repressive regime's laws is not a great design spec for the internet. Why not make Tor mandatory for all TLS 1.4 connections? Either they'll use traffic analysis to find out where you're going anyway or they'll just ban all HTTPS connections. Not that they need to as Russia is fine with just blocking whole IP ranges, making SNI irrelevant.
  - dingaling 8y ago
    They can still check the SNI string, since initial encryption is negotiated with the proxy. They can't subsequently masquerade as the actual SNI host since they don't have a valid cert for it, but by that point they've probably learned enough to terminate the connection and log the attempt. Well unless they have their root cert in your browser... SNI encryption is useful against ISPs and casual snooping, not state actors.
schoen 8y ago
> with a de facto maximum of about a 100 100 is the exact maximum by policy from Let's Encrypt, but if you're interested in more details about what CAs can do, there is a great thread on the Let's Encrypt Community Forum about the nature of the limitations: https://community.letsencrypt.org/t/is-there-an-rfc-that-covers-cert-size-limits/63122 https://community.letsencrypt.org/t/is-there-an-rfc-that-cov... Two resources mentioned there are https://1000-sans.badssl.com/ https://1000-sans.badssl.com/ https://10000-sans.badssl.com/ https://10000-sans.badssl.com/ which you can use to experiment with TLS client behavior in the presence of unusually large numbers of SANs.