-----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 - [email protected] To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
