- HyperText Transfer Protocol (HTTP)
- File Transfer Protocol (FTP)
- Real Time Streaming Protocol (RTSP)
- Secure Sockets Layer (SSL)
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Secure Sockets Layer (SSL)
The final protocol we'll look at in this chapter is neither a Layer 4 transport protocol nor an Application layer protocol, but one that sits between these layers to provide security services to many modern Internet applications. Secure Sockets Layer, or SSL, has been one of the major forces in Internet security technology since its inception by Netscape Communications, and continues to be included in all major browsers. This has enabled Web application developers to deliver secure content and services using traditional HTTP servers with few changes required in terms of the setup of the basic server or restructuring of the HTML content. The other major advantage of the integration of SSL into all major browsers is its transparency to the user. SSL typically gets used without the knowledge of the client, other than the appearance of a small padlock in the corner of the browser window, thus meaning that no additional level of expertise is required to use Internet applications with this security. Figure 3-9 shows a browser that is currently using SSL.
)
Figure 3-9. A Web browser will typically use SSL when instructed by the Web site with little or no input required by the user. The use
of SSL can be seen by the inclusion of a small padlock in the browser.
While the most common implementation of SSL is within Web browsers, creating the application protocol hybrid known as HTTPS, it should be remembered that it is a transparent protocol available to any TCP/IP-based application. Along with HTTPS, other common SSL secured protocols include SMTPS and Telnet-S.
The Need for Application Security
The need for security within Internet applications is clear—the Internet is still a public network with little or no security infrastructure designed to protect all users. Imagine using the online services of your favorite bank. Passing important data such as your bank account number, password, and balance across the Internet using only HTTP represents a huge personal security risk, as the data is potentially visible to any device sitting between your browser and the bank's Web site. SSL can be used very effectively to hide all of all the application data as it traverses the Internet to prevent anybody snooping the connection from reading personal data—a process referred to as encryption.
The second important feature provided by SSL for Internet applications is authentication; in other words, the ability for the client to be able to distinguish the Web site as valid. Imagine in our previous bank example if another rogue site were to masquerade as the bank's Web site. This might allow the rogue site to intercept the personal and banking details of thousands of customers, not a welcome situation. SSL provides mechanisms to implement authentication as a way for each side to identify itself to the other.
The final security element that is provided by SSL is tamper detection. Imagine finally that someone were to sit between the client and the bank's Web site and change certain pieces of data as they pass back and forth. This would give the opportunity to alter key personal and banking data and potentially set up fraudulent transactions. SSL provides mechanisms for each side to ensure that the Application layer data being sent and received has not changed in any way as it traverses the Internet.
For the Internet to continue to grow, not only in size, but also as a credible medium for business and commerce, it must be able to provide mechanisms such as SSL as a way to guarantee security.
Fitting SSL into the Seven Layer Model
In the concepts of the OSI Seven Layer Model as we saw in Chapter 2, Understanding Layer 2, 3, and 4 Protocols, SSL sits between the Application layer and the Transport layer, traditionally seen as part of the Presentation layer. This means that the use of SSL is selectively performed by each application rather than as a whole with encryption based in IPSec. This gives the client machine the ability to run secure services for certain applications only, while remaining impartial to the underlying Layer 3 and 4 services below. In comparison, IPSec, for example, can operate in a tunneling mode, which means that all traffic flowing to or from a particular address or range of addresses is encrypted right down to the IP layer. Within SSL, only the Application layer data is encrypted. Figure 3-10 shows the presence of SSL in the OSI model.
)
Figure 3-10. Where SSL sits in the OSI model in comparison to IPSec.
Encryption and Cryptography
The process of encryption and decryption fundamentally means to take some source data, transform it to a state where it cannot be read by anyone else, and then transform it back to its original state, thus rendering it readable once more. This approach requires the use of two important elements: the Cryptographic Algorithm, or cipher, and a key. A cipher is a mathematical formula or function that is applied either to the original data (to encrypt) or to the transformed data (to decrypt). One thing always remains true, however—the cipher used to encrypt the data must also be used to decrypt at the other end. To enable this commonality in a network such as the Internet where there are enormous numbers of potential client-server connection combinations, a series of standard ciphers have been developed over time such as Data Encryption Standard (DES) and RC4.
As these ciphers are well known, they rely on the second element to introduce some form of random factor to the process, known as a key. The use of a key, or series of keys, gives the cipher the ability to encrypt the data in such a way so as not to be decrypted easily. If you were to encrypt a simple sentence using an algorithm that is widely known, it would be a relatively simple task to run the data through the same algorithm and arrive at the answer. The use of a key means that in order to decrypt the data, the recipient must know both the appropriate cipher to use and the key used to encrypt the data originally.
This combination of cipher and key forms the basic premise of modern cryptography: Decryption with the known key is simple, but decryption without the key is extremely difficult and in most cases computationally impossible. SSL uses a combination of two basic encryption techniques, symmetric-key encryption and public-key encryption.
Symmetric-Key Encryption
With symmetric-key encryption, both sides use the same key value to perform both the encryption and decryption. Figure 3-11 shows a simple graphical representation of symmetric-key encryption.
)
Figure 3-11. With symmetric-key encryption, both the encryption and decryption use the same key.
Symmetric-key encryption has a number of advantages and disadvantages. First, performing this type of encryption and decryption is computationally inexpensive, which means that the performance of applications using symmetric keys is generally better. On the downside, if the shared key is compromised on either side, the security of the encryption between the parties is broken. Moreover, the process of sharing a single shared key between two sides wanting to use symmetric-key encryption can be cumbersome. Imagine two Internet-based users wishing to communicate—they must first share a key to use before they can encrypt and transmit data. This in itself is a major headache, as the key cannot just be simply sent in clear text over the Internet for fear of being captured. SSL uses symmetric-key encryption for bulk encryption—that is, the encryption of all Application layer data—but it employs a very clever technique to arrive at a common shared key—public-key or asymmetric-key encryption.
Public-Key or Asymmetric-Key Encryption
As its name suggests, public-key or asymmetric-key encryption uses two different keys to perform encryption and decryption, respectively. These keys are known as the public and private keys and are mathematically linked to security. The mathematics of public-key encryption are different from those in symmetric-key encryption, as any data encrypted using the public key cannot be easily decrypted using the public key, and similarly with the private key. For public-key encryption to work correctly, the client must encrypt using the public key and the server must decrypt using the private key. As a result, the security of the public key is largely irrelevant and it is commonly available. In SSL terms, the public key is carried in a certificate—more on that later. The security of the private key, however, is of utmost importance, and typically, the private key will never leave the server for which it was generated for fear of compromising the security of the key pair. Therefore, in summary, if you encrypt with the widely available public key, the resulting data can only be decrypted using the corresponding private key. Figure 3-12 shows a simple representation of public-key encryption.
)
Figure 3-12. In asymmetric-key or public-key encryption, any data encrypted using the easily available public key can only be decrypted
using the corresponding private key.
This approach affords private-key encryption a couple of key advantages. First, the combination of corresponding, mathematically linked keys means that once the data has been encrypted, it can only be decrypted by the holder of the private key. Second, as the public key can be transmitted in clear text to the intended receiver, it is well suited to large-scale, public networks such as the Internet. The main downside of public-key encryption is that it is computationally expensive, thus rendering it unsuitable for situations in which large volumes are required. Above all, the security of the private key is paramount; if it is lost or compromised, the entire premise on which the process is built is broken.
SSL—Combining Symmetric and Asymmetric Encryption
Therefore, on the one hand we have a symmetric encryption mechanism that is computationally cheap but does not scale well to large numbers of users, and on the other, we have a computationally expensive algorithm which does scale well due to its concept of public keys. The answer in terms of SSL is to use a combination of both of these mechanisms to achieve the result we're looking for. The aim of combining the two methods is to allow for encrypted access from anywhere by anyone. The process uses asymmetric encryption to initialize the connection, and then uses symmetric encryption to provide a secure communication channel for the duration of the conversation.
When communications begin, the client creates a random number whose length is determined by the encryption strength required. This large random number will effectively form the shared private key for the symmetric encryption that will be used to exchange application data. The client encrypts this random number with the public key and sends the encrypted version of this to the server. The asymmetric encryption at this stage ensures that only the private key can decrypt the data. Once decrypted, this random number is now used as the symmetric key for the duration of the conversation, as each party has successfully shared a common key. The beauty of this process is that the actual private keys (random numbers) never actually traverse the connection in clear form, thus minimizing the chance of being intercepted. Figure 3-13 shows this combination of symmetric and public-key encryption as used by SSL.
)
Figure 3-13. SSL uses a combination of public-key encryption to exchange the symmetric-key and symmetric encryption to encrypt the bulk
application data.
Encryption Algorithms
There are many encryption algorithms used, and each provides different levels of encryption, depending on the degree of security required. Earlier algorithms were 40 bits in length, but with today's computing power can typically be cracked within a few hours. The longer the encryption length, the harder they are to crack. All algorithms work in conjunction with a secret key to create the encryption. In the case of SSL, this secret key is the randomly generated number. Common encryption algorithms used today are DES, 3DES, and AES.
Certificates
Now that we've seen the importance of passing the public key within SSL, let's look at the mechanism used to undertake this. Certificates are used in SSL to perform two key functions: first, they provide a level of authentication, potentially for both sides, and second, they provide a standard format in which to pass the public key to the requester. Certificates are like digital passports that can authenticate an organization to a user on connection to its site. Two types of certificates can be used: a server certificate and a client certificate. In a typical SSL environment, only the server certificate is used. This is so that the server (or site) can authenticate who they are on the initial client request and pass the public key. Remember, it is the client that initiates the connection and asks for the certificate to be sent. This allows an organization to publish its services, and even though the users cannot see where they are going (e.g., there is no storefront, or actual physical structure), they know they have connected to the site based on the server certificate issued. While we agree that this could be spoofed in theory, one has to question the rationality of this. It requires that the private key be retrieved, DNS entries to that site be hijacked, or updated to the new address, and all of this needs to happen without the existing site becoming aware of it. This is highly unlikely in an age where security is a number-one agenda item, and a highly active site would be immediately aware of a site failure or attack. In addition, a user must actually make a credit card payment to this fraudulent site. If this did happen, it would have to be to a site that is not well monitored and actively trading, and therefore very rarely visited, which in turn makes the exercise superfluous as no huge revenue or loss of reputation would be achieved by the hacker. Typically, the receipt of a server certificate is all that is required to begin a secure connection with a site. In some cases, the site also wants to ensure that the users are who they say they are. This is certainly a requirement in business-to-business transactions where companies want to be able to control access to their site, especially when access to sensitive information or large sums of money are involved.
Client certificates are used to provide client-side authentication. These certificates, normally derived from the server certificate, are loaded on to the user's machine, and on connection, the server will request the certificate to be sent to it to authenticate the user. As each certificate will have a unique identifier, this can be used to track access. Should connectivity no longer be permitted or required, then this unique identifier can also be used to revoke access to the specific site.
Having the ability to provide client and server authentication builds a very compelling case for SSL deployment. Figure 3-14 is an example of what a certificate looks like followed by the associated private key:
Certificates such as these can be easily copied and pasted into a security appliance.
Certificate Authorities
Certificate authorities (CAs) are like the passport control of the SSL world. They confirm that a site is what it says it is, as they have signed the certificate. Many organizations act as CAs and sign certificates on behalf of sites. These organizations are often seen as respected businesses or in some cases quasigovernment type departments such as a post office or telecommunications provider. The largest ones around today are dedicated to providing a certificate signing function, such as Verisign, Entrust, and Thawte. By default, Web browsers have a list of accepted CAs, which is checked when a site is accessed. If the CA is not present, the browser will display a message asking if this certificate should be accepted. Adding or deleting CAs can be done by users within their favorite browser. Certificates have the ability to be chained. This means that a certificate can be trusted if it has a link or chain back to the original issuer whom you trust. This method is transparent to the user and is handled by the SSL protocol.
Figure 3-14 Sample of a public certificate and private key. As you can see, it is merely clear text and can be easily copied.
-----BEGIN CERTIFICATE----- IFtTCCBR6gAwIBAgIEN0sJFTANBgkqhkiG9w0BAQQFADCBwzELMAkGA1UEB VVMxFDASBgNVBAoTC0VudHJ1c3QubmV0MTswOQYDVQQLEzJ3d3cuZW50cnV ZXQvQ1BTIGluY29ycC4gYnkgcmVmLiAobGltaXRzIGxpYWIuKTElMCMGA1U LmVudHJ1c3QubmV0L0NQUyBpbmNvcnAuIGJ5IHJlZi4gKGxpbWl0cyBsaWFiLikxJTAjBgNVBAs THChjKSAxOTk5IEVudHJ1c3QubmV0IExpbWl0ZWQxOjA4BgNVBAMTVudHJ1c3QubmV0IFNlY3Vy ZSBTZXJ2ZXIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkDjAMBgNVBAMTBUNSTDEyMCygKqAohiZ odHR3QubmV0 L0NSTC9zZXJ2ZXIxLmNybDAfBgNVHSMEGDAWgBTwF2ITVT2z/woAa/tQhJfz7WLQGjAdBgNVHQ4EFgQU3Rc4WmXyFuApzKBZCUyzwqoO6jkwCQYDVR0TBAgkqhkiG9n0HQQAEDDAKGwRWNC4wAwIDq DANBgkqhkiG9w0BAQQFAAOBgQBbSMGk6BtJ7g6UzC4hL1nJZYQldua3ot6K7EstAu6pBiE0DhAG JKm0tCrS16h KGMpIDE5OTkgRW50cnVzdC5uZXQffffltaXRlZDE6MDgGA1UEAxMxRW50cn ZXQgU2VjdXJlIFNlcnZlciBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0 MDgxNjA4MjdaFw0wMjAxMDgxNjM4MjdaMH4xCzAJBgNVBAYTAlNFMRIwEAY EwlTdG9ja2hvbG0xEjAQBgNVBAcTCVN0b2NraG9sbTEUMBIGA1UEChMLQmx aWwgQUIxFDASBgNVBAsTC0RldmVsb3BtZW50MRswGQYDVQQDExJ2aXAyYS5 dGFpbC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALctVjRkmPJ FsI/oo1Xh0yJqyC/Vl2tWS3ujM8lSqCA9afq8cqfcRN5cWcelix5oEbaz5e GdtLVWqBHw09As3w1AyZsdiSUpdOFNdjPhv9IC9S13y7zCzr0SyS/u7l1c4 c3QubmV0L2NwczCBwAYIKwYBBQUHAgIwgbMwEhYLRW50cnVzdC5uZXQwAwI 9TsMAFHBudxPK58IPkKUSpdxZvg7AgMBAAGjggL4MIIC9DCCAQcGA1UdIAS /DCB+QYJKoZIhvZ9B0sCMIHrMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnEVudHJ1c3QubmV0IE
SSL in Action
Let's see the combination of cipher suites, keys, algorithms. and certificates in action as we run through an example SSL session.
When enabling SSL on services on your server, you will first need to create a private and public key pair and corresponding certificate. This process is automatically initiated on most Web servers and will result in the creation of what is known as a certificate signing request, or CSR. This CSR, containing the public key, should be forwarded to the chosen CA for signing, and once completed imported back into the Web server. A point to note here is that the private key must stay private; if it were available, someone could easily masquerade as your site because the public key is just that, public. With the private and public key pair, all encrypted traffic can be decrypted. But let's get back to the CSR. The CSR needs to be sent to a CA, who will sign it and return it to you for you to validate your domain name. We must point out here that a certificate is tied to a domain name and not an IP address. This domain name needs to be resolved to the address of the server in order to work. Once complete, the Web site can be ready for use, and all that is required is that the servers have the SSL service running.
Now we are ready to begin the actual SSL setup as illustrated in Figure 3-15. Let's look at the steps in more detail, remembering that certain message types within the SSL protocol are used to determine specific requests:
-
Once the client has established a TCP session on port 443 with the server, the client sends a client hello message. This client hello includes information such as the cipher suites that it supports.
-
The server selects the cipher suite from the list presented and responds with a server hello indicating to the client the ciphers it deems suitable. The client and the server have now agreed on a cipher suite to use.
-
The server then issues the client a copy of its certificate (remember that this certificate also contains the public key). Optionally, the server may request a copy of the client's certificate if client-side authentication is required.
-
Next, the server sends a server hello done message to tell the client it has completed the first phase of the session setup. As there is no key yet, this process is carried out in clear text.
-
The client now generates a random number, encrypts it with its public key, and sends the server the client key. This process is known as the client key exchange. This is the symmetric key that will be used for the duration of the symmetric encryption session. Communication from here on is encrypted.
-
The client now sends a change cipher spec message to the server to say it will now begin using the negotiated cipher suite (determined in step 2) for the duration of the session.
-
Once this is done, the client sends a finished message to the server to say that it is ready.
-
The server, in turn, sends a change cipher spec message to the client using the agreed information. The server also sends out a finished message on completion.
-
A secure encrypted tunnel is now set up, and communication can begin using the symmetric encryption details negotiated.
)
Figure 3-15. SSL session setup is a computationally intensive process that we need to offload to increase network performance.
One key piece of information in this exchange, which we will see has relevance in content switching in later chapters, is the SSL Session ID. This is a random identifier agreed by both sides when first initiating the SSL session to the server and is used to uniquely identify the tunnel they have established. One option that is held by the client during the negotiation process described previously is to reuse a set of agreed ciphers and keys by including the Session ID in the client hello it sends to the server. Provided that the server is configured to allow this type of session reuse, it will skip the need to swap the symmetric key and thus bypass the big number arithmetic needed, in turn speeding up the process. The SSL Session ID can be read in clear text, as it is not passed encrypted between client and server.
SSL Summary
SSL is a standards-based encryption and authentication mechanism widely used within the Internet today. While by far the most common implementations use HTTP as the Application layer protocol, SSL can be used to secure other applications. As we'll see in later chapters, the inclusion of SSL as a security mechanism for modern Web sites creates yet another part of the puzzle of content switching.