IPsec and SSL
IPsec is a suite of protocols used to protect IP packets and has been around for decades. It is in use today for both remote-access VPNs and site-to-site VPNs. SSL is the new kid on the block in its application with remote-access VPNs. Let’s take a closer look at both of these options.
IPsec
IPsec is a collection of protocols and algorithms used to protect IP packets at Layer 3 (hence the name of IP Security [IPsec]). IPsec provides the core benefits of confidentiality through encryption, data integrity through hashing and HMAC, and authentication using digital signatures or using a pre-shared key (PSK) that is just for the authentication, similar to a password. IPsec also provides antireplay support. We take a closer look at IPsec in a later chapter, but here’s a good preview of the coming attractions:
ESP and AH: The two primary methods for implementing IPsec. The acronyms stand for Encapsulating Security Payload (ESP), which can do all the features of IPsec, and Authentication Header (AH), which can do many parts of the IPsec objectives, except for the important one of encryption of the data. For that reason, we do not frequently see AH being used.
Encryption algorithms for confidentiality: DES, 3DES, AES.
Hashing algorithms for integrity: MD5, SHA.
Authentication algorithms: Pre-shared keys (PSK), RSA digital signatures.
Key management: An example would be Diffie-Hellman (DH), which can be used to dynamically generate symmetrical keys to be used by symmetrical algorithms; PKI, which supports the function of digital certificates issued by trusted CAs; and Internet Key Exchange (IKE), which does a lot of the negotiating and management for us for IPsec to operate.
SSL
Transmitting information over a public network needs to be secured through encryption to prevent unauthorized access to that data. An example is going online to do banking. Not only do you want to avoid an attacker seeing your usernames, passwords, and codes, you also do not want an attacker to be able to modify the packets in transit during a transaction with the bank. It would seem that this would be a perfect opportunity for IPsec to be used to encrypt the data and perform integrity checking and authentication of the server you are connected to. Although it is true that IPsec could do all of this, there is not an IPsec client or software currently running on everybody’s computer. Even if there were, not everyone has a digital certificate or a PSK that they could successfully use for authentication.
You can still benefit from the concept of encryption and authentication by using a different type of technology. This additional option is called Secure Sockets Layer (SSL). The convenient thing about SSL is that almost every web browser on every computer supports it, so almost anyone who has a computer can use it.
To use SSL, the user connects to an SSL server, which is a fancy way of saying a web server that supports SSL, by using HTTPS rather than HTTP. An easy way to remember is that the S means secure. Depending on whom you talk to, SSL may also be labeled as Transport Layer Security or TLS. To the end user such as you or I, it represents a secure connection to the server, and to the correct server.
Even if the users does not type in HTTPS, the website could redirect the user behind the scenes to the correct URL. Once there, the browser requests that the web server identify itself. (Be aware that all of this that is about to happen is occurring in the background and does not require user intervention.) The server sends the browser a copy of its digital certificate, which may also be called an SSL certificate. When the browser receives the certificate, it checks whether it trusts the certificate. The browser decides whether it is trusted by looking at the digital signature of the CA that is on the certificate; using the method for verifying a digital signature discussed earlier, the browser determines the certificate is valid based on the signature of the CA (or is not valid). (If the signature is not valid, or at least if our browser does not think the certificate is valid, a pop-up is usually presented to the user asking whether the user wants to proceed.) This is where user training is important and users should be trained never to continue or accept a certificate that the browser does not trust.) Assuming the certificate is trusted, the browser now has access to the server’s public key contained in the certificate.
Most of the time, the server does not require the browser to prove who it is. Instead, the web server uses some type of user authentication, such as a username or password as required, to verify who the user is.
After the authentication has been done, several additional exchanges occur between the browser and the server as they establish the encryption algorithm they will use and the keys that they will use to encrypt and decrypt the data. You learn more about that exact process in the chapter on PKI.
As mentioned previously, understanding the terminology is important for you in mastering VPN technologies. Table 5-2 describes VPN components, their functions, and examples of their implementation. Some of these terms are a review, whereas others are new. These concepts and their functions are repeated throughout the chapters on these topics to assist you in learning and applying these concepts.
