15 ms·
Cloudflare, Mozilla, Fastly, and Apple Working on Encrypted SNI
- okket 8y agoDirect link to the tweet thread https://twitter.com/grittygrease/status/1018566026320019457 https://twitter.com/grittygrease/status/1018566026320019457 Link to the RFC draft-00 "Encrypted Server Name Indication for TLS 1.3" on which the work is based https://tools.ietf.org/html/draft-rescorla-tls-esni-00 https://tools.ietf.org/html/draft-rescorla-tls-esni-00
- stingraycharles 8y agoThanks, the UI of this Stackshare website is not that great.
- prdonahue 8y agoYeah, strange. I submitted the direct Twitter link (with the exact same title) about 5h before this StackShare link was submitted: https://news.ycombinator.com/item?id=17537176 https://news.ycombinator.com/item?id=17537176.
- breakingcups 8y agoI just get an almost blank page.
- DeepYogurt 8y agoMe too. It has a lot of javascript that I'm blocking.
- tscs37 8y agoThis is amazing work, can't wait for this to be finished and deployed on the internet. Together with encrypted DNS (DoT and DoH) we finally get fully confidential connections to a server without leaking anything other than Remote IP.
- dogma1138 8y agoThat only works if the server you are visiting is behind a CDN with no resources served directly from the dedicated host. The encrypted SNI would primarily be useful to make censorship and MITM attacks harder.
- rqs 8y agoI'm don't completely get it. How does CDN is required for this? Let's say that I have a Nginx on my server which serves a lot's of websites, and whose web sites can only be accessed through HTTPS with SNI, not HTTP. Now with Encrypted SNI deployed, requests from my clients can still be dispatched to it's respective virtual hosts, but any sniffers in the middle of the connection should only be able to see that my clients are accessing to my server, but not which virtual host. Is I'm missed anything? I haven't dig deep in to this currently.
- deleted 8y ago[deleted]
- reaperhulk 8y agoThat’s an accurate summary, but CDNs are important because they terminate huge numbers of sites. In your example censorship is relatively easy since network operators who want to block a site won’t have very much collateral damage by blocking your entire server just to deny access to that single site. CDNs, terminating millions of sites, make that far more challenging.
- dogma1138 8y agoIt misses the fact that even with encrypted SNI it would be very easy to fingerprint a website see my comment above.
- geocar 8y agoThat's about it. The theory is that if you put your server behind a popular CDN, then a state-level attacker is left with little choice but to block the entire server. Another benefit is that attacks that can observe but not modify traffic will be less able to track what sites you're visiting. There are risks though: * It's unclear how resistant CDNs actually are to state-level attackers. * It's unclear how resistant CDNs are to regular attackers[1] * Corporations/Security-savvy users will find it difficult to control what [their] workstations can reach and cannot: Allowing access to a single cloud-based service may inadvertently allow access to a malicious command/control server sharing the CDN. [1]: https://9to5mac.com/2017/02/24/cloudflare-server-breach-cloudbleed-uber-fitbit-okcupid/ https://9to5mac.com/2017/02/24/cloudflare-server-breach-clou...
- Cyphase 8y agoIt's great seeing more and more work being done to increase privacy and anonymity online, especially things like this which are about plugging smaller, less obvious holes. Nothing is perfect, but the harder it is for the snoops and spooks, the better.
- EGreg 8y agoWhat do you think the time frames are for something like this to make it into all the major browsers?
- RyanZAG 8y agoYou'd need to get it into all servers too, which is probably a very long time frame.
- galadran 8y agoThis design only requires the hosting server (e.g. Cloudflare, CDN, ...) to support encrypted SNI. It can be entirely transparent to user deployed servers. So it might well be here much sooner than you think!
- breakingcups 8y agoDoes anyone know Google's position on this? I tried finding a relevant Chromium issue but failed.
- jgunsch 8y agoThe linked Twitter thread mentions that BoringSSL (maintained by Google, used in Chromium) has an implementation already.
- breakingcups 8y agoRight, I forgot BoringSSL was used in Chromium. Thanks!
- tialaramex 8y ago"Google's position" includes a lot more than just some Chromium developers, and even Chrome is big enough for there to be internal tension between teams focused on end-user security (e.g. encrypting SNI) and real world performance. Google is a cloud operator these days, and as such if something like this is to be of much use they'll have to eat the consequences at the other end, which means their product (Cloud servers) working less well for uncontroversial services than it might if they let censors do as they please. Basically for a cloud operator or CDN choosing to actually implement a working encrypted SNI solution (whatever it is) means now all your uncontroversial sites are obliged to tell censors "I'm Spartacus" and reap the consequences. If the censor is a single place of business or a micro-state maybe you can just suck it up. If it's Russia then you've just decided you want to annoy all your paying customers on a point of principle. I believe the word for that in Yes, Minister was "Brave". Ultimately, for this to be deliver much value (and if it doesn't why bother at all?) it needs to be something every major cloud provider and CDN does for all the sites they host. Which means from somewhere they're all going to need to find a lot more backbone than is needed for, say, TLS 1.3 itself. I hope it works, but I fear it will not.
- matt4077 8y agoGoogle and AWS are each large enough to make blocking them a very expensive proposition. I also get the sense that Google is pretty good at prioritizing long-term goals such as a fast and secure internet over any short-term considerations.
- est 8y agoCan we do something about the certs? There are DPI that can block websites by cert CN/SAN.
- tscs37 8y agoThis is sorta it. SNI is the only unecrypted part that leaks the server hostname. CN/SAN blocking usually has a middlebox that decrypts the connections so there is nothing to be done here. If somebody can MitM your encrypted connection to both server and DNS, encrypted SNI stops working to my understanding.
- Buge 8y agoEncrypted SNI is about protecting you from people who aren't in your list of trusted CAs. If someone is in your trusted CA list, why do you want protection from them? If you want protection from them, remove them from your list of trusted CAs.
- est 8y agoIIRC after ServerHello the cert was given to client in clear text.
- geertj 8y agoThis changed in TLS 1.3. The server cert is now encrypted.
- est 8y agoThat's cool. Is it possible to force google.com use TLS1.3?
- tialaramex 8y agoIf you insist upon talking TLS 1.3 draft 23, which is the last substantive change before the draft went to the RFC queue, google.com is perfectly happy to talk TLS 1.3 draft 23. TLS 1.3 has downgrade detection, so if a middlebox tries to downgrade you (e.g. to TLS 1.2) without proxying the entire connection the TLS 1.3 implementation in your client will spot that and reject the connection. Proxying is possible (including with a downgrade) if you trust the proxy. So, don't. If you have a recent-ish version of Chrome or Firefox you are already using all this.
- enitihas 8y agoJust curious, would it enable Signal and other tools trying to avoid censorship by doing domain fronting without the cloud provider (e.g AWS Cloudfront) noticing. e.g. https://news.ycombinator.com/item?id=16970199 https://news.ycombinator.com/item?id=16970199 https://news.ycombinator.com/item?id=16868564 https://news.ycombinator.com/item?id=16868564
- icebraining 8y agoArguably it's no longer domain fronting, it's just connecting to a server that serves both sites without saying which one you want. So it's better, because it doesn't break any rules. That requires AWS et all to support SNI encryption, though. What I wonder is about downgrade attacks. Browsers will probably have to support clear-text SNI for a long time - could censors abuse this by making it seem that no server supports encrypted SNI? Or is there a digitally-signed way for servers to prove that they support it, before the browser sends the host?
- dannyw 8y agoThis solution is already solved through things like HSTS preloads.
- rdl 8y agoApps and other machine to machine can require encrypted SNI pretty easily. Pinning of various other kinds (not just in the binary, but via headers or a list in a browser) solves it too.
- icebraining 8y agoApps and other machine to machine can require encrypted SNI pretty easily. Yes, but then the censor can distinguish these apps from a regular client, and block them. This only works if browsers do it too, so that the app can't be distinguished.
- tialaramex 8y agoThe intent is that you'd be using a secured DNS channel such as DoH or DoT to obtain your DNS results - so an adversary can't rewrite the DNS records. This proposal supposes that when we've decided to talk to example.com we may as well ask a DNS query that requests not only 'A' and 'AAAA' records (IPv4 and IPv6 address) but also an encrypted SNI key. If such a key is available we can use it to prove to the server (which set that key) which name we wanted, while eavesdroppers are none the wiser. If the adversary can eavesdrop DNS they can already speculate from our query which host we wanted to talk to, but securing DNS is a problem for which there are known solutions.
- peterwwillis 8y agoI think it's worth pointing out the repercussions of this and DNS-over-HTTPS. Every corporation which does SNI scanning for web filtering will require every user to insert the company's CA cert in every client they use. This then also forces them to make a choice between requiring all apps in all networks to do this, or whitelist certain parts of the network. Not only does this reduce their security, but it limits how apps can work on their networks. Authoritarian governments will also start requiring this. I could even see federal agencies for non-authoritarian governments making a stink over it on law enforcement grounds. They already hate encryption. If they can't force you to expose what sites you are visiting, they may force new legislation to require all web service providers to provide logs to law enforcement, which is a much worse privacy violation than just seeing what domain you were hitting. I think the better solution to this would have been to improve server-side support for VPNs and Tor. Tech does not exist in a bubble, and rights can be taken away when they conflict with the interests of authority.
- Buge 8y agoThey could always do IP blocking and tracking.
- peterwwillis 8y agoDoesn't really work if half the internet is covered by CloudFlare's free CDN.
- anticensor 8y ago> federal agencies for non-authoritarian governments You should correct it into _national_ agencies for non-authoritarian governments. Unitary states are majority in the world.
- zorked 8y agoIf this makes surveillance more visible it's already a huge societal win.
- michaelt 8y agoEvery corporation which does SNI scanning for web filtering will require every user to insert the company's CA cert in every client they use. Just require your employees to route port 443 traffic through a proxy, making a CONNECT request. It doesn't prevent domain fronting, of course, but neither did SNI scanning.
- mosselman 8y agoIs this really done by these companies or just by developers from these companies in their spare time?
- eastdakota 8y agoThis has 100% support from the most senior quarters at Cloudflare. Can’t speak for the others.
- repolfx 8y agoThis doesn't make much sense to me, I wonder if the senior management at these firms understand what the engineers are doing. You could already do something approximating encrypted SNI using domain fronting. Connect to boring domain A via SSL, then send an HTTP request with a Host header set to your actual target domain B. Load balancing HTTP reverse proxies in the clouds would happily use the encrypted domain in the Host header, ignoring SNI in the TLS headers. This started being widely used to evade censorship and build "unblockable" services, because to block them you'd have to block all of Cloudflare or Akamai or Google. These firms all, as one, banned domain fronting. Turns out the bosses wanted access to big markets more than they wanted censorship resistance. So why do these developers think it'll work out any differently this time, with slightly different packet formats? First company to enable encrypted SNI will get blocked at the national level and will blink. The others will look at it and probably never try. If they're serious about making sites unblockable by domain, the first step is to re-activate support for domain fronting and make a public commitment to keep it.
- stingraycharles 8y agoI don't think this is a correct assessment. Domain fronting / boring domains can still be blocked, and this is precisely what caused the whole Signal / AWS issue recently. This is a commercial risk to the domain holder, and to any organisation with shareholders it makes sense for them not to want their domain to be used for this purpose. The engineers are looking for an alternative solution which pleases both camps: no more domain fronting, and no more possible blocking of domains by adversaries. I think it's a bit idealist to say that if they're serious about making sites unblockable, they should put their commercial interests aside. This will not happen. But they are working on an alternative solution where both parties (engineers and shareholders) are happy, and I can only support that.
- repolfx 8y agoIt's the same thing. How do you think encrypted SNI will play out? The IP address is still available, so this only helps if the IP address you're connecting to hosts many domains, some of which are desirable to the censors to keep unblocked. In practice this means big CDNs and hosting services, of which there are only a few. The reason they stopped domain fronting wasn't technical, it was business related. If these engineers can't win the internal political battles to keep domain fronting working, what makes them think they can win the exact same battle this time around?
- social_quotient 8y agoOne thing my team is working on and “waiting” for is the ALT SVC SNI extension to be adopted. If you haven’t read the spec it’s pretty fascinating. https://tools.ietf.org/id/draft-bishop-httpbis-sni-altsvc-02.html https://tools.ietf.org/id/draft-bishop-httpbis-sni-altsvc-02... Working with ALT SVC’s and being able to set the SNI which piggybacks on some of the OP encrypted SNI is pretty cool tech. It’s all early, hard to get working, not supported by most browsers, but it’s going to allow for some interesting future security and trust options.
- exikyut 8y agoRelated/relevant question. A number of months ago I decided to finally begin researching a project I've had on the backburner for ages: a simple domain+IP bandwidth throughput counter for everything within my LAN. Basically I wanted to make a dashboard saying "you exchanged this much data with this many IPs within the last 24h; here's the per-IP and per-domain breakdown; here are the domains each IP served", that sort of thing. Part of the motivation for this was to track down the headscratch-generating mysterious small amount of "unmetered data" my ISP reports each month (I don't watch TV over the internet and cannot think of what else would be it), and the other part of the motivation was to satisfy idle curiosity and observe domain<->IP cohesion/fragmentation over time. At the exact point I began my research TLS 1.3 had just been approved, and I rapidly realized my nice little idea was going to get majorly stomped on: the inspiration for the project, years ago, was the SNI field itself (hah). 5-10 years ago, I would have been able to route all my traffic through a gateway box, and passively watch/trace (slightly behind realtime) everything via tcpdump or similar, catching DNS lookups and sniffing SNI fields. That would have handled everything. Now, with encrypted SNI, and the upcoming DNS-over-HTTPS (seems I need to think ahead :/), it looks like my (now irritatingly stupid-seeming) project will require me to generate a local cert, install it on all my devices, and get a machine beefy enough to keep line-rate speed while doing MITM cert-resigning. And then, for the fraction of traffic my system reports as "not signed by local cert", I'm just going to have to let that go, or I'll break everything that uses cert pinning. ...which I wouldn't be surprised if some programs eventually use with DoH lookups (using pinned certs fished out of DNSSEC for DoH makes sense). I'm very very interested to know if there are any alternatives I can use. I realize, for now, that I can sniff for and collect DNS lookup results and associate these with IPs, but when will this break?(!) Honestly HTTPS and security in general just seems like a gigantic mess. I say this not as a disrespect of the architecture, but more as a "wow, this is just so hard to get right".
- xg15 8y agoEven on desktop, some non-browser programs already seem to use cert-pinning. E.g., there doesn't seem to be a way at all to inspect the traffic of the Dropbox client on Windows, short of patching the executable. The situation is likely worse on mobile. So no, I don't think that's an easily solvable problem. And yes, I also think it's a giant mess. Even from a security standpoint it doesn't seem to make sense: We're fortifying the connections itself against sniffing but at the same time force everything to go through centralized cloud services which have a growing reputation to be hacked and also force everyone to blindly trust the programs they have running on their own devices. To put on my tinfoil hat, this kind of threat model sometimes seems better designed to protect surveillance capitalism against attacks instead of protecting the users.
- XparentX 8y agoIs this a way for the ad-industry to evade pi-hole or similar technology?
- icebraining 8y agoThey would spend more money developing this than they would gain. Nobody, in a statistically-relevant sense of the word, uses pi-hole.
- XparentX 8y agoWhat do you mean, not use pi-hole?
- icebraining 8y agoI very few people use it, to the point that the ad companies don't really losing anything from it.
- gruez 8y agopi-hole doesn't intercept/inspect SNI. they block at the DNS level.
- jopsen 8y agoLots of people here seem to focus on how this could prevent censorship and spying by governments. It might raise the bar, and make such measures infeasible for small countries, while also making it more visible. But what we really should focus on is the added security everywhere else. Even when I trust my ISP, that is no reason not to have defense in depth. Someday WiFi or 4G network will have a horrible security flaw. And then this will be another bolt in the next layer of security. If security is important, we need multiple layers! Focusing on what authoritarian governments might or might not do is pretty much besides the point.
- xg15 8y ago> Even when I trust my ISP, that is no reason not to have defense in depth. But if this is the method we are following, we will also need to think about the costs-vs-benefits of different security measures. If patching known exploits or threat-models, the cost-vs-benefit generally allows for very strong security measures because you know the risks if you don't implement it and you know when the measure is implemented and you are done. However, with "defense-in-depth" you could always add another layer of encryption, add another sandbox layer or make a system less general-purpose. If security is your only priority, there is no point where you would stop.
- xj9 8y ago> If security is your only priority, there is no point where you would stop. in a secure system, adding defensive layers is constrained by the amount of code required to implement them. at a certain point, these layers can become an attack surface, and therefore a liability.
- ausjke 8y agoSNI is key to https virtual hosting. If encrypted how will the server know where to go? More importantly, why not just use the "Host" header inside https if you need SNI? I mean, if SNI is encrypted then we don't need SNI at all, just use the Host field inside https header which is encrypted already and carries all the info you need know. Am I missing something? Yes SNI could be encrypted outside of the SSL handshake in client-hello, but why? will it be useful to defend domain fronting, don't think so.
- tialaramex 8y agoThe purpose of SNI is to allow the server to pick the right proof of identity (usually an X.509 certificate) for the site the client actually wants to access. This needs to happen before the HTTP session starts, so we can't wait for a Host: header. Yes, the intent is exactly to encrypt SNI during the initial ClientHello, in particular the public key used will be found in DNS alongside the server's IP address(es). The key used will be the same for some set (perhaps all) of names hosted on this IP address, so yes it achieves the same goal as "domain fronting" but without tricks.
- zzzcpan 8y agoAm I understanding this correctly, they propose a _esni TXT record for a domain containing a public key, which is used to encrypt SNI? Who does this protect from? ISPs that don't want to give up spying obviously are monopolies, have enough power and can block DNS-over-HTTPS/TLS and all 3rd party resolvers. So can censors. State actors can intercept DNS traffic even easier, since DoH/DoT make it more centralized. IP address itself leaks so much information, that cleartext SNI might not be even needed after all (meaning you can still pinpoint a domain with high probability just by IP address). Maybe this can help make collateral freedom a bit easier. But it's already possible to achieve that with generated not known ahead throwaway domains, they are cheap compared to CDN/cloud costs. And collateral freedom doesn't really work against censorship all that well on its own, as centralization makes it easy to pressure CDNs and clouds to deny service to dissidents. Not enough collateral damage.
- zamadatix 8y ago"ISPs that don't want to give up spying obviously are monopolies, have enough power and can block DNS-over-HTTPS/TLS and all 3rd party resolvers." Too many big players are behind it for ISPs to be able to get away with that strategy. If a battle started then Google, Cloudflare, and others could simply start hosting DNSoHTTPS directly alongside all of their major services. To most customers 90% of "the internet" is the services from these providers. "So can censors. State actors..." There is never going to be surefire way to subvert a large government that controls the infrastructure you are trying to sneak through. Even if there was the government would still be in control of data at any companies that operate inside the country. It's not "outsmart China or bust". Rather than dismissing the solution as useless because it doesn't provide the ultimate privacy maybe it's more worthwhile to look at what it can do and how other changes to TLS and other protocols can continue to make things harder to snoop.
- mschuster91 8y ago> It's not "outsmart China or bust". While we're at it: what prevents, say, a cartel of the world's transit providers to cut China off from the Internet until they don't censor it any more? And why haven't they done so? After all, there are only two outcomes: the Chinese government goes fully intranet, but their economy tanks as a result or the Chinese government backs down, with their economy (and civil rights) profiting. Same goes for Russia or Iran. It's about time that Western companies take a stance when it comes to civil rights. So much technical and social progress is kept back out of the fear the censorship creates, it must be profitable by now to simply force their hands. Oh, and while we're at it, why are there still companies doing business with our very own guilty parties in espionage terms? Why do they have bank accounts? Why is anyone renting them office spaces, selling computers and whatever else? The same companies from USA, Germany, Israel and I believe also Italy do not only supply our own governments (which is bad enough in itself) but also dictators who use these tools to repress their own citizens.
- chaz6 8y agoWould it not be simpler to issue an SSL certificate for the IP address for the outer connection (kind of like how EAP works with inner and outer identities) instead of relying on a DNS RR?