13 Overview of Secure Sockets Layer (SSL) in Oracle Application Server

13.1 What SSL Provides

SSL secures communication by providing message encryption, integrity, and authentication. The SSL standard allows the involved components (such as browsers and HTTP servers) to negotiate which encryption, authentication, and integrity mechanisms to use.

• Encryption allows only the intended recipient to read the message. SSL can use different encryption algorithms to encrypt messages. During the SSL handshake that occurs at the start of each SSL session, the client and the server negotiate which algorithm to use. Examples of encryption algorithms supported by SSL include AES, RC4, and 3DES.

• Integrity ensures that a message sent by a client is received intact by the server, untampered. To ensure message integrity, the client hashes the message into a digest using a hash function and sends this message digest to the server. The server also hashes the message into a digest and compares the digests. Because SSL uses hash functions that make it computationally infeasible to produce the same digest from two different messages, the server can tell that if the digests do not match, then someone had tampered with the message. An example of a hash function supported by SSL is SHA1.

• Authentication enables the server and client to check that the other party is who it claims to be. When a client initiates an SSL session, the server typically sends its certificate to the client. Certificates are digital identities that are issued by trusted certificate authorities, such as Verisign. Section 13.5, "Certificates and Oracle Wallets" describes certificates in more detail.

  The client verifies that the server is authentic and not an imposter by validating the certificate chain in the server certificate. The server certificate is guaranteed by the certificate authority (CA) who signed the server certificate.

  The server can also require the client to have a certificate, if the server needs to authenticate the identity of the client.

13.2 About Private and Public Key Cryptography

To provide message integrity, authentication, and encryption, SSL uses both private and public key cryptography.

Private Key Cryptography

Private, or symmetric, key cryptography requires a single, secret key shared by two or more parties to secure communication. This key is used to encrypt and decrypt secure messages sent between the parties. This requires prior and secure distribution of the key to each party. The problem with this method is that it is difficult to securely transmit and store the key.

In SSL, each party calculates the secret key individually using random values known to each side. The parties then send messages encrypted using the secret key.

Public Key Cryptography

Public key cryptography solves this problem by employing public and private key pairs and a secure method for key distribution. The freely available public key is used to encrypt messages that can only be decrypted by the holder of the associated private key. The private key is securely stored, together with other security credentials, in an encrypted container such as an Oracle wallet.

Public key algorithms can guarantee the secrecy of a message, but they do not necessarily guarantee secure communication because they do not verify the identities of the communicating parties. To establish secure communication, it is important to verify that the public key used to encrypt a message does in fact belong to the target recipient. Otherwise, a third party can potentially eavesdrop on the communication and intercept public key requests, substituting its own public key for a legitimate key (the man-in-the-middle attack).

To avoid such an attack, it is necessary to verify the owner of the public key, a process called authentication. Authentication can be accomplished through a certificate authority (CA), which is a third party trusted by both of the communicating parties.

The CA issues public key certificates that contain an entity's name, public key, and certain other security credentials. Such credentials typically include the CA name, the CA signature, and the certificate effective dates (From Date, To Date).

The CA uses its private key to encrypt a message, while the public key is used to decrypt it, thus verifying that the message was encrypted by the CA. The CA public key is well known, and does not have to be authenticated each time it is accessed. Such CA public keys are stored in wallets.

13.3 How an SSL Session Is Set Up (the "SSL Handshake")

The SSL protocol has two phases: the handshake phase and the data transfer phase. The handshake phase authenticates the server and optionally the client, and establishes the cryptographic keys that will be used to protect the data to be transmitted in the data transfer phase.

When a client requests an SSL connection to a server, the client and server first exchange messages in the handshake phase. (A common scenario is a browser requesting a page using the https:// (instead of http://) protocol from a server. The https protocol indicates the usage of SSL with HTTP.)

Figure 13-1 shows the handshake messages for a typical SSL connection between a Web server and a browser. The following steps are shown in the figure:

1. The client sends a Hello message to the server.

   The message includes a list of algorithms supported by the client and a random number that will be used to generate the keys.

2. The server responds by sending a Hello message to the client. This message includes:

   • The algorithm to use. The server selected this from the list sent by the client.

   • A random number, which will be used to generate the keys.

3. The server sends its certificate to the client.

4. The client authenticates the server using the server's certificate.

5. The client generates a random value ("pre-master secret"), encrypts it using the server's public key, and sends it to the server.

6. The server uses its private key to decrypt the message to retrieve the pre-master secret.

7. The client and server separately calculate the keys that will be used in the SSL session.

   These keys are not sent to each other because the keys are calculated based on the pre-master secret and the random numbers, which are known to each side. The keys include:

   • Encryption key that the client uses to encrypt data before sending it to the server

   • Encryption key that the server uses to encrypt data before sending it to the client

   • Key that the client uses to create a message digest of the data

   • Key that the server uses to create a message digest of the data

   The encryption keys are symmetric, that is, the same key is used to encrypt and decrypt the data.

8. The client and server send a Finished message to each other. These are the first messages that are sent using the keys generated in the previous step (the first "secure" messages).

   The Finished message includes all the previous handshake messages that each side sent. Each side verifies that the previous messages that it received match the messages included in the Finished message. This checks that the handshake messages were not tampered with.

9. The client and server now transfer data using the encryption and hashing keys and algorithms.

Figure 13-1 SSL Handshake

Description of "Figure 13-1 SSL Handshake"

13.4 Requirements for Using SSL in Oracle Application Server

To use SSL in Oracle Application Server:

• You need a certificate and an Oracle wallet for your site. This certificate is used by clients to verify that they are not connecting to an imposter site.

• If you need to authenticate your clients, the clients will need certificates as well.

• You need to configure Oracle Application Server components (for example, Oracle HTTP Server) to accept and transmit messages over SSL.

• SSL is resource-intensive. If you expect heavy SSL traffic, then you should consider getting an SSL accelerator.

The following sections in this chapter describe these topics in more detail.

13.5 Certificates and Oracle Wallets

You need a certificate for your site. When clients connect to your site requesting SSL communication, you usually have to send your certificate to them so that they can authenticate you.

Oracle Application Server supports X.509 V3 certificates, and certificates that conform to the PKIX standard (RFC 3280).

13.6 SSL Configuration Overview

You enable components in Oracle Application Server to use SSL using the Application Server Control. In some cases, you edit configuration files by hand.

SSL secures communication between two parties: a client and a server. If three or more parties are involved, for example, client browser, OracleAS Web Cache, Oracle HTTP Server, and OC4J, then you may have to configure all components to use SSL.

Figure 13-2 shows typical communication paths between Oracle Application Server components and the protocols that they use. For example, browsers use HTTP to communicate with OracleAS Web Cache, and Oracle HTTP Server uses AJP to communicate with OC4J. All these protocols can work with SSL.

Figure 13-2 Communication Paths Between Components in Oracle Application Server

Description of "Figure 13-2 Communication Paths Between Components in Oracle Application Server"

13.7 Integration with Hardware Security Modules

When clients connect to your site using SSL, the extra processing required for SSL strains your servers, and your site as a whole (SSL as well as non-SSL connections) will experience slower performance and throughput. You should consider using SSL accelerator hardware to offload SSL computations and improve performance.

Types of SSL accelerators:

• Section 13.7.1, "Protocol Converters"

• Section 13.7.2, "Mathematics Accelerators (PKCS #11 Integration)"