Am 25.03.13 13:20, schrieb David Sommerseth: > On 20/03/13 16:49, Siren 1117 wrote: >> Hi all, >> >> I modified the obfuscation patch to work with git-master. And I also put >> it on Github: https://github.com/siren1117/openvpn-obfuscation-release . >> >> Hope it could help someone. > Your patch still have not changed *anything* commented in this e-mail: > <http://thread.gmane.org/gmane.network.openvpn.devel/7285/focus=7293> > > I am in particular worried that you have not put any concern into the > RC4 comments. To seed you more on this topic, please read this one > (especially the "So what's wrong with RC4" paragraph): > <http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html> > > In addition, you have more in-depth info here: > <http://blog.cryptographyengineering.com/2011/12/whats-deal-with-rc4.html> > > Why am I concerned about this weakness when RC4 is only used for > obfuscation? Because if the encryption key is easily recovered, the > obfuscation doesn't really work. Any blocking firewalls of certain > sizes can easily add checks on for extracting this RC4 data and try to > retrieve the keys. This way they can detect the obfuscated OpenVPN > traffic, and decide to block it. You can of course change the key > again, but it's just a matter of time until the new key is retrieved and > your back at start needing to change the key even once more. And when > this is needed to be done in 10-15 minutes intervals, people will start > complaining about OpenVPN's non-functional obfuscation. This is a no-go! > > So please! Before submitting any more patches of this "RC4 obfuscation" > approach, come up with a better and improved solution - at least don't > ignore the weaknesses in RC4. > > And as I already said: The TOR project already have written good > obfuscation methods (obfsproxy) - learn from them! Then doing something > similar will make far more sense to include into OpenVPN. Reusing the > obfsproxy source code will even reduce the risk of errors and lessen the > maintenance of the OpenVPN code as well. I think the correct approach is to create a plugin mechanism that allows arbitrary connection methods like:
<connection> remote my.remote.bla xxxx connect-plugin obfuscate.so </connection> The plugin would then try to open the connection and return a fd to openvpn so that all the other is transparent for openvpn. This allows a good integration for stuff like obfuscation that can change quickly while providing a nice and clean interface for openvpn. Arne
signature.asc
Description: OpenPGP digital signature
