Re: [tor-dev] Domain Fronting, Meek, Cloudflare, and Encrypted SNI...
On Mon, Sep 24, 2018 at 01:46:10PM -0400, Nathaniel Suchy wrote: > 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. What we would need in order for meek to used encrypted SNI would be either: 1) support for encrypted SNI in Go's crypto/tls package; or 2) support for encrypted SNI in the Firefox that ships with Tor Browser, which meek-client could use through its TLS camouflage helper support. IMO (2) is less desirable because I'd like to get rid of the TLS camouflage helper support and replace it with a Go-level TLS camouflage library: https://github.com/refraction-networking/utls. The TLS helper works, but its complexity is a pain to deal with and leads to problems like https://bugs.torproject.org/12774 https://bugs.torproject.org/25405. Note, however, that a transport based on encrypted SNI doesn't have to be meek per se. I use "meek" to refer to a specific combination of domain fronting and a certain (fairly stupid and inefficient) HTTP/1.1 serialization of a bidirectional byte stream. It's conceptually straightforward to simply replace the "domain fronting" part with an "encrypted SNI" part. But it's possible to do better: if you're willing to abandon HTTP/1.1 compatibility and require HTTP/2, you can use the "server push" feature to implement a serialization that's much more efficient than the current one in meek. It may even be better to start over with a new codebase, it's not like meek's code is that large. But tjr's point stands: I think it's best not to push anything like this out until after encrypted SNI has seen some level of adoption by browsers. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] I
Sent from my iPhone b ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Domain Fronting, Meek, Cloudflare, and Encrypted SNI...
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 accust
Re: [tor-dev] Domain Fronting, Meek, Cloudflare, and Encrypted SNI...
On Mon, Sep 24, 2018, 12:46 PM Nathaniel Suchy 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 > ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Domain Fronting, Meek, Cloudflare, and Encrypted SNI...
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? References: * https://blog.cloudflare.com/encrypted-sni/ * https://blog.cloudflare.com/esni ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Memory usage on 0.3.4.8
Hi r1610091651, thanks for your report. please add that information and your OS+version to https://trac.torproject.org/projects/tor/ticket/27813 -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Memory usage on 0.3.4.8
Hi devs After upgrade from 3.3.7 -> 3.4.8, I've noticed that memory usage is erratic. Please consult the image below, showing memory available in green and memory used in blue on a tor dedicate system. [image: image.png] The upgrade to 3.4.8 took place on Saturday in week 37. The connection count / load was relativity stable: [image: image.png] (green inbound, blue outbound) I was wondering if there were any changes from 3.3.7 to 3.4.8 which might impact memory behaviour on a middle-relay. I'm also wander what is the "source" of this usage? Potentially relevant config entries (remainder is port/ip, accounting & exit(no)): MaxConsensusAgeForDiffs 4 hours DirCache 0 MaxMemInQueues 64 MB (but "defaulting" to 256mb now) Thanks in advance Seb ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
