Some questions answered.
Hey everyone! I'm Derek from the OSTIF and here's some answers to the questions that were asked above:
On the windows environment path problem: If an attacker is able to edit the Windows environment path, the system is already completely compromised. Therefore it does not enhance security to use the solution suggested.
On the entropy gathering problem: Stalling due to a lack of entropy in virtual systems is better than using poor entropy sources. OpenVPN does try to partially mitigate this by using a hash PRNG instead of OpenSSL when it is handling non-sensitive information that requires entropy. It will not use weaker entropy to solve the issue globally, though.
On which platforms were covered by the audit: Cryptography engineering analyzed the 2.4.x master source only. QuarksLab and OSTIF analyzed the master source, the Windows specific source, the linux specific source, the Windows tap driver, and the Windows GUI. We planned to cover the OpenVPN for Android app as well, but ran out of time due to significant amounts of time reviewing and documenting the code paths for the other branches. While OpenVPNs code is generally good, the documentation is poor and could use a large scale effort to update the documentation for the application and the protocol. This means that code specific to OpenVPN for Android, code specific to Tunnelblick, and OpenVPN Connect for Android, as well as OpenVPN Connect for iOS were not reviewed. (OpenVPN Connect is based on OpenVPN 3.x code which has different licensing and significant amounts of rewritten code).
The audit covered the source for operating in both client and server mode, using both OpenSSL and PolarSSL (mbedtls).
Biting the hand that feeds IT
