[tor-dev] [PATCH] Add some words about meek in proposal 203
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 -- 1.7.10.4 signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Python ExoneraTor
On 24/06/14 18:53, Kostas Jakeliunas wrote:
> Hi Karsten,
Hi Kostas,
> On Tue, Jun 17, 2014 at 10:13 AM, Karsten Loesing
> wrote:
>> Hi Kostas,
>>
>> On 11/06/14 04:48, Kostas Jakeliunas wrote:
>>> Hi all!
>>>
>>> On Mon, Jun 9, 2014 at 10:22 AM, Karsten Loesing
>>> wrote:
On 09/06/14 01:26, Damian Johnson wrote:
> Oh, and another quick thought - you once mentioned that a descriptor
> search service would make ExoneraTor obsolete, and in looking it over
> I agree. The search functionality ExoneraTor provides is trivial. The
> only reason it requires such a huge database is because it's storing a
> copy of every descriptor ever made.
>
> I suspect the actual right solution isn't to rewrite ExoneraTor at
> all, but rather develop a new service that can be queried for this
> descriptor data. That would make for a *much* more worthwhile project.
>
> ExoneraTor? Nice to have. Descriptor archive service? Damn useful. :)
I agree, that was the idea behind Kostas' GSoC project last year. And I
still think it's a good idea. It's just not trivial to get right.
>>>
>>> Indeed, not trivial at all!
>>>
>>> I'll use this space to mention the running metrics archive backend
>>> modulo ExoneraTor stuff / what could be sorta-relevant here.
>>>
>>> fwiw, the onionoo-like backend is still running at an obscure address:port:
>>> http://ts.mkj.lt:/
>>
>> Would you want to put the summary you wrote here to that link?
>
> Moved the whole setup to work on port 80 (via uWSGI, with nginx as the
> reverse proxy) ("ts.mkj.lt:/some/request" now transparently
> perma-redirects to "ts.mkj.lt/some/request"), and put a simple very
> short summary on the index:
>
> http://ts.mkj.lt/
> (have you heard of this new edgy font, "Times New Roman"?)
> Let me know if something is too confusing or reads funny, etc. I can
> elaborate more in the beginning or after the examples, too.
Looks good to me!
>> And would you want me to add a sentence or two about your service
>> together with a link to the CollecTor page?
>>
>> https://collector.torproject.org/#references
>
> Ok!
>
>> What would I write?
>
> something like? --
>
> The Searchable Metrics Archive backend allows users to search and
> explore relay metrics data (consensuses and descriptors), present and
> past. It covers the years 2008-now and provides an Onionoo-like API.
>
> does that make sense?
It does! Tweaked a tiny bit and put online.
>>> TL;DR "what can I do with that" is: look at:
>>>
>>> https://github.com/wfn/torsearch/blob/master/docs/use_cases_examples.md
>>>
>>> In particular, regarding ExoneraTor-like queries (incl. arbitrary
>>> subnet / part-of-ip lookups):
>>>
>>> https://github.com/wfn/torsearch/blob/master/docs/use_cases_examples.md#exonerator-type-relay-participation-lookup
>>>
>>> Not sure if it's worth discussing all the weaknesses of this archive
>>> backend in this thread, but the short relevant version is that the
>>> ExoneraTor-like functionality does mostly work, but I would need to
>>> look into it so see how reliable the results are ("is this relay ip
>>> address field really the one we should be using?", etc.)
>>>
>>> But what's nice is that it is possible to do arbitrary queries on all
>>> consensuses since ~2008, with no date specified (if you don't want
>>> to.) (Which is to say, "it's possible", not necessarily "this is the
>>> right way to do the solution for the problems in this thread")
>>>
>>> So e.g. this is the ip address where moria runs, and we want to see
>>> what relays have ever run on it:
>>>
>>> http://ts.mkj.lt:/details?search=128.31.0.34
>>>
>>> Take the fingerprint of the one that is currently running (moria1),
>>> and look up its last 500 statuses (in a kind of condensed/summary
>>> form):
>>> http://ts.mkj.lt:/statuses?lookup=9695DFC35FFEB861329B9F1AB04C46397020CE31&condensed=true
>>>
>>> "from", "to" date ranges can be specified as e.g. 2009, 2009-02,
>>> 2009-02-10, 2009-02-10 02:00:00. limit/offset/parameters/etc.
>>> specified here:
>>> https://github.com/wfn/torsearch/blob/master/docs/onionoo_api.md
>>>
>>> (Descriptors/digests aren't currently included (I think they used to),
>>> but they can be, etc.)
>>>
>>> The point is probably mostly about "this is some evidence that it can be
>>> done."
>>> ("But there are nuances, things are imperfect, time is needed, etc.")
>>>
>>> The question really is regarding the actual scope of this rewrite, I
>>> suppose.
>>>
>>> I'd probably agree with Karsten that just doing a port of the
>>> ExoneraTor functionality as it currently is on
>>> exonerator.torproject.org would be the safe bet. See how that goes,
>>> venture into more exotic lands later on maybe, etc. (That doesn't mean
>>> that I wouldn't be excited to put the current backend to good use,
>>> and/or use the knowledge I gained to help you folks in some way!)
>>>
Regarding your comment about storing a copy of every descriptor ever
>
Re: [tor-dev] Run a Small Tor Network for a Research
On Jun 24, 2014, at 7:59 AM, Karsten Loesing wrote: > On 24/06/14 12:55, Soroosh Sardari wrote: >> I want to run a small tor network with only 3 node, entry, router, and exit >> node. >> Also I want to set this three nodes in the client node without using >> directory server. > > https://www.torproject.org/docs/faq#PrivateTorNetwork > > Running without a directory server won't work, and you also cannot > define in which position your nodes will be used (except for the exit > position where you can simply reject *:*). > > Maybe start by going through Chutney's README, set up one of the > provided network topologies, and modify it until it does what you want. You might also consider Shadow. It contains a minimal topology and you should be able to get up and running quickly. You can get started here: https://github.com/shadow/shadow/wiki#tutorial and learn more here: https://shadow.github.io https://github.com/shadow/shadow Best, Rob ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Damian's Status Report - June 2014
Oooh summer. Pollen scratching my eyes and a fiery ball of death hellbent on frying me. We oughta nuke the sun! Teach that lazy, freeloading ball of plasma who's boss. Just think of all the savings on air conditioning! In those rare moments not staving off heat stroke I spent much of this month visiting family, and just a tad on code... * Stem 1.2.0 introduced a couple version compatibility regressions, the first with python 3.x [1] and another with python 2.6 [2]. Both received hotfixes, bumping us now to version 1.2.2. * Karsten and I discussed a Python rewrite of ExoneraTor at length [3]. While this would be a pretty fun and interesting project, its relative impact compared to other things I have in the works right now isn't especially high. * Reviewed Stem usage in Kai's DetecTor project. [4] Recently I shifted my focus back to arm. I've been truly impressed at the level of interest in it on IRC! New arm users are appearing almost daily, and I owe them a shiny new release! [1] https://trac.torproject.org/projects/tor/ticket/12185 [2] https://trac.torproject.org/projects/tor/ticket/12223 [3] https://lists.torproject.org/pipermail/tor-dev/2014-June/006970.html [4] https://lists.torproject.org/pipermail/tor-dev/2014-June/006965.html ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Who shall we send to the GSoC reunion?
Well, questions pretty straightforward, and I didn't get selected via the lucky draw, so I was thinking of alternative ways to get there! ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
