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
