4 ms·
Issues and Requirements for SNI Encryption in TLS (draft-03)
- wahern 8y agoThese two claims conflict in a very perverse manner: Many deployments still allocate different IP addresses to different services, so that different services can be identified by their IP addresses. However, content distribution networks (CDN) commonly serve a large number of services through a small number of addresses. ... The decoupling of IP addresses and server names, the deployment of DNS privacy, and the protection of server certificates transmissions all contribute to user privacy. This logic says that we have more privacy when resources are centralized behind commercial CDNs. WTF!? The truth is that it's a complex trade-off. But IMO long-term in terms of privacy I think we're better off discouraging CDN and Cloud centralization. At least in the big developed countries it's easier to put legal limits in place to prohibit ISPs from snooping than it is to control upstream content providers and their agents. The RFC conflates censorship in authoritarian regimes with privacy. I understand the very real and legitimate issues with censorship, but it's disingenuous to sell SNI encryption as a privacy-enhancing measure for everybody else. SNI encryption adds little marginal benefit in censored jurisdictions because authoritarian regimes can and will terminate HTTP connections (e.g. Great Firewall). But SNI encryption could do tremendous long-term harm because it creates a system where, perversely, privacy is "improved" by everybody moving their content distribution to CDNs and the Cloud. Furthermore, even if you can trust the promises of someone like Cloudflare to not sell data, the more traffic they proxy the more enticing a target they become. Centralization is risky. Centralization premised on dubious arguments is just plain bad policy and poor stewardship.
- LinuxBender 8y agoAgreed. Using a CDN does not enhance privacy and and centralizes logging for all sites behind just a few vendors. SNI does however improve privacy. I have dozens of SSL sites using one ip+port and strict SNI. I combine this with wildcard certificates and wildcard DNS to make enumeration futile. Today, most web browsers support SNI. Hopefully in the near future, more libraries and API tools will support it as well. This could ease the burden on ipv4 to a small degree.