On 23/01/13 14:42, 77 77 wrote: > On Wed, Jan 23, 2013 at 8:49 PM, David Sommerseth > <openvpn.l...@topphemmelig.net <mailto:openvpn.l...@topphemmelig.net>> > wrote: > > On 23/01/13 11:21, 77 77 wrote: > > Hi all, > > > > I wrote a patch to obfuscate OpenVPN's traffic to avoid protocol > > identification. Compared with other traffic obfuscation methods like > > using static keys or obfsproxy, it only adds one more config > parameter, > > and supports both TCP and UDP. If OpenVPN releases support this, > lots of > > devices will benefit from traffic obfuscation without installing > > additional softwares -- for exsample, the newly released OpenVPN > Connect > > for iOS or Openvpn for Android. > > > > The patch is based on openvpn-2.2.1, but works fine with > openvpn-2.2.2. > > Gert said one very important thing about openvpn 2.2. Even though, he > said to bring it up to openvpn-2.3 or git-master .... I'm saying > git-master is the natural point. If you need to have it in openvpn-2.3, > backporting it from git-master is far easier than going the other way. > > I've looked quickly at your patch. And the first instinct is that, > yes, this looks reasonably well. This is also a feature which I think > will be very useful in the coming future. > > > I hope OpenVPN be more connectively from every place, every device. My > friends and I have been using this patch for a while. > > > > Just a few comments ... > > - Have you looked at the obfsproxy project from TOR? That does pretty > much a similar thing and does work together with OpenVPN (but only via > TCP, as it uses the socks5 proxy mode of obfsproxy). Could it be > considered a better approach to integrate tighter against obfsproxy? > obfsproxy provides a more "plug-in" oriented approach where there > obfuscator logic can be changed at runtime, and doesn't necessarily > depend on a encryption/obfuscation key. What you basically do is to RC4 > encrypt the data. > > > The shortcome of obfsproxy is that you have to run the proxy along with > OpenVPN. If people want to use OpenVPN on mobile devices, it's easier to > use if we have in-place obfuscation ability. For example, OpenVPN > Connect is avaliable on iOS, but failed to connect from some > countries.
Just to make one thing clear. The OpenVPN Connect for iOS and Android are not using the same code base as the OpenVPN version you patched. Those use a completely new code base which has not been open sourced yet. > /In such circumstances obfsproxy can't help, but in-place > obfuscation would work./ I don't necessarily think that obfsproxy should be used with the socks approach as it is possible to do now. But rather look more into details how TOR integrates more tightly with obfsproxy. Or maybe contribute to obfsproxy so that it can be used as a library, linked into openvpn. > Currently, this patch *JUST* works. And I agree that a "plug-in" system > for obfuscation is more robust and easier to extend. And in the future, flexibility in obfuscation will be highly needed. It all depends on how many will make use of this feature and whom that will annoy most. But what you have done so far is a great Proof of Concept. It shows very well how to hook obfuscation into OpenVPN. That is highly appreciated work! I strongly believe in re-using as much code as possible, including not increasing the code maintenance. The OpenVPN developer's team isn't big, so we need to have code which will be easy to maintain many years into the future - including extending the obfuscation and security related issues. So depending on a more active project like obfsproxy is a big plus, IMHO. Please misunderstand me correctly ... I do like the idea of obfuscation in OpenVPN. And there have been several requests on such features already. However, when we implement this officially, it needs to be code which can live and be easily maintained in OpenVPN for many years. So that's why I'm taking the stance I'm taking. -- kind regards, David Sommerseth
signature.asc
Description: OpenPGP digital signature
