What exactly do ipsec and ssl do?

Of the following solutions: PPTP, IPSec, SSL and EoIP, which is the most secure / preferable VPN and why?

• Answer:

  Short answer: IPSec and SSL VPN are generally your best bet. IPSec primarily for network to network and SSL VPN for user to network. Details below. EoIP is out since it doens't have *any* security features, not even rudimentary authentication. At least L2TP has that.  You didn't ask about L2TP, but it encapsulates L2 traffic via PPP it does ahve rudimentary authentcation and doesn't provide any encryption. Generally speaking, L2TP implementations rely on IPSec for cryptographic services. PPTP PPTP is out since the strength of the encryption mechanism relies on a username/password. We all know that username/passwords can be easily guessed. Also, the username and hashed password is transported over the network and can be sniffed for off-line cracking (assuming you have access to sniff the packets). Also PPTP doesn't have any key management features and has other problems http://www.schneier.com/pptp.html (some have been addressed, but not all). It is very easy to use, however. That leaves us with IPSec and SSL I'd say both are equally secure for the definition of protecting from eavesdropping and ensuring data integrity (encrypting and hashing). The real value is in the details such as choosing good algorithms and authentication mechanisms. IPSec IPSec has a number of interesting features that can be enabled primarily related to key management such as time or data key renewal for both the control and data channel, perfect forward secrecy, selected hashing/encrypting algorithms, and certificate based authentication. It's weakest when using pre-shared keys--a fancy name for passwords. It's best when using certificates. The authentication is multual. You can also define IPSec tunnel parameters to allow/disall some hosts or protocols. It's pretty flexible that way. While IPSec is a standard, it is not very interoperable and you pretty much use it between products from the same vendor. There are so many options that can cause a tunnel to break down, like handing a re-keying when a re-key is in progress, that it's imply not reliable among multiple vendors. Also, if your IPSec VPN is going to pass through a NAT device, then you need to encapsulate it into UDP,otherwise it will fail. For remote access VPN, the encapsulation is pretty important since you will likely be on reserved address space or behind a firewall that blocks IPSec traffic. IPSec works really well for network to network VPN when you have idea of the intervening network and can centrally manage the devices. SSL SSL VPN is particularly useful for remote user to network access since at layer 4, can pass through NAT unscathed and most networks pass HTTPS. SSL VPN is much simpler than IPSec. You can use it in the common served side SSL where the client authenticates the server via digital certificate and the server authenticates the client via username/password or client side where both peers use digital certificates for authentication. From that point on, it's just about ciphersuite selection. For anything other than HTTP traffic through a browser, SSL VPN does require agent software on the client computer to redirect application traffic over the VPN. SSL VPN is used primarily for client to network VPN and rarely for network to network, though there is no reason why it couldn't be used that way. I just don't think it has been productive in that fashion. I believe OpenVPN http://openvpn.net/index.php/open-source/overview.html supports network to network natively. Update: I just saw this report on "Debunking the Myths of SSL VPN Security: https://www.ncp-e.com/fileadmin/pdf/techpapers/Debunking_the_Myths_of_SSL_VPN_Security.pdf Many of the myths seem to be applicable to SSL in general (I read the article, but not deeply, so this is first impression). However, Myth #1 is most interesting to me. When an SSL VPN handles HTTP traffic, it acts like an HTTP proxy. In some cases, it modifies the host name of the URL. For example, you enter http://www.example.com and the SSL VPN redirects you to a new hostname http://webvpn.www.example.com or makes the original URL an argument as in http://webvpn.mycompany.com/q=www.example.com/%3Cwhatever%3E. Once that happens, all the browser protections like same origin policy are lost because any web site accessed over the VPN are, in fact, the same origin. Ooops. Anyway, that document seems like a good read. Note that if you are using SSL VPN as a network VPN--using an agent to redirect IP (not HTTPS), then the same origin issue does not apply.