Hi, I think you should look into the pluggable transports documentation as I think it's exactly what you need. They use a socks implementation to redirect tor traffic and can rewrite the destination. I used it in my gsoc project fog: https://github.com/infinity0/fog On May 24, 2015 3:33 PM, "l.m" <ter.one.lee...@hush.com> wrote:
> Hi Jeremy, > > Thank you for the thoughtful and thorough reply! I think the users of > your software will appreciate you wanting to minimize attack surface. > One thing I've noticed about mitmproxy is that it appears to only > support SOCKS upstream proxies *without* authentication. It's also a > http proxy, so although it's certainly useful, it may not meet your > current requirements (in transparent proxy mode you'll exclude support > on Windows). I may be mistaken of course. > > If I understand correctly you intend to use the intermediate SOCKS > proxy to perform the translation of .bit address to destination > format. If the address doesn't require translation you'll pass it > through along with any authentication used for domain-isolation. The > downside of using an intermediate proxy is that you'll have an extra > dependency. The intermediate proxy needs to be modified to perform > lookups against a local resolver as needed. If proposal 229 [1] is > implemented you'll need to be aware of the changes. This may turn > into maintenance difficulty in the long run. > > If this were a regular browser you could always just setup the local > DNS resolver to forward if not resolving .bit addresses. Since this > is tor you need to make that resolver aware of tor being used, and to > use the SOCKS proxy instead (or tor-resolve). So maybe that's one > option. Have a local DNS resolver which forwards to tor after > checking the address (and turn off browser Remote DNS). That is to > say it might be easier to maintain your own resolver implementation > which can be kept as simple as you need. This would keep (some) > cross-browser compatibility, from TBB, to Firefox. The downside being > the whole system will rely on the resolver so you'll have to worry > about: conflicts with other local resolvers (dnsmasq, some vpn), or > need to set the DNS server manually. It looks like you do this > currently. If the local resolver wrapped all the related processes > you could make a UI available to indicate status. > > As a browser-plugin based alternative, maybe you can do without the > extra SOCKS proxy by a change to the plugin design. Say you use > Observer Notifications in the plugin. Now intercept the address and if > it ends in .bit make a request against a (local) server holding the > blockchain. This provides some flexibility in that you're not > restricted to using a SOCKS proxy. It should work with TBB. Unless I'm > mistaken (and I frequently am) websockets are enabled (check with > tbb-devs on this). An alternative approach would be to create your own > address bar for resolving addresses using the same approach previously > mentioned. There's a downside to this approach, in that if someone > were to use the regular bar, the resolve will be relayed using tor, > which might actually work if the exit DNS is setup to resolve > namecoin. > > Besides that, I'm only familiar with the SSH SOCKS proxy, and Tor's > SOCKS proxy. I can only look at the list of SOCKS servers on > Wikipedia, or HAProxy, as was previously mentioned, for other options. > > In any case, thank you for trying to make FreeSpeechMe compatible with > tor. > > --leeroy > > [1] > > https://gitweb.torproject.org/torspec.git/tree/proposals/229-further-socks5-extensions.txt > > -- > tor-talk mailing list - tor-talk@lists.torproject.org > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
