DNS tunneling transport (like iodine, dnscat)

DNS-based pluggable transport.

Encode data in recursive DNS queries and responses. Your local recursive resolver sends your packets to the right place. A DNS bridge would be an authoritative name server for a particular domain; users would configure a domain rather than an IP address in their Bridge lines. Tools already exist to do DNS tunneling, for example ​iodine and ​dnscat. Probably requires a reliability layer and periodic polling by the client.

Provides a way for users behind restrictive firewalls to connect to Tor at the expense of speed.

Mailing list discussions: [tor-dev] obfsproxy dns transport ​https://lists.torproject.org/pipermail/tor-dev/2014-February/006250.html (Feb 2014)

using OzymanDNS to access Tor via DNS ​https://lists.torproject.org/pipermail/tor-talk/2006-January/007124.html (Jan 2006)

added DNS component::circumvention/pluggable transport hard ideas iodine priority::medium severity::normal status::new tor tunneling type::enhancement labels

Trac:
Component: Tor to Pluggable transport
Owner: N/A to asn

Trac:
Keywords: DNS iodine tor tunneling deleted, DNS iodine tor tunneling ideas hard added

I'm not totally sold on this being a good idea. There's a gigantic mountain of research regarding detecting such things, so I don't expect it to have a very long shelf life, there's interesting implications of caching intermediary resolvers being able to enumerate bridges fairly easily, and the performance would be rather poor.

http://eprints.eemcs.utwente.nl/23518/01/10.1007_978-3-642-38998-6_16.pdf http://arxiv.org/ftp/arxiv/papers/1004/1004.4358.pdf

Don't let my predictions of doom and gloom discourage you from writing this and investigating it further, but my initial reaction is, "very well analyzed by adversaries, there's code out there to detect and censor this approach to circumvention, the implementation would be fairly complicated, for extremely poor performance".

But! There are many use cases and threat models. A DNS-based transport might be nice to get out from behind a wi-fi captive portal, for example, even if it is vulnerable to a nation-level censor. I would find it valuable to have a DNS tunnel into Tor that I can configure with only a bridge line, as opposed to setting up a tun device or whatever, which I have always found difficult.

DNS could also be interesting for rendezvous (like flash proxy) or for dynamically fetching bridge addresses.

Replying to dcf:

But! There are many use cases and threat models. A DNS-based transport might be nice to get out from behind a wi-fi captive portal, for example, even if it is vulnerable to a nation-level censor. I would find it valuable to have a DNS tunnel into Tor that I can configure with only a bridge line, as opposed to setting up a tun device or whatever, which I have always found difficult.

Sure. And it'll be fun to write. Not sure how many of the captive portal implementations out there don't do DNS hijacking currently, so it's probably more usable than the existing literature would suggest.

DNS could also be interesting for rendezvous (like flash proxy) or for dynamically fetching bridge addresses.

I would be fully interested and supportive of these sort of use situations since it's less blatant when used as an extremely low volume covert channel, and we are looking into auto-bridge distribution.

The original text was at: https://trac.torproject.org/projects/tor/wiki/doc/DnsPluggableTransport

Relevant links: https://github.com/iagox86/dnscat2 https://github.com/FedericoCeratto/dnscapy https://github.com/yarrick/iodine https://github.com/mdornseif/DeNiSe

Irvin Zhan wrote a working prototype transport in 2015, built on top of dnscat2. The project report is here: https://www.cs.princeton.edu/sites/default/files/uploads/irvin_zhan.pdf The source code of the transport used to be at https://github.com/izhan/dnstun_pt but as of 2015-01-26 it is 404.

Trac:
Severity: N/A to Normal
Sponsor: N/A to N/A

fyi the max throughput of solutions like this usually are not more than 10KB/sec. that may be useful only in very strict environments.

Trac:
Username: 6h72Q484AddGha8H
Reviewer: N/A to N/A

Why not just use tor over iodine?

Trac:
Cc: N/A to dmr

asn does not need to own any obfuscation tickets any more. Default owners are trouble.

Trac:
Owner: asn to N/A
Status: new to assigned

tickets were assigned to asn, setting them as unassigned (new) again.

Trac:
Status: assigned to new

Replying to dcf:

Irvin Zhan wrote a working prototype transport in 2015, built on top of dnscat2. The project report is here: https://www.cs.princeton.edu/sites/default/files/uploads/irvin_zhan.pdf The source code of the transport used to be at https://github.com/izhan/dnstun_pt but as of 2015-01-26 it is 404.

Today (2019-12-05) the link is working again. https://github.com/izhan/dnstun_pt Also phw has a fork: https://github.com/NullHypothesis/dnstun_pt

Demonstration of running Tor Browser through the new dnstt tunnel: https://lists.torproject.org/pipermail/anti-censorship-team/2020-April/000080.html

First, get the tunnel client software and run it with the proper parameters. {{{ git clone https://www.bamsoftware.com/git/dnstt.git cd dnstt/dnstt-client go build ./dnstt-client -doh https://dns.google/dns-query -pubkey a8090ab2d7b918e69ed4b2340fcd9c2af33c08e3620af98fb9c6a460fb63f76d tor.rinsed-tinsel.site 127.0.0.1:7000 }}} You can replace "!https://dns.google/dns-query" with another server from [https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-available-servers].

Second, in Tor Browser, go to about:preferences#tor, select "Provide a bridge", and enter {{{ 127.0.0.1:7000 4D6C0DF6DEC9398A4DEF07084F3CD395A96DD2AD }}} tor will connect to 127.0.0.1:7000 as if it were a remote bridge, but that port actually leads through the tunnel to the ORPort of my bridge giygas.

mentioned in issue #29293 (moved)

moved to tpo/anti-censorship/pluggable-transports/trac#15213 (closed)