On Fri, 2015-10-16 at 15:31 +0000, Yawning Angel wrote: > Cute. The networking part works in a near-identical manner Orbot's > Android VPN mode, under the hood, except they opted to use a 3rd party > implementation (that bundles lwIP IIRC). >
Interesting... > Why did you write your own IP/ICMP/TCP (partial) implementations > instead of using something like lwip? 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. > 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. - 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. > > The second question I have is: are there programs / protocols which > > should be blocked by avne? For example: I think its a bad idea to > > support unencrypted POP3. > > I think users should be allowed to shoot themselves in the foot if they > want to. "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. > 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/ Regards, Rob. https://hoevenstein.nl _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
