On Mon, Sep 24, 2018 at 01:46:10PM -0400, Nathaniel Suchy wrote:

Why this matters: With the right adjustments for TLS 1.3 and Encrypted SNI support, Cloudflare may be a viable option for Meek.

Risks: * Firewall products could always use DPI and block TLS 1.3 altogether. * Firewall products could block all requests with encrypted SNI.

I wrote an essay on some of the implications of encrypted SNI here: https://groups.google.com/d/msg/traffic-obf/UyaLc9jPNmY/ovNImK5HEQAJ tl;dr: yes, encrypted SNI is a very good thing for censorship circumvention and privacy more generally; a risk though is that it further centralizes access to online resources. ---- 2018-08-18 Efforts are underway to add SNI encryption as an extension in TLS 1.3. * https://tools.ietf.org/html/draft-rescorla-tls-esni-00 * https://www.ietf.org/mail-archive/web/tls/current/msg26842.html I find this a really hopeful development. I appreciate the work of everyone who is helping to make it a reality (some of them are on this list). Encrypted SNI will of course be a boon for online privacy generally, but in our world of censorship circumvention it could be the biggest thing since the ascendance of TLS. Along with its benefits, I foresee that encrypted SNI will change the basic game in ways that we need to be ready for. I expect that we'll need to reevaluate our customary models and begin to consider new challenges. At first glance, encrypted SNI—in whatever form it may eventually take—is a silver bullet. It's domain fronting without the downsides. It solves all our problems, up to traffic analysis: payload encryption prevents blocking by content, and SNI encryption protects the destination address. The censor cannot distinguish various connections to a TLS server and faces the old dilemma: block all, or block none. And experience shows that we can find servers with a sufficient degree of co-hosting that a censor will hesitate to "block all." So what's the catch? I don't really think there is one, at least not a major one. SNI encryption is poised to put censorship circumvention on substantially securer footing. As https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-03 (which I encourage you to read) says, "Historically, adversaries have been able to monitor the use of web services through three channels... These channels are getting progressively closed." But what I do think SNI encryption will do is force us to reconsider our threat models. Solving our current batch of problems is going to uncover new problems—lesser problems, to be sure—but ones that we have until now mostly ignored because they were not the most pressing. Censors, too, will be forced evolve, when they are finally deprived of their last easy traffic distinguisher. I predict a displacement of the battleground, from the land of firewalls to new arenas. It's a credit to everyone's work on domain fronting, and the basic soundness of the idea, that when it began to falter, it was not because of the Great Firewalls of the world, but because of the Googles and Amazons. This phenomenon is an example of what I mean when I say that old challenges will give way to new ones. We beat the censors at their game, and resisted direct blocking long enough for another weakness to reveal itself; i.e., that network intermediaries don't reliably perform the functions that we depended on. I mean that as an observation of fact, not as implied judgement—personally I don't really blame Google and Amazon for their policy change regarding domain fronting. While the wisdom of the decision is debatable, and I suspect there is more to their rationale than they have stated publicly, certainly they are under no obligation to continue supporting an unintended feature, no matter how useful we find it. But whatever the cause, the fact is that domain fronting, while demonstrably robust against border-firewall censors, is susceptible to the changing dispositions of intermediary services. We reached this frontier of experiential knowledge only because we had beaten the censor's usual tricks—we transcended the cat-and-mouse game. I like to draw an analogy with human health: our caveman forebears didn't worry about dying from heart disease, because it was almost certain that they would be killed by something else first, a woolly mammoth, say. It was only after the immediate threat of death by mammoth had subsided, that humans had the comparative luxury of being concerned about heart disease. So it is with us now: we built a cat-proof mouse, and now we see what other worries a mouse has. I can see something similar playing out with encrypted SNI, only on a larger and more pervasive scale. Network intermediaries—CDNs, app stores, hosting providers—are going to face more and more pressure: as other links in the chain of communication are strengthened, those intermediaries will become attractive targets of action by censors. We already see examples of censors having to step out of their accustomed comfort zones because of generally increasing Internet security, for example when the government of China pressured Apple to yank VPN apps from its app store. I contend that if the government had the ability to block apps all by itself, without petitioning Apple, then that's what it would have done. That the censor resorted to pressuring a third party shows a certain weakness, but the fact that it succeeded shows it is still strong enough for its purposes. It also highlights a shift in moral responsibility. If the government were able to block apps without asking, then Apple could just throw up its hands and say: "not my fault." But because the censor has no choice but to ask, Apple must make the deliberate choice of whether to become an agent—however unwilling—of censorship. We circumvention designers have customarily assumed that network intermediaries are benevolent, or at least non-malicious—that they do not collaborate with a censor. We assumed so, because the risk of direct blocking by a censor overshadowed any other risk. In a world of encrypted SNI, where the direct risk from the censor is greatly diminished, we will need to reexamine this assumption. Intermediaries will become de-facto gatekeepers of information, to an even greater degree than they are now, and they'll be in the unenviable position of being the logical place at which to implement censorship. As things stand now, when a court in India orders a site blocked, it's Airtel's problem to block it. But when encrypted SNI renders Airtel unable, it'll be Cloudflare's problem. Now, if I had to choose between the good will of Cloudflare et al. and that of the GFW, there's no comparison: obviously you choose Cloudflare every time. And yet, we can't overlook that Cloudflare once booted a site on a CEO's whim; nor that Google secretly started building a censored search engine for China. The operators of network intermediaries, and their commitment to human rights, will be tested more than ever, and the population of Internet users will increasingly rely on them to do the right thing. As circumvention designers, one thing we can do to help those services help themselves is not to proxy directly from the services themselves, but to use at least one additional encrypted hop to an separate proxy server. That way, it becomes technically harder for the services to do surgical blocking. I have to admit that I don't fully understand the apparent enthusiasm for encrypted SNI from groups that formerly were not excited about domain fronting. It's possible I misunderstand some subtlety, but to my mind, they both should amount to about the same thing from the their perspective. The primary difference is one of scale. The stated concerns with domain fronting also apply to encrypted SNI; in particular that if one customer gets blocked, it will have a collateral effect on other customers. Maybe the difference in scale is really it: the cloud companies are happier to bet against blocking when *all* their customer's domains are potentially affected, rather than just one. It's a rational enough viewpoint (greater potential collateral damage → lower probability of blocking), but to my mind encrypted SNI doesn't fundamentally alter the nature of the game, it just raises the stakes. Don't get me wrong: I welcome the adoption of encrypted SNI for whatever reason. It's better than domain fronting, it'll be nice to have it in a standard, and once we have it we won't want to go back. But I hope that operators understand what they're getting into. Will they get cold feet when push comes to shove—when a future version of Telegram uses encrypted SNI and Russia again blocks millions of IPs? Or malware adopts it for C&C and infosec blue teamers get annoyed? I said earlier that I didn't see any major catch with encrypted SNI. The minor catch I see is the potential for increased centralization. TLS with encrypted SNI is likely to be the most effective form of circumvention, which means that unless you're a major player, or hosted on one, you'll be at increased risk of being blocked. I've read some criticism online of circumvention systems, like domain fronting, that route traffic through the major cloud companies. One the one hand, I find that kind of criticism annoying, because it's not that the use of centralized services is a desired, designed-in feature; it's that we don't yet know how to do it better. Circumvention is already hard enough, and by demanding that is be simultaneously decentralized, these critics are asking us not only to juggle, but to do so backwards on roller skates. But on the other hand, I can sympathize with their point of view. Despite the difficulty, we *should* aspire to better designs. I dislike giving connection metadata to Amazon and Microsoft as much as anyone. Unfortunately, encrypted SNI is likely to move us even farther from the decentralized end of the scale. It will be so effective, and so easy to use, that I predict there will be a convergence of systems using it. We see something like that effect today, where there is a perception that if you want to resist DoS, you have no choice but to be on one of the big CDNs. The outcome I fear for the web is something like we have today with SMTP, where the costs of setting up an independent server are so great as to make the choice effectively impossible. But I don't want to overblow my concern here. We should be thinking about ways to decentralize, but encrypted SNI is worth pursuing even if we can't think of any. What are the risks to reaching a future of easy and effective circumvention using encrypted SNI? The worst case is if the proposal fails or is permanently stalled: we'll be stuck in a world that is pretty much like the world of today, except more hostile to domain fronting, waiting for something else to come along. As I understand it, draft-rescorla-tls-esni-00 is subject to change before standardization, and I suppose there's a chance it could morph into something so unwieldy or undeployable that it fails despite standardization. Most of the discussion that I've seen so far has been positive, but not all stakeholders at the IETF love the idea; in particular I get the impression that some people rely on plaintext SNI for monitoring or regulatory compliance, and encrypted SNI will make their lives more difficult. So we have to watch out for it being neutered in a way that enables censorship. Crucially, the value of encrypted SNI for circumvention depends on its adoption. If at first it's only circumventors and malware authors using encrypted SNI, then censors and security firewalls will start to block it, and then it's permanently skunked, no use to anybody. What we need is for at least one of the major browsers to implement encrypted SNI and (importantly) enable it by default. It's browsers that have to lead the way here, just as they effectively snuck TLS deployment past the censors' notice, until it was too late to do anything about it. And what about traffic analysis; that is, classification based on the timing and size of packets in an SNI-encrypted TLS stream? My gut feeling is that it still won't be the first tool that censors reach for. I see pressure on third parties as a more likely threat. But it becomes more likely with each passing day, and anyway, my instinct could be wrong. So I think that research on traffic analysis obfuscation will become more and more relevant.

On Mon, Sep 24, 2018, 12:46 PM Nathaniel Suchy <me@lunorian.is> wrote:

Hi everyone,

Cloudflare has added support to TLS 1.3 for encrypted server name indication (SNI). This mailing list post is a high level overview of how meek could take advantage of this in relation to Cloudflare who until just now wasn’t an option for domain fronting.

What this means: Effectively domain fronting works by sending a different SNI and host header. CDN providers like Cloudflare started double checking to make governments happy, scratch that line, I mean to protect their customers from fraud and abuse. They seem to of backtracked now. Encrypted SNI means that a firewall or coffee shop owner won’t be able to use SNI to see the real origin of TLS traffic.

Why this matters: With the right adjustments for TLS 1.3 and Encrypted SNI support, Cloudflare may be a viable option for Meek.

Risks: * Firewall products could always use DPI and block TLS 1.3 altogether. * Firewall products could block all requests with encrypted SNI.

Thoughts anyone?

The latter concern seems real enough for me that we should consider not front-running major adoption in browsers. -tom