I had not looked at that file before, because I hadn't actually installed vtun, but now I have. I have also looked at the source code, including your 00-sslauth.dpatch.
VTUN DOES NOT USE SSL. It uses the Blowfish *cipher* from the OpenSSL library; it does not use the SSL protocol in any form whatsoever. Vtun can be built in two ways: "without SSL" which means it uses no encryption, and obscures its authentication procedure by XORing it with the password, and "with SSL" which means it encrypts tunnel data and authentication challenges with Blowfish in ECB mode, the weakest mode in which a cipher can be used. Availability of Blowfish is a compile-time option, which is enabled in this Debian package. Your "sslauth" patch adds a run-time option whose only effect is to make it possible to *disable* use of Blowfish in authentication even though it's available. This "feature" adds zero security. The other change made by the patch is to seed the rand() function using /dev/random rather than the current system time. This is a very marginal improvement, but does nothing to address the faults with the protocol itself. In summary: all the problems described by Peter Gutmann in his analysis (http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_vpn.txt), which I mentioned earlier, still exist in this patched version of vtun. My recommended resolution is to add the following text to the package's description: This program includes an "encryption" feature intended to protect the tunneled data as it travels across the network. However, the protocol it uses is known to be very insecure, and you should not rely on it to deter anyone but a casual eavesdropper. See the included README.Encryption file for more information. And please add a link to this bug report in the README.Encryption file. Alternatively, please consider removing the package from Debian entirely -- I don't see any good reason for shipping a VPN package with huge known flaws when a good one, OpenVPN, is freely available. (My apologies for the extreme delay between your comments and this reply. I had sent this message last September, but evidently it was eaten by my mail configuration at the time, because I just noticed now that it wasn't in the BTS.) -- Mike Paul <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
