Opened 4 years ago

Last modified 2 months ago

#15213 new enhancement

DNS tunneling transport (like iodine, dnscat)

Reported by: federico3 Owned by:
Priority: Medium Milestone:
Component: Obfuscation/Pluggable transport Version:
Severity: Normal Keywords: DNS iodine tor tunneling ideas hard
Cc: dmr Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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)

Child Tickets

Change History (12)

comment:1 Changed 4 years ago by nickm

Component: TorPluggable transport
Owner: set to asn

comment:2 Changed 4 years ago by yawning

Keywords: ideas hard added

comment:3 Changed 4 years ago by yawning

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".

comment:4 Changed 4 years ago by 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.

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

comment:5 in reply to:  4 Changed 4 years ago by yawning

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.

comment:7 Changed 3 years ago by dcf

Severity: Normal

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.

comment:8 Changed 2 years ago by 6h72Q484AddGha8H

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

comment:9 Changed 12 months ago by cypherpunks

Why not just use tor over iodine?

comment:10 Changed 9 months ago by dmr

Cc: dmr added

comment:11 Changed 3 months ago by teor

Owner: asn deleted
Status: newassigned

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

comment:12 Changed 2 months ago by cohosh

Status: assignednew

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

Note: See TracTickets for help on using tickets.