On Sun, 2015-10-18 at 14:43 +0000, Yawning Angel wrote:
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.
I never adjust the size of the TCP window, that's correct. The code only sends an ACK for data that is *removed* from the buffer. If data is added to the buffer, the amount of data the TCP-client is allowed to send decreases. Eventually becoming zero if no data is removed at all.
"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.
Good idea.
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...
Guess you'll use the OpenVPN TUN/TAP driver?
Yep.
One thing: At the moment I do not have the resources to work on a Windows version of the program. Creating a consumer-grade Linux version is my current goal.
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).
Ok.
- 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.
Maybe, I will look into this.
- I couldn't figure out how to get X apps to work at all. (Eg: chromium fails with "Gtk: cannot open display: :0")
Ah, your system probably uses an Abstract Unix Socket for communication with the X server. Abstract Unix Sockets are created inside a network namespace, and your X server socket lives inside the global network namespace. To solve this I have to write proxy code to create an X server socket inside the network namespace of the TCP client. Maybe you can temporarily solve the problem by binding your X server socket to a normal Unix socket? (filesystem Unix Sockets are not network namespace aware).
What OS (name+version) are you using? I'm using Debian Wheezy which does not have this problem.
- 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).
AVNE is a suid program at the moment. To do the privileged calls the program runs (for a while) with root privileges.
I'm going to move to Debian Jessie. This version has a newer kernel that supports user namespaces. As I understand it (have not played with user namespaces), these can be used to create programs that can have full privileges inside the user namespace without having full privileges themselves. No more suid needed. The downside is that user namespaces are only available for kernels with versions >= 3.8
- The config file load/parse routine has a trivially exploitable buffer overflow.
The final config file will be owned by root and stored in /etc.
Good input Yawning!