Tunnelblick created a patch for openVPN client and server which can hide your openVPN traffic from deep packet inspection.
According to tunnelblicks-an open source VPN provider for MacOSX The option can be useful to avoid having OpenVPN traffic detected by monitoring or censoring mechanisms such as the Great Firewall of China. The option "scrambles" each buffer of traffic before it is sent between the OpenVPN client and server.
The patch is attractive because it is so easy to implement: simply apply the patch to both the OpenVPN server and the OpenVPN client and add a single, identical option to the configuration files for each. Using obfsproxy is more complicated because it involves running another, separate program on both the server and the client.

But openVPN developer refused to add this. According to them we especially discourage using such an approach when there exists a far better solution, used by the TOR community. It is called obfsproxy and can be used together with OpenVPN without needing any re-compilation of OpenVPN.

My question is you already know that Tor is slow and when it is used with pluggable transport like obfsproxy or meek it becomes slower. Now openVPN developers also want us to use this then don't you think by adding a obfsproxy server, VPN will become slower as Tor? How is it a far better option?Is there any security reason they refused to add this?

Full article source can be read here

  • I don't think Tor is slow because of the pluggable transports. It's slow because of the way it transfers data. Pluggable transports may be slower, but it's most likely because the bridges running the transport have less bandwidth, not because of the actual transport. Oct 13 '16 at 16:47
  • @SuperSluether If you use pluggable transport to access tor then it becomes slower than it is without using PT. The reason you have mentioned why it is slow is definitely correct. Imagine if you were to use obfsproxy with openVPN you won't be able to browse with desirable speed. OpenVPN developers not only close that thread(xor implementation) but also deleted it. I thought to ask here the reason of rejection as most of the developers of open source community also hang around in stack exchange.
    – defalt
    Oct 13 '16 at 17:21
  • It's probably not incorporated upstream because it's A) terrible and B) would require VPN providers to use it and it would be trivial to defeat. It doesn't defeat DPI in any meaningful way, centuries old cryptanalysis would break it if it was done properly, as it stands it looks like it's far easier to break than that because it's done the stupid way. Whoever wrote this was an idiot and you should not attempt to patch their code into security critical systems. I'm also flagging this for closure since it's totally unrelated to Tor.
    – cacahuatl
    Oct 14 '16 at 2:16
  • 2
    I'm voting to close this question as off-topic because it's unrelated to Tor.
    – cacahuatl
    Oct 14 '16 at 2:17

The answer is in your question: it's a patch. Every good and popular Open-Source program has at least some really good patches, and they are not a-must-adopt ones. Just use them if you wish. For example - I have my own patch set for Tor, and I'm not thinking that when it will be released to public it will be adopted by the original Tor team.

  • The pity fact is that in the protocol itself there's no markers or another ways to determine - which "capabilities" are on both sides. From one hand - it guards against DPI, from another - it causes problems like this.
    – Alexey Vesnin
    Oct 13 '16 at 13:30
  • I understand that but if for one time openVPN developers had understood that patch implementation is better than using slow obfsproxy it would have solved filter problems by firewalls. I think there is a reason why they didn't and I hope someone here could answer that. Most of the time I only see you answering questions here.
    – defalt
    Oct 13 '16 at 15:27
  • Thanks on a good word! If you ever developed a network protocol and the DPI tools(which I did both), you'll see, that making a protocol "a Lego" is not a trivial task. Even more - such pluggability - if implemented straight-forward - makes it much more easily detectable by a DPI tools. I'm working on my own project of patches to Tor and other software, so find me in Facebook at facebook.com/avesnin and we can discuss the details in a chat and I'll be able to alert you when my software will be released. The subject is too broad and deep for a question here on this site
    – Alexey Vesnin
    Oct 13 '16 at 19:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.