4.4 Secure sockets layer

4.4 Secure sockets layer

In Chapter 3, we introduced you to the term SSL. SSL (Secure Sockets Layer) is a protocol designed by Netscape Communications. SSL provides for the encryption of a session or authentication of a server. It is a network protocol layer, located directly under the application layer with responsibility for the management of a secure, encrypted, communication channel between a server and client. SSL is implemented in major web browsers such as Netscape and Internet Explorer. The address keyword https:// is used to designate a secure, or SSL enabled, connection.

One of the most basic functions of SSL is message privacy. SSL can encrypt a session between a client and a server so that applications can exchange and authenticate user names and passwords without exposing them to eavesdroppers. Hackers can use IP sniffers and scanners to capture copies of all packets that pass between a client and server during a session. This information is then available in an unencrypted, cleartext format. One example could be a basic authentication between a browser and a server. The browser attempts to access a page that requires authentication, a user name, and a password. The server will return a status code back to the browser (for example, 401). This status code tells the browser to generate a prompt for the user name and password. The user then enters the user name and password, and this data is sent back to the server. In this example of basic HTTP authentication, the password is passed over the network, not encrypted, but not as plaintext either; it is "unencoded." Anyone watching packet traffic on the network will not see the password in the clear, but the password will be easily decoded by anyone who happens to catch the right network packet, and this is very easy to do. With SSL, however, all transmissions following the initial handshake are encrypted to prevent transmissions from being captured. The client and server prove their identities by exchanging certificates. All traffic between the SSL server and the SSL client is encrypted using a key and an encryption algorithm negotiated during the SSL handshake, which occurs at session initialization. Next, the SSL protocol ensures that messages between the sender system and receiving system have not been tampered with during the transmission. This ensures a secure channel between the client and server. SSL uses a combination of mathematical functions known as hash functions. (Hashing was discussed in Chapter 3.) Also, a shared secret is used to encrypt the data with a strong cipher. If, during a session, a packet is damaged or indecipherable, we must assume that tampering has occurred. An ongoing process of verifying and checking the packets will preserve the integrity of the messages. In SSL v3.0, initiation of the handshake can even be carried out by the client or in the middle of an open session, thus allowing the systems to change the algorithms and keys used whenever they want. Included in this process is server authentication (with X.509v3, clients can also be authenticated). This is the process of determining the server identity via the exchange of X.509 certificates. A server's identity is coded into a public-key certificate that is exchanged during the SSL handshake.

SSL was designed to make its security and services transparent to the end user. Normally a user would follow a URL (see RFC 1738) to a page that connects to an SSL-enabled server. The SSL-enabled server would accept connect requests on 443 (default). The default port for non-SSL access is port 80. When it connects to port 443, the handshake process will establish the SSL session. Now, all traffic between the server and client will be encrypted. The handshake is composed of three basic steps:

  1. The client and server (or server and server) exchange X.509 certificates to prove their identity. As part of the process, the certificates are checked against expiration dates and for evidence of tampering.

  2. Next, the client generates a set of keys to be used for encrypting the data. The client encrypts a cipher key with the public key that it received from the server. The client then sends the encrypted key to the server. The server now decrypts that key with its private key.

  3. Finally, the client and server select the hash function and the message encryption cipher algorithm. The server will ask the browser to provide a list of all possible ciphers that it holds. The server then selects a cipher to encrypt the data, using the strongest allowable cipher that it holds in common with the client.

Figures 4.4 and 4.5 show examples of the ciphers that can be used with other servers, in these cases SSL v2 and SSL v3.

click to expand
Figure 4.4

click to expand
Figure 4.5

You will notice in Figure 4.5 that there are many different key strengths. Servers use these key strengths and browsers to determine the strength of the encryption that should be used. But, alas, all is not well in "encryption land." The issues are complex due to the involvement of various governments. The United States government watches closely over what is happening with encryption technologies. There are two government agencies that control export of encryption software: the Bureau of Export Administration (BXA) in the Department of Commerce, authorized by the Export Administration Regulations (EAR), and the Office of Defense Trade Controls (DTC) in the State Department, authorized by the International Traffic in Arms Regulations (ITAR) and U.S. Department of Commerce, Bureau of Export Administration Office of Strategic Trade & Foreign Policy Controls, and the Information Technology Controls Division. The old rule was you could not export any key size greater than 64 bits. This rule has changed and will likely change again in the future. See the following web sites for more information:

  • http://www.eff.org/pub/Privacy/ITAR_export/


  • http://www.bxa.doc.gov/Encryption/licchart.htm

  • http://www.bxa.doc.gov/Encryption/Default.htm

  • http://www.bxa.doc.gov//PDF/1231ERC.pdf

Before you start rolling out browsers worldwide, do the following.

  1. Determine in which countries you will be doing business.

  2. Check with your legal department to determine current U.S. export laws. There are some countries that you cannot export to for any reason. (See section 740.17 of the Federal Register Vol. 63, no. 251.) [5]

  3. Determine what the import laws are of the countries in which you will be doing business. Some countries limit encryption technology; be sure to check on this. As of this writing, France and China are two such countries. For more examples see the following:

    • http://www.cnnfn.com/digitaljam/newsbytes/124890.html

    • http://news.cnet.com/news/0-1003-200-1570561.html

So far in the process we have talked about the SSL handshake and the encryption keys and certificates. One item left to talk about is certificates and the authority used to manage the certificates.

Certificates are, in effect, signed documents. In an SSL transaction, each device will have one. We use different forms of signed documents in our everyday lives. In most countries, including the United States, there are agencies (Department of Motor Vehicles) that certify people to legally drive a car. The steps for obtaining a driver's license are very similar between all agencies:

  • The user requests a license (a certificate).

  • The user makes a payment (always money involved!).

  • The user may have his or her picture taken and sign the document.

  • The agency will "certify" that the license is good and will provide some type of unique number that only that particular license will have.

  • The license will expire at some point.

  • At some point, the license may need to be renewed.

  • The license gives the user the right to drive a car and is used for identification purposes.

In this example, the Department of Motor Vehicles is the certificate authority, or "CA." The CA in this case will certify that holders of licenses can drive a car and that they are really who they say they are. As for identification, we trust the holder of the license that the picture and signature are those of the license holder.

Why do we trust the license? Because we trust the agency that certified the license. So we trust this third party because the third party has implemented some type of due diligence in determining the true identity of the user. If we trust the third party, then we trust the identity of the holder of the card. Get it? If not, you may want to review this section again. This is critical in order to understand the rest of the certificate process.

With Internet certificates, the process is much the same. Certificates are signed by certificate authorities (CAs). The CA will issue certificates based on a request from the user or server. A certificate authority is a commonly trusted third party (like the government agency in the license example), who is relied upon to verify the matching of public keys to the user's identity. This process can also verify items such as e-mail name, digital signature, and access privileges.

To make this process work, all parties must trust the CA. We use digital certificates instead of a card or license. Using a CA and these certificates, we can verify a user's or server's identity over the Internet. So a certificate authority, or CA, refers to either the software or service that issues digital certificates. A certificate authority acts as the third party in a digital transaction: When a user is trying to prove his or her identity to a vendor to access an account, the vendor can verify the user's identity via the certificate authority. Digital certificates work via a technology known as public key encryption. The owner of a certificate holds two keys, a public key and a private key. The public key allows anyone to encrypt data to send to a specific user. The private key, which is accessible only to the user or owner, can send signed messages and decrypt information.

The CA will issue a certificate to a user or server (see Figure 4.6). Each certificate will have the following information:

  1. Certificate owner the certificate owner is the person that has access to use the certificate. This could be protected by a password or be placed onto a smart card or other device.

  2. Name this is the name assigned to the owner of the certificate.

  3. Key serial number each certificate should have some type of number that identifies it and is unique.

  4. Expiration date all certificates should have an expiration date.

  5. Private key the private key is not shared outside of the certificate.

  6. Public key the public key is sent to other users or a shared directory service.

  7. Certificate issued by this section has information about the CA.

  8. Name this is the name of the CA.

  9. Digital fingerprint this is a number that is unique to the certificate and can be used to verify a signature's validity.

click to expand
Figure 4.6

As we have seen, certificates have a limited life. They are requested and created and then are either revoked or expire. Revocation is important if private keys are compromised or if there has been a change in status or policy. Revocation of a certificate is accomplished through use of a Certificate Revocation List (CRL). Someone who is going to use a certificate might want to check against a CRL to ensure the validity of the certificate. A certificate authority will sign all certificates that it issues with its private key. The corresponding certificate authority public key is itself contained within a certificate, called a "CA certificate." A browser must contain this CA certificate in its "Trusted Root Database" in order to "trust" certificates signed by the CA's private key. So the browser will have a trusted root and the server will have a certificate that is signed by the CA (see Figure 4.7).

click to expand
Figure 4.7

Figure 4.8 shows some examples of the root certificates that ship with a Netscape browser, where there are more than 50. If you were to use a public CA, you would use something similar to the following steps to get your server certificate (Note: These steps may vary from one software product to another.):

  1. Create a key ring file.

  2. Send a certificate request to the CA.

  3. You may need to send identification about your company and some payment.

  4. The CA will certify the request.

  5. The CA will send the certified request back to you.

  6. You will then merge the certified request into your server's key ring file.

  7. Configure your software to enable SSL and open up port 443 on your DMZ.

  8. Enable your application to support SSL as needed.

  9. Hit the application with https://urlname.

click to expand
Figure 4.8

Your company may choose to create its own closed, "private" certificate infrastructure for internal use. This can be accomplished with software that is provided with many web servers, you can purchase your own software, or you can have a service provider as your CA. You can also use Public CAs, such as:

SSL References


Internet Security(c) A Jumpstart for Systems Administrators and IT Managers
Internet Security: A Jumpstart for Systems Administrators and IT Managers
ISBN: 1555582982
EAN: 2147483647
Year: 2003
Pages: 103
Authors: Tim Speed, Juanita Ellis

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net