[tor-dev] Another Virtual Network Environment needs your I/O

Yawning Angel yawning at schwanenlied.me
Sun Oct 18 14:43:03 UTC 2015

On Sun, 18 Oct 2015 13:08:01 +0200
Rob van der Hoeven <robvanderhoeven at ziggo.nl> wrote:

> When I was researching my idea I came across lwIP and was planning to
> use it. Unfortunately I could not find documentation. It's not on the
> project homepage and the wikia pages were not helpful too. What I
> needed was the info provided by the lwIP paper by Adam Dunkel. Found
> this paper yesterday trough the wikipedia article about lwIP.
> I always try to understand a technology that I use, even if I use an
> implementation by someone else. So I studied the TCP protocol. From
> this I got the idea that a full TCP protocol implementation was not
> needed to correctly handle *my* tun traffic. Writing a simplified TCP
> protocol would give me some major advantages: perfect integration
> with my design and no extra external dependencies.

Sounds reasonable, and yeah the lwIP documentation isn't great.

> > As your blog post notes "There are still some loose ends", most of
> > these should be known issues (From quickly skimming the code, there
> > is  
> Fair enough, the loose ends are:
> - The proxy uses two connections, an upstream connection and a TCP
> connection. If one of the two connections closes, the other connection
> is closed immediately. There is however a (very?) small change that
> there is still data in a buffer that must be written to the open
> connection. The open connection should close after this data is
> written.

Fairly easy.

> - Needs more testing. I have tested the program in a loose way. For
> hours and hours I have watched YouTube videos, visited nasty websites
> (lots of advertisements, scripts and simultaneous connections), and
> downloaded very large files using WGET. Everything seems to work, but
> *seems* is not enough it most be *proven* to work correctly. 
> - No unit tests.  
> > a possibility I've missed things or I'm wrong):
> > 
> >  * No IPv6.
> >  * No congestion control (TCP Tahoe is fairly trivial to implement,
> >    and would be more than sufficient).  
> Congestion control is used to prevent dropped segments. This can not
> happen on the User Space <-> kernel connection of a tun interface. The
> TCP-window flow control prevents this. 

Hm.  Your code never shrinks the advertised window, and ACKs once when
data has been added to the receive buffer.  As a perfectionist for such
things, this makes me really sad, but since it the stack never sees the
light of day outside a TUN interface, the behavior is probably ok.

As a side note, the TUN driver will happily drop packets once the
backlog exceeds 500 or if a skb allocation fails.  Both unlikely, both
can happen.

> "Want to" implies that the user is aware of the danger. Most users
> have no idea about the dangers of using a particular protocol over
> Tor. I want to protect these users.

Fair enough.  I'd suggest this be configurable behavior.  See
`WarnPlaintextPorts` in the tor manpage for what should be a sensible

If you want to protect users from danger, you'd probably also want to
disallow port 80 and 443 by default, because they're giving up a lot by
using what is probably the Wrong Browser[1].  They may even think that
viewing Flash/Java content is safe, when neither are because the
plugins are all sorts of terrible.

> > Should be easily portable to the U*IXes, Windows will give you pain,
> > but I'm not sure you care.  
> I care, and I think it can be ported to Windows. Since there are no
> kernel namespaces, another way to force all traffic through the tun
> interface must be found. It can be done by using the Windows firewall
> like this:
> https://community.hide.me/tutorials/bind-your-connection-to-vpn-with-windows-firewall.49/

Guess you'll use the OpenVPN TUN/TAP driver?

Some more random things:
 * PSH is set incorrectly.  You set PSH when you're ACKing received
   data (without piggybacked payload).  You're supposed to PSH as part
   of sending data to the peer (See RFC 1112
 * DNS resolution does not work if /etc/resolv.conf points at
   This probably is a documentation thing rather than a code thing.
 * I couldn't figure out how to get X apps to work at all.
   (Eg: chromium fails with "Gtk: cannot open display: :0")
 * There should be documentation that this requires a minimum of
   CAP_SYS_ADMIN (for the various unshare() calls) and CAP_NET_ADMIN (to
   bring the tun interface up).
 * The config file load/parse routine has a trivially exploitable
   buffer overflow.

Yawning Angel

[1]: Tor Browser would be the Less Wrong Browser.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151018/396e3c35/attachment.sig>

More information about the tor-dev mailing list