Figure 3 ESP Packet
The SPI and sequence number fields follow the same format, and purpose as above. Payload Data is the actual data being transferred. Since IPSec uses block ciphers the payload may require some padding in order to make the payload a multiple of the block length. The pad length is then added, followed by the Next Header field, and finally the HMAC is added. IPSec supports two operational modes: transport mode and tunnel mode. In Transport Mode only the data that is being transmitted is encrypted, the IP header is not modified, and the routing is left intact. This mode is used in host to host communication. In Tunnel Mode both the data and IP information are encrypted and are then encapsulated within a new IP packet in order to be routed. This mode is primarily used for host-to-network or network-to-network communications. Figure 4 shows the different IPSec modes.
Figure 4 Differences in Packets in Different IPSec Modes
IPSec is a fantastic protocol, but does have some drawbacks when used with a VPN. With an IPSec VPN you need to configure or install client software in order to connect to the VPN. Once the client is installed and configured IPSec is secure, however, you’re now tied to the workstation with the client software in order to access and resources provided by the tunnel.
We aren’t going to have a book about an SSL VPN without a little discussion about the protocol that makes it possible, Secure Sockets Layer, or SSL. SSL is the most widely deployed security protocol in the world. It’s what allows most people to feel safe making purchases online or using online banking, and you’d have a hard time finding someone that uses the Internet regularly that’s unfamiliar with the little lock in the corner of their browser. SSL was originally created by Netscape in 1994 in order to protect Web traffic for use with e-commerce, and it has since undergone a number of revisions. It provides confidentiality, integrity, and authentication between two hosts with the use of encryption. As shown in Figure 5 SSL runs above TCP/IP but below other higher level protocols like HTTP and LDAP. It uses TCP/IP on behalf of the higher level protocols, and allows a server and client to authenticate to one another in order to establish an encrypted connection.
Figure 5 Location of SSL
SSL is a layered protocol and we’ll focus a bit more on two of the main layers, the SSL Record protocol and SSL Handshake protocol. The SSL Record protocol is responsible for the encapsulation of the higher level protocol data, while the SSL Handshake protocol is responsible for the authentication and negotiation of the encryption algorithm and keys between the client and server in order to establish a secure communication, this is accomplished using the SSL Record protocol.
SSL Record Protocol All encryption for SSL is handled by this protocol. The SSL Record protocol defines a standard format to be used for the transmission of data. These Records contain the message type, version, length, and encapsulated data. They are 8 bytes in length, and do to this fixed length a pad is sometimes necessary. SSL Handshake Protocol This protocol is used to establish a secure connection between the communicating hosts. The handshake allows the server to authenticate itself to the client using public key techniques, as well as client to server in some cases, and then allows for creation of symmetric keys for use with encryption, decryption, and integrity checking.
Here is a brief summary of the steps involved in the SSL Handshake (see Figure 6):
1. The client sends a message to the server in order to initiate a session. The message includes the SSL version, random data generated by the client, session identifier, cipher settings, and compression method. 2. The server responds to the client request by returning the same parameters used by the client. It will also send the server certificate, or server key exchange if no certificate is available, and a request for the client certificate if a server resource requiring authentication is requested. 3. The client initiates a client key exchange by creating a premaster secret and encrypting it with the server’s public key and sending it to the server. The client now returns the client certificate if one has been requested. It may also verify its certificate by sending data encrypted using its private key so that the server can verify that the client is indeed the owner of the certificate. 4. The server and client both generate a master secret based off of the shared premaster secret and use the master secret to generate the session keys. These are symmetric keys used to encrypt and decrypt the data throughout the session. 5. The client and server send a message to each other stating that all future communications will be encrypted using the session keys, and the handshake is complete.
Figure 6 SSL Handshake Step-by-Step
With an SSL VPN there is no need for client software and configuration. Since you can use any browser to connect to the VPN, you can access private resources from anywhere with a browser that supports SSL. Whether at home, an internet caf? or an airport kiosk, the widespread use of SSL makes connecting to company resources secure and easy.
IPSec VPN vs. SSL VPN
An IPSec VPN is fantastic, and is a great choice when you’re looking for an always on, dedicated connection, from Network-to-Network across the Internet cloud. It takes more maintenance and time to deploy but is a solid solution. However, in this battle the SSL VPN seems to be taking on, and surpassing, IPSec as the choice for more and more VPN solutions. There are several reasons this may be the case; the cost associated with deploying an SSL VPN, the relatively low maintenance involved in administrating the device, and the increased control of resources. Because an SSL VPN uses a Web browser for access there is no maintenance performed on the client side as long as a supported browser is being used, this saves countless man hours and in turn money. It is also a cross platform solution; if the operating system has a supported browser installed then the resources can be accessed. Detailed access control can be used; different users can be given different levels of access rather than being allowed access to more resources than are absolutely necessary.
What Is the IVE?
All Juniper Networks Secure Access appliances are built upon the Instant Virtual Extranet (IVE) platform. An extranet is an extension of a corporate network to mobile users, telecommuters, or partners that is provided over a secure connection. The Juniper Networks SSL VPN provides this connection through a standard SSL enabled browser. Once a user has been authenticated they can make requests for resources to the IVE. The IVE, acting as a middle man between the external user and internal company resources, makes requests on behalf of the authenticated user. Any resources the user is permitted access to are passed to the IVE, which then passes the resource on to the remote user. This provides an excellent layer of security since the IVE is the only device ever communicating with the internal resources on the corporate network. Users are able to access internal websites, file servers, e-mail, Terminal Services sessions, and telnet and/or SSH sessions all through their browser. Here is a brief summary of how the IVE works:
1. The end user connects to the IVE using an SSL enabled browser, is authenticated, and makes a request for a specific resource. 2. The IVE logs the request, terminates the connection to the user, and requests the resource from the internal server using the appropriate protocols.