My recent posting about problems in some open-source VPN products generated quite a bit of mail, particularly after it turned up on slashdot (for the first time in years I got more real mail than spam). This is a followup to address some points arising from the original. In case people are archiving/re-posting the original article, please attached this as a coda to that. I'll also be putting up a long-term copy at http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_vpn.txt (linked off my home page) in the next few days.
The main purpose of the writeup was to point out that it's just as easy to create insecure "security" software with open source as with closed source, thus the title of the article. Microsoft took a fair bit of flak over their insecure PPTP implementation, but there are open-source alternatives that are just as bad. The article wasn't meant to be an exhaustive survey of Linux (or any OS in general) VPN software, since there's way too much of this around to cover it all. As with X window managers a few years ago, there are probably enough VPN packages around for every user to have their own personal one without much overlap. Just as with WMs, there will probably be a general shakeout leading to a smaller number of widely-used ones, driven by a particular environment (kwm driven by KDE, Sawfish driven by Gnome) and a large number of lesser-used alternatives driven by user preference. The problematic ones will still continue to be used for some time, for example Ed Gerck pointed out a Linux Journal article published only last month (Linux Journal, August 2003, p.84, http://www.linuxjournal.com/article.php?sid=6675) that recommends the use of vtun, the least secure of the three that I looked at, but hopefully the better ones will come to predominate. As with window managers, the same move towards a small number of standardised VPN apps will probably occur over time in the open-source community. Although I deliberately omitted mentioning them in the original writeup because specifically pointing to one particular implementation would be seen to implicitly exclude anything else and because predicting the future is always a dicey proposition, I'm guessing that the two major players will probably be Free S/WAN (http://www.freeswan.org/) and OpenVPN (http://openvpn.sourceforge.net/) or something very much like it, with Free S/WAN representing the IPsec approach and OpenVPN representing the SSL-based approach that I described in the article (to paraphrase Winston Churchill, "SSL is the worst way to build a VPN, except for all the others"). Free S/WAN, being an IPsec implementation, inherits all of the IPsec complexity that seems to have been the inspiration for the creation of several of the non-IPsec VPN applications. There are also quite a number of complaints from users that Free S/WAN is excessively difficult to use if you want anything more sophisticated than a straightforward setup using pre-shared static keys, more so than most normal IPsec implementations (please, no flamewars over this, I'm just reporting user comments and experience). There also exists an IKE-less IPsec implementation called ipsec_tunnel (http://ringstrom.mine.nu/ipsec_tunnel/) that uses the Linux (not Microsoft) CryptoAPI and that was also inspired by the difficulty in using Free S/WAN ("it was hard to understand and hard to configure"). OpenVPN is the "IPsec is too complex" alternative, running a TLS-protected dual control/data channel session over either TCP or UDP, with a reliability layer added for the control chanel if it's running over UDP. The manpage indicates that the data channel doesn't have this since tunnelling TCP will provide the necessary facility, but that makes tunnelled protocols without built-in reliability facilities vulnerable to message insertion or deletion. This could cause problems in cases where users assume that the use of a secure tunnel gives them this additional protection. A note in the manpage to indicate that OpenVPN provides only the same facilities as the protocol being tunnelled would be useful in clearing up any possible confusion. Overall, the choice of how to handle this is a tradeoff: You can either have protection against message insertion (strictly speaking, message replay), deletion, and reordering, but the first occurence of UDP unreliability will be detected as an attack by the security layer and the connection terminated, or you can have the ability to live with UDP's unreliability, at the cost of not detecting insertion/deletion/reordering at the VPN level. In terms of security, Free S/WAN is an implementation of the IPsec design and so should be as secure as any other IPsec implementation. OpenVPN uses OpenSSL's SSL/TLS for its control channel, and so should be as secure as SSL/TLS in general. For the data channel it uses encrypt-then-MAC with explicit IVs (these will be added to TLS 1.1), which is good. The key management step (that is, how to get from the SSL control channel to the data channel) is documented only in the source code, which I don't feel like reverse-engineering, but a quick look through it indicates that the author knows what he's doing. One thing that would be nice here is an RFC documenting a standard way to do this, to allow compatible implementations to be created by others doing SSL-based VPN work. Something based on experience with OpenVPN and other tunnelling implementations that may be around would be useful here (I'm currently bugging various people about this). My focusing on those two imlementations should not be taken to mean that everything else not mentioned above is insecure. I'm was aware of a number of other VPN implementations, but had no idea just how many there really were until people pointed a great many of them out to me in email, and I really don't have time to go through them all. Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
