On 12 May 2015 at 07:23, Andrew Sullivan <a...@anvilwalrusden.com> wrote: > If the Tor Browser has its own resolver that is used just by it and > that is not a separate service installed with the expectation that > other clients will use it, then it seems to me the built-in Tor > resolver is part of the application, even if it happens to be built > out of components that _could_ be a name resolution API or library in > the general case. It is definitely my impression that (for instance) > the Onion Browser installed on my iphone doesn't provide services to > other applications, and has its very own resolution system as a > result. That suggests to me that there's more than one way to do > this, and one of those ways is for the application to be special. > It's not the only way, though, I agree.
Like you say there are a multitude of ways to do it, and there are examples of most of them: The tor daemon (often called little-t tor or just "tor") is a daemon running on the OS that exposes a SOCKS service for anyone who speaks SOCKS to connect to. You can point an unmodified browser at it, and access .onion services. [0] This is also how OrBot works on Android! You can configure little-t tor to act as a DNS resolver, point /etc/resolve.conf at it, and have all your DNS queries go through tor, but not any of your actual traffic.[1][2] You can use iptables and transparently proxy non-SOCKS traffic through tor as either the main mechanism for internet access or as a backup to prevent anything from not going through tor. TAILS and other anonymous LiveDVD systems do this, and OrBot on Android supports this mechanism also, if you have root access. You can use TorBrowser, which bundles little-t tor, uses the SOCKS access method, and requires no configuration to access .onion services. You can use a SOCKS aware program to access .onion services (or the Internet) using TorBrowser's bundled tor, which is how Pond works. Shutting down TorBrowser closes the connection to .onion services, and Pond is stranded. You can create a bundle, like Onion Browser on iPhone, which does _not_ allow other applications to make use of the bundled daemon. -tom [0] As mentioned, this is a wholly insecure way to access sites anonymously, as there are ways to a) get your real IP address b) link you between TLDs c) correlate your browsing sessions and d) fingerprint you uniquely. [1] This is kind of a nifty way to get DNS privacy. [2] If you attempt to resolve a .onion this way (as opposed to letting SOCKS resolve it), this is the response: dig @127.0.0.1 -p 5353 facebookcorewwwi.onion ; <<>> DiG 9.10.1-P1 <<>> @127.0.0.1 -p 5353 facebookcorewwwi.onion ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41248 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;facebookcorewwwi.onion. IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.1#5353(127.0.0.1) ;; WHEN: Tue May 12 09:31:31 EDT 2015 ;; MSG SIZE rcvd: 40 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
