Re: [tor-talk] SOCKS proxy to sit between user and Tor?

[Jeremy Rand <biolizard89@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/24/2015 08:54 AM, l.m wrote:
> Hi,
> 
> Is the Socks-to-Socks proxy absolutely necessary? This could be
> done as a browser plugin couldn't it? You might find the work of
> the FreeSpeechMe team interesting. They have the objective of
> integration with tor which sounds a lot like what you describe.
> It's probably not vetted to your standards (yet) but the source may
> be a start for tinkering.

Yep, as you noticed, I'm the developer of FreeSpeechMe.  (And thanks
for the mention -- happy to see that the project is being cited by
people such as yourself.)  FreeSpeechMe actually is a proxy, just
implemented in Javascript.  It's based on Convergence by Moxie
Marlinspike.  The original intention of using Convergence was that it
can validate self-signed TLS certs by using a non-malicious local
MITM.  However, that approach has high attack surface (as systems like
Superfish have demonstrated, although Convergence is much higher
quality implementation than Superfish and, as far as we know, hasn't
made any nasty mistakes).  Also, Mozilla seems to have wiped out the
API that Convergence was using to validate TLS (there might be ways
around this, I haven't thoroughly debugged).  Generally the
Convergence proxy was pretty hacked together and I don't like its
implementation.  It uses js-ctypes to call the NSPR and NSS libraries
that Firefox includes, and those libraries were never really intended
for extensions to access.  It's also unmaintained for quite a while,
and I got tired of fixing bugs in code that I had no familiarity with
and that used API's that I've never used (and, for that matter, almost
no one uses or documents).

We now have a new method of validating TLS (should be released soon)
that doesn't use a proxy and is much simpler.  However, this left us
in a position of having to find a new way to handle the DNS aspect of
Namecoin (both directing to IP addresses and .onion/.b32.i2p).  I do
have a proof of concept of a Namecoin DNS proxy using the mitmproxy
library (which we initially investigated as a TLS validation library,
but decided to avoid for that purpose because intercepting proxies
inherently have high attack surface).  The question is whether
mitmproxy is really the best way to do it, given that we originally
chose it for entirely different reasons than our current criteria are
(we don't care about TLS interception anymore, we just want a nice
well-maintained proxy).  mitmproxy is very well maintained, and fits
most of our requirements.  The mitmproxy developers have also been
very nice to us.  However, it's a fairly large library (due to the
interception capabilities that it has), and it's originally written
for pen-testing rather than end user usage.  Am I being overly
paranoid?  Maybe so -- indeed, we're calling a very small subset of
mitmproxy's functionality, and we explicitly disable all of the
protocol level processing that mitmproxy does; we configure it to
treat all connections as straight TCP traffic with no processing after
the SOCKS protocol has been processed.  So... it's conceivable that
mitmproxy is a good avenue, given our use case.  (It also helps that
mitmproxy is Python, and the code that we have for processing Namecoin
records is also Python, so that simplifies implementation
substantially.)  Do you think we should just use mitmproxy and spend
our limited engineering resources on other problems?

> Would I be correct in saying this offers an alternative over OnioNS
> in that it: - requires downloading the blockchain, so will not leak
> statistics associated with lookups

Yes, blockchains offer basically the best lookup privacy possible,
since lookups don't generate network traffic.

> - can be extended to a general petname system which maps
> personally chosen identifiers to known onion properties

Yes.  Indeed, the Namecoin processing library that we're using
(NMControl) has pluggable backends.  The default backend is to load
from the Namecoin blockchain, but there's another backend that loads
from a user-provided file.  So you could create a file that lists
names for .onion, change one line in the config file so that the file
backend is used instead of the Namecoin blockchain, and you've got a
petname system that provides the same API as Namecoin (and would be
usable by whatever I end up doing here).

> On that note: what are the advantages of namecoin (.bit to .onion) 
> over a petname system (id to .onion) or OnioNS?

Well, a petname system isn't deterministic between users.  So if I
provide you with a link to some petname, you won't know which .onion
I'm intending you to visit.  I think I2P tries to mitigate this by
letting people subscribe to feeds of petnames (I admit I'm not that
familiar with the internals of I2P), but it's not as good a solution
as Namecoin (which is designed to solve exactly that problem, i.e. the
Zooko's Triangle problem of deterministic, decentralized, human
readable naming).

Quite honestly, I haven't reviewed the OnioNS design thoroughly, so
I'm not really able to comment on it yet.  From what I do know, OnioNS
makes a design assumption that a quorum of Tor relays are honest,
while Namecoin makes a design assumption that a quorum of Namecoin
miners are honest.  The analysis of whether these assumptions are
valid is complicated.  However, a system like OnioNS cannot work in a
decentralized network; it's completely dependent on the Tor directory
authorities to prevent Sybil attacks, while Namecoin has reasonable
resistance to Sybil attacks without relying on a trusted third party
(a while back I calculated the cost of enough ASIC mining hardware to
overwhelm Namecoin, and it was nearly a billion USD).  Does that
matter in terms of applicability to Tor?  Not really; I don't think
Tor is going to become decentralized any time soon, nor does it need
to in order to continue doing well.  This argument is somewhat more
relevant to I2P, which doesn't have directory authorities, but that's
out of scope of your question.  In terms of the actual design of
OnioNS, I can't speak to it because I haven't reviewed it... so I
guess I can't really fully answer your question there.  But it's a
good question.

(Wow, this email is long... hope I covered everything.)

Cheers,
- -Jeremy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVYeQ6AAoJEAHN/EbZ1y06wukP/RYf23VEfvtSTfepd3CzTVA1
aHcu0mi2zrn1XK25INc40tR8ShXuk4vdO3sSN3Z/J2geXoQDmywYAsavVM05uWsc
wBOdDCV2gVUjMxPAW9Q+LWHirkpsggsYfat7KLi36rwCtbQuz4234RBNTxdFZLBt
/QVMrSW5gW6wpFd3WHqoG6GAi33di7eRG7uikfQHC5+SBCuDDUgV5HgvEAbFs1cV
eE6qCwIPn7NhrKv7Zy+IEruw8gOOr2zvgMDmYzN3PJNJcICOis+Bp+Ln5ZI1dAkn
5AREs47H9dvuJ9EWzGRk5ZeyJSb4YlZHLXri2aI4AsswySZzTOsA67xnlTfAFQLd
Frd3BBw8J9Q+BshaY4DG0XBj1X86qxl4EtnJbfqBMGStENS5Nf2+K8olH/7wPcL2
8rLOD9b16d/x2n0k0UlotK5yJHCcAPKZznmd6ZU/o/Sa58KkModzOvIzaJncodZx
eJZA4pIoEBUzylhKUuUMIPvofp+GELd1CG1wmiT9NIJZPe35p7zJLRbXG/Fd7hW1
ujm2NIKPEHS/JKE24fi3mJki56vGklHDGofzU/8XLFjRHmvOF6CEzwidJQjwdMAu
7q+arJo0mpOdEKyCPxbAMUfy/WiteVuTI18y+30hEnlmYyjVfEjKZ34VKLSy3qT7
z1CUcang3sh3FO4l+e7c
=SpXQ
-----END PGP SIGNATURE-----
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk