Re: [tor-dev] Domain Fronting, Meek, Cloudflare, and Encrypted SNI...

[David Fifield <david@xxxxxxxxxxxxxxx>]

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.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev