We’ve had comments from a handful of users who have heard that “IPSec is more secure than OpenVPN.” While this is incorrect at its basic premise, we wanted to address this with more details in order to help our customers understand the reasons why.
Part of the issue has to do with what type of certificate is used in the implementation of IPSec or OpenVPN. Generally, VPN providers do not use root-CA-signed certificates. The weaknesses in public-cert exploits are because criminals/governments are able to gain access to root CAs. Because DarkWire VPN does not use root CAs, and we are our own CA (which is standard in the VPN industry) we are not susceptible to the same issues in the same way.
The author of OpenVPN is James Yonan. He started with the spec of IPSec and admiration for its strength of security while developing OpenVPN. The encryption algorithms, key choice algorithms, and key exchange algorithms are nearly identical between IPSec and OpenVPN, but the problem with IPSec has always been a tremendous amount of overhead in dealing with users/certificates. Whole industries developed around producing software to manage keysets for IPSec. In short, it’s a nightmare administratively and support-wise to do IPSec right (which means issuing proper certificates for all users), and in the effort to make things simpler, many commercial VPN services have opted to do things incorrectly and use nothing more than a short, simple PSK for securing their IPSec service. So basically once you have an account with them, and a username and password with their PSK, you’re in. The strength of using large keys is lost. So IPSec has the underlying power to be super-secure, but the final implementation of most VPN services do not make any use of it.
At the same time, it’s also possible to build OpenVPN systems which are also lackluster in their security. You can setup OpenVPN with null certificates, or with a shared-PSK among all users, and get users on very quick and easy. In this case, it offers no more or less security than IPSec in a similar style of configuration. What is most important is not the specific protocol or software, but how well it was configured.
One of the things which set IPSec apart from the beginning was the ability to use HMAC authentication of each packet. What this does is make it so that if a packet arrives, attempting to look like an IPSec packet, the packet must be signed with a specific key. If the packet is supposedly “ok” but is not signed appropriately, it is dropped without any further processing. OpenVPN has the exact same thing, and we have configured our instances of OpenVPN the same way. Unsigned packets arriving on the OpenVPN port attempting to “masquerade” as a valid packet are dropped. This serves double-duty as both a security measure as well as a denial-of-service mitigator.
The keys you get in your config file for OpenVPN are session-initiation keys, to secure the exchange of data between client and server. However, once the session is begun, “ephemeral keys” are generated and live for a maximum of 1h before being thrown away and re-generated on each side. In so doing, an attacker would need not only to obtain the session-initiation keys, but also be able to discern these ephemeral keys in order to decrypt the data stream. Again, the use of ephemeral keys is a common tactic used in both IPSec and OpenVPN, further showing how closely related the two are.
However, the two diverge rapidly at what you see from the packet perspective. With IPSec, no thought was ever given to the concept of hostile governments trying to stop the proliferation or use of encryption technology. Here, IPSec falls woefully short of some very real needs. First, it uses specific packets that are neither UDP nor TCP: they are packets that have an IP source and destination, but only a protocol number as the identifier. Namely, these are protocol number 47 (AH, the authentication header) and 51 (ESP, the encapsulated security packet). It also uses a fixed port numbers of 500/udp and 4500/udp. On most implementations of IPSec, changing or altering the port numbers is impossible or nearly-impossible and creates utter nightmare situations if you try to deploy this to a customer base. For a hostile entity, blocking protocol numbers 47 & 51, and udp port 500 & 4500, is trivial. In fact, block just one of them and all IPSec comes to a screeching halt.
Also, as an aside, this use of AH & ESP packets also lends to IPSec not being able to have multiple users behind the same IP. You can’t tell a portless protocol like AH & ESP to go to another port/IP (ie NAT’ing) since there is no such thing in that protocol. There are ways, of course, of doing net-to-net IPSec to avoid NAT issues, however that is not the mode of operation for end-users in general. The typical phone, tablet, or laptop has no concept of establishing a net-to-net relationship with an IPSec server (or peer, in that case), but is intended to be just for individual use. For those organizations who wish to do a net-to-net, or point-to-net topology with our services, we can do that as well with our OpenVPN service. OpenVPN lends itself very easily to any possible configuration of point-to-point, point-to-net, or net-to-net.
For years, in the VPN industry, we used a variety of techniques to do “port hopping” with OpenVPN. When one government decides they don’t like a given port number, we hop to another port number and run OpenVPN there. This worked for a while, until certain countries developed highly-scalable routers which would recognize OpenVPN handshakes (as well as any other VPN handshake) and then drop the handshake packets. At that point, the ability to successfully port-hop went away in those countries, and most VPN providers simply stopped providing OpenVPN or went, literally, backwards to VPN technologies like Cisco AnyConnect or PPTP, which have known, serious flaws, and which can be decrypted nearly-realtime by the authorities. Because these flaws are so bad, the host countries were letting them through, because it was basically giving the illusion of security while they knew they could decrypt any user traffic they wanted at will. These other VPN services, unfortunately, thought “Hey, our stuff is now getting through!” and let their users continue on, all the while their data no more secure than plain text.
DarkWire VPN’s Premium service has ways of working around these limitations.
Hopefully this article will underscore the differences and similarities between IPSec and OpenVPN, as well as to strongly underscore why our OpenVPN service, in particular, is fundamentally different from the other competitors out there.