On Fri, 16 Oct 2015 15:03:49 +0200 Rob van der Hoeven robvanderhoeven@ziggo.nl wrote: [snip]
Because the network interception takes place at the IP-level, no special Tor configuration is needed. In theory all TCP-clients should now be able to use the Tor network.
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).
Why did you write your own IP/ICMP/TCP (partial) implementations instead of using something like lwip?
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 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). * Things will break/perform poorly if there ever is loss on the TUN interface (Unlikely, I know). * Out-of-order but in window segments are discarded, instead of stashed for use later. * No slow retransmission timer. * The implementation does not ACK enough. Send a dup. ACK when you receive something that's Out-of-order but in window.
Probably doesn't matter much since the stack is never exposed to a public network and is only ever within the confines of a single host.
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.
Of course I am also interested in bug-reports and your ideas for improvement.
Code looks fairly clean. I'd feel better if it was in a memory safe language, but I like C/C++11 more than all the new popular stuff so I probably would have made a similar decision.
Should be easily portable to the U*IXes, Windows will give you pain, but I'm not sure you care. I assume you use version control for the code and are just not exposing it to the world.
Regards,