OpenVPN Support Forum

Guys, needless to say the privacy becomes more precious everyday, with the introduction of privacy invading systems from all vendors, like Microsoft's TMG, Cisco's SCE, and only god know what else...

So, I'm planning to implement the port hopping in OpenVPN, where the communication port changes as a function in time according to a sequence/algorithm pre-agreed upon between the client and the server...

I've already given the guys a visit on IRC:

23:11:21 <samehshaker> hello there everyone, I've an idea for a new feature, and I'd like to know where should I start to have it implemented....
23:11:36 <samehshaker> I was thinking for the past few weeks about port hopping....
23:11:59 <samehshaker> where the port for the communication changes as a function in time....
23:12:43 <samehshaker> I have some ideas about implementing it, like it would be much easier to have it implemented on the UDP connections....
23:13:22 <samehshaker> the algorithm the new random port to be selected...
23:13:29 <samehshaker> stuff like that....
23:13:52 <samehshaker> any tips on where to start will be great...
23:17:09 <krzee> you might want to put it on the wishlist section of the forum, and mention that you develop and are interested in doing it but need a push in the right direction

So, what do you think ???

[02:47] * dazo wishes samehshaker didn't log out ...
[03:38] <cron2> indeed
[03:38] <cron2> what he wants is quite far away from "have minimal impact"
[03:40] <dazo> and not possible to implement as a plug-in for sure
[03:40] <cron2> and no threads yet
[03:40] <dazo> heh
[03:41] <dazo> well, before looking at the real code, it does sound that easy and simple though
[03:41] <cron2> nothing related to "listening on multiple ports" is ever "that easy and simple"
[03:44] <dazo> heh ... that's very true ... I didn't think that far into the code path .... still in the waking up process ...
[03:45] <cron2> and then things like "reliable port change in the face of packet loss"...
[03:45] <cron2> all doable, of course, and very interesting challenge, but far from trivial...
[03:45] <cron2> (we could even change between IPv4 and IPv6 transport in the middle of an ongoing session...)
[03:46] <dazo> that would actually be an awesome feature .... "hey, you got IPv6, lets use that instead!"
[03:46] <cron2> mmmm, SCTP transport...
[03:47] <dazo> hmm
[03:48] <dazo> well, could become a mess to firewall though ... unless you define very well in the config what's allowed and not
[03:49] <krzie> [03:41] <cron2> nothing related to "listening on multiple ports" is ever "that easy and simple"
[03:49] <krzie> thats not what he wants
[03:50] <krzie> we established listening on multiple ports is a bitch to impliment and wont happen til v3
[03:50] * cron2 still has it on his roadmap for 2.3
[03:50] <krzie> he wants to change the port that the tunnel operates on randomly as agreed by both sides
[03:51] <krzie> on cool, if you get that done it would be very very awesome
[03:51] <krzie> didnt know that was being worked on!
[03:51] <cron2> krzie: that's much harder, as you need to listen on both ports for a while (think "packet loss")
[03:51] <dazo> krzie: yeah, and that includes listening to multiple ports on the server side
[03:51] <cron2> krzie: well, it's not yet "being worked on", but I want to have it, and things happen faster when I implement them myself
[03:51] <krzie> cron, during reneg traffic stops except the renegotiation, seems like a good time to do it
[03:52] <krzie> when it restarts, it goes over the new port =]
[03:52] <cron2> it might need to fall back to the old port in case the new port doesn't go through a firewall...
[03:52] <dazo> krzie: but also think about the server side in a p2mp ... with multiple clients ... all negotiating their own port numbers individually
[03:52] <krzie> if both sides attempt communication it would punch through firewalls
[03:53] <krzie> server side would need to force the port then
[03:53] <cron2> if the fw permits "random port" traffic
[03:53] <krzie> true, that would break his idea
[03:53] <krzie> so those couldnt use it
[03:53] <krzie> it wouldnt be for everyone (i wouldnt use it)
[03:54] <dazo> yeah ... I am administering firewalls which also have restrictions on outgoing ports ... so it's not for all, for sure ... but it again depends on the config flexibility
[03:54] <krzie> true, maybe he could have a range or something
[03:54] <dazo> yeah, that will do a lot

well, as I'm working in an ISP, I got the chance to have a look what ISPs can do spying on their users and invading their privacy, my main goal behind implementing port hopping is keeping my (or any user's) traffic away from the spying eyes of nosy ISPs in a way that makes it almost impossible to guess which server/service/port the user is being connected to...

I've been inspired for using port hopping by the spread spectrum technology used in wireless telecommunications; esp. frequency hopping, that makes the signal almost impossible to jam/trace ...

Usability from behind firewalls isn't my point at all, because after all it doesn't make much sense, I want to implement it for those who are worried that their ISPs (or some other entities) might be spying on them ...

1st thoughts were to make it work with UDP connections only as it's the easiest thing to do, you don't have to SYN/ACK before you start sending traffic through the socket...

I was also thinking about writing it in C++ as a plugin, since C++ is where I truly shine, adding a hook for the plugin to get it involved in the reneg process, and probably taking care of new socket creation, and migrating the traffic from the old socket to the new one, as well as doing the cryptographic work needed for a true port hopping implementation ...

Sounds like too much to do, but hey, the privacy is defiantly worth it...

Do you guys have some diagrams/charts for how OpenVPN works ?? can you please share it?? it would make it much easier to dive into the code ...

This sounds like something to discuss in terms of OpenVPN 3.0. There is talk of a lot of changes, including a lot of modularity. The level of modularity really depends upon use/test cases, and this is a good one. Perhaps spend some time in #openvpn-devel, talk to the developers, and get more involved now as getting involved later is only going to be a detriment.

What he's talking about is done by the US Military in SINGARS radios and is known as Frequency Hopping Spread Spectrum. The way the Military does it is by pre-generating the fill sets, which is a big list of the possible frequency's. All the SINGARS connect to a network master SINGARS, this is very important because the network master controls the timing and all the others must sync their timing sources with the network master. This isn't HH:MM:SS timing, its a number that starts counting when the master is turned on and all the other ones must be synced to this number +/- 1 second or so. Everyone is also using the same encryption key so the sync is done encrypted, even the fill sets can be sent over the air once the encrypted session is setup.

In network terms it means there must be a predefined list of possible ports configured on the server side. When the server daemon starts up it must read that list and randomize the duration for each port. The client must first connect on a default prearranged channel, establish a session, sync its own time source and receive the list, then disconnect from the primary session and reconnect on the next timed session. Could probably code it so that it wouldn't actually drop the session as just switch the ports it's communicating on.

I think the solution to the listen to multiple ports problem is that you listen to all configured ports but ignore any packets not received on the right port at the right time. You will get dropped packets, no real way to get around that without weakening the security concept. Could probably time the port switch's with the SSL rekeys.

On the server side, it's simple. Just put an iptables DNAT (or its equivalent) to map the ports to the openvpn daemon's actual bound port. Of course this means that you have to know the port ranges a priori, and they can't be used by anything else.

So this works best if you've got a spare IP (let's call it OVIP). Simply DNAT all UDP traffic destined to the OVIP to your main IP's openvpn listening port. Now the destination port (server side) is irrelevant; it just gets rewritten anyway.

Also, this is a dead-simple way to enumerate and bypass egress filters. Simply nmap -P0 -sU OVIP, and if anything responds, that port isn't being filtered outbound. Then reconfigure openvpn to use that dest port.

In radio, FHSS has useful properties; a fast hop spreads the time-averaged signal over the frequencies, meaning that it's hard to detect (LPD) with a slow spectrum analyzer, especially if it drops below the noise floor, and it tends to suffer only a little in the face of narrowband RFI. If you don't have a broadband reciever/recorder, or you have the hopcodes but only have a slow hopping receiver, it's hard to intercept (LPI). But those don't really apply too much on IP networks.

Still, it'd be neat to see.

That got me thinking, this could be possible with some really fancy shell scripting and firewall configuration. That shell script could be used to rotate the ports traffic travels OUT on to the remote end. To further hide information, netcat could be used on either end with SSL to configured timing, and the server side, rather than using a firewall rule to listen on all ports, could be set up to only listen on the proper port for the current cycle.

Would be better, imho, if it was done within openvpn, but this would be relatively simple to do with something like pf on Free/Open BSD using tables.