On Sun, 18 Oct 2015 13:08:01 +0200 Rob van der Hoeven <robvanderhoeven@xxxxxxxx> wrote: [snip] > 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. [snip] > "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 list. 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 4.2.2.2). * DNS resolution does not work if /etc/resolv.conf points at 127.0.0.1. 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.
Attachment:
pgpGQbLfd3sZ_.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev