This is mostly David Fifield's words from an email exchange. ---
I re-read proposal 203 the other day and wondered how it was related to the meek pluggable transport. As I might not be the only one, I thought it could be worthwhile to share David's answer. Feel free to improve!
proposals/203-https-frontend.txt | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
diff --git a/proposals/203-https-frontend.txt b/proposals/203-https-frontend.txt index 26101b3..df30cd5 100644 --- a/proposals/203-https-frontend.txt +++ b/proposals/203-https-frontend.txt @@ -245,3 +245,31 @@ Side note: What to put on the webserver? "Something to add to your HTTPS website" rather than as a standalone installation.
+Related work: + + meek [1] is a pluggable transport that uses HTTP for carrying bytes + and TLS for obfuscation. Traffic is relayed through a third-party + server (Google App Engine). It uses a trick to talk to the third + party so that it looks like it is talking to an unblocked server. + + meek itself is not really about HTTP at all. It uses HTTP only + because it's convenient and the big Internet services we use as cover + also use HTTP. meek uses HTTP as a transport, and TLS for + obfuscation, but the key idea is really "domain fronting," where it + appears to the censor you are talking to one domain (www.google.com), + but behind the scenes you are talking to another + (meek-reflect.appspot.com). The meek-server program is an ordinary + HTTP (not necessarily even HTTPS!) server, whose communication is + easily fingerprintable; but that doesn't matter because the censor + never sees that part of the communication, only the communication + between the client and CDN. + + One way to think about the difference: if a censor (somehow) learns + the IP address of a bridge as described in this proposal, it's easy + and low-cost for the censor to block that bridge by IP address. meek + aims to make it much more expensive: even if you know a domain is + being used (in part) for circumvention, in order to block it have to + block something important like the Google frontend or CloudFlare + (high collateral damage). + +1. https://trac.torproject.org/projects/tor/wiki/doc/meek
On Wed, Jun 25, 2014 at 6:05 AM, Lunar lunar@torproject.org wrote:
This is mostly David Fifield's words from an email exchange.
I re-read proposal 203 the other day and wondered how it was related to the meek pluggable transport. As I might not be the only one, I thought it could be worthwhile to share David's answer. Feel free to improve!
David, do you sign off on this? If so, I'll add it to the proposal.
On Mon, Jul 07, 2014 at 01:57:04PM -0400, Nick Mathewson wrote:
On Wed, Jun 25, 2014 at 6:05 AM, Lunar lunar@torproject.org wrote:
This is mostly David Fifield's words from an email exchange.
I re-read proposal 203 the other day and wondered how it was related to the meek pluggable transport. As I might not be the only one, I thought it could be worthwhile to share David's answer. Feel free to improve!
David, do you sign off on this? If so, I'll add it to the proposal.
Yes, I wrote those words and said it's okay to use them.
David Fifield
On Mon, Jul 7, 2014 at 2:00 PM
, David Fifield david@bamsoftware.com wrote:
On Mon, Jul 07, 2014 at 01:57:04PM -0400, Nick Mathewson wrote:
On Wed, Jun 25, 2014 at 6:05 AM, Lunar lunar@torproject.org wrote:
This is mostly David Fifield's words from an email exchange.
I re-read proposal 203 the other day and wondered how it was related to the meek pluggable transport. As I might not be the only one, I thought it could be worthwhile to share David's answer. Feel free to improve!
David, do you sign off on this? If so, I'll add it to the proposal.
Yes, I wrote those words and said it's okay to use them.
Okay, applied.
(To be clear, I didn't doubt that you wrote those words or that Lunar had permission to use them -- I just wanted to double-check that you thought they belonged in that proposal, and that you hadn't come up with better words in the interim.)
cheers,
-
David Fifield -
Lunar -
Nick Mathewson