Home > Articles > Networking

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.

03fig09.gifFigure 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.

03fig10.gifFigure 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.

03fig11.gifFigure 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.

03fig12.gifFigure 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.

03fig13.gifFigure 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.


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.

graphics/ccc.gif EFgQU3Rc4WmXyFuApzKBZCUyzwqoO6jkwCQYDVR0TBAgkqhkiG9n0HQQAEDDAKGwRWNC4wAwIDq
   graphics/ccc.gif NQUyBpbmNvcnBvcmF0ZWQgYnkgcmVmZXJlbmNlLiBUayBjb250YWlucyBsaW1pdGF0aW9ucyBvb
   -----END CERTIFICATE-----
   Proc-Type: 4,ENCRYPTED
   -----END RSA PRIVATE KEY-----

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. Once this is done, the client sends a finished message to the server to say that it is ready.

  8. 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.

  9. A secure encrypted tunnel is now set up, and communication can begin using the symmetric encryption details negotiated.

03fig15.gifFigure 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.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020