On 04/29/2012 07:01 PM, Jacob Appelbaum wrote: > On 04/29/2012 12:15 PM, Ondrej Mikle wrote: >> >> I wrote a HOWTO for DNS/DNSSEC over Tor with unbound+socat (IMHO if you're >> using >> unbound, drop ttdnsd altogether): >> >> https://labs.nic.cz/page/993/dnssec-validation-over-tor--linux-/ >> >> Click 'English' on top of the page if you get Czech version (it takes >> language >> preferences from headers sent by browser; Referer sending must enabled in >> browser in order the language switch to work). >> > > I'm the current maintainer of ttdnsd and I fully support using something > that isn't such a hack. > > I know that Paul Wouters and another unbound developer hacked together a > udp/tcp listener that only made outbound TCP connections. I think I made > some notes in the ttdnsd git repo at one point.
The 'tcp-upstream' together with 'forward-zone' settings accomplish that. > There was a patch that needed to be applied to unbound but I believe it > is now merged. If that is the case, I think that unbound and either > TransPort + iptables, socat, torsocks and unbound would be the best path > forward. That would work, but we need to deal with circuit correlation (from different applications). For example, your IM client will query: IN SRV _xmpp-client._tcp.nic.cz Now that single query will put you into a very small group, "tagging" all the other queries from the circuit. Not quite sure how much similar is it to viewing a little-visited site over Tor. >>> [1] https://lists.torproject.org/pipermail/tor-dev/2012-March/003341.html >> >> The above proposal/implementation will take a while to finish, I've run into >> some technical quirks that need to be resolved (in order to have it working >> reasonably fast and not shoot yourself in foot with some stupid design/coding >> mistake). >> > > Oh? So far I have the impression that every approach is like: "You might shoot yourself in the foot, but at least you can choose which toe it will be, if any." Short summary: 1. Circuit correlation, as in above example. We need some "demultiplexer" that would send unrelated queries over different circuits, e.g. a permanent mapping PID of querying application->SocksPort/TransPort, something along IsolateClientProtocol. 2. Deriving/guessing client's local DNS cache state from what queries are sent and which are skipped (i.e. what sites user visited already). Shouldn't matter too much for simple queries without many CNAMEs/DNAMEs in answer (typical RR has TTL in order of hours, thus clients are expected to requery). With queries having many CNAMEs/DNAMEs in answer spanning over multiple zones (various CDNs usually), it could leak some information. 3. Nick wanted to integrate libunbound event loop with Tor's event loop [2]. That will also influence round-trip time, especially in the cases with many CNAMEs/DNAMEs (many zones => many DS/DNSKEY queries). Issues 2. and 3. could be alleviated by something like Adam Langley's DNSSEC stapling [3], but the stapling is already complex enough and doesn't even take into account NSEC/NSEC3 yet. We're doing some mass DNS RR scans to get some statistics on things like sizes of responses, DNSKEYs fetched, number of zones traversed through CNAMEs/DNAMEs (hopefully the result will be better than "majority of men have above-average number of limbs"). >> That's also the reason I decided to try the "DNS as hidden service over TLS" >> approach. >> > > I think this doesn't scale very well but it's never the less quite > interesting as well! Aside from scalability, DNS hidden service is quite hard to hide (outside communication necessary) and there's the circuit correlation as well (so a demultiplexer sending to distinct DNS servers necessary). But it can be deployed without changes in Tor and a bug in unbound won't compromise Tor relay. I just thought - let's give it a try and see where it takes us. [2] https://lists.torproject.org/pipermail/tor-dev/2012-March/003360.html (comment under "5. Implementation notes") [3] https://tools.ietf.org/html/draft-agl-dane-serializechain-01 Ondrej _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
