|Oracle® Application Server Administrator's Guide
Part Number B28185-01
In Oracle Application Server, components send requests to and receive responses from other components. These components can be Oracle Application Server components (such as OracleAS Single Sign-On, OracleAS Web Cache, or Oracle HTTP Server) or external clients such as browsers.
To secure these communications, you can configure Oracle Application Server to use SSL, which is an industry standard for securing communications. Oracle Application Server supports SSL versions 2 and 3, as well as TLS version 1.
This chapter provides an overview of SSL and how you can use it with Oracle Application Server. It contains the following topics:
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 11.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.
To provide message integrity, authentication, and encryption, SSL uses both private and public 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.
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 11-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:
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.
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.
The server sends its certificate to the client.
The client authenticates the server using the server's certificate.
The client generates a random value ("pre-master secret"), encrypts it using the server's public key, and sends it to the server.
The server uses its private key to decrypt the message to retrieve the pre-master secret.
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.
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.
The client and server now transfer data using the encryption and hashing keys and algorithms.
Figure 11-1 SSL Handshake
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.
Oracle Application Server supports X.509 V3 certificates, and certificates that conform to the PKIX standard (RFC 3280).
You get certificates from certificate authorities (CAs). CAs are trusted entities who sign the certificates that they issue with their private key. Clients can verify the issuer of a certificate (by using the CA's public key). Examples of CAs include Verisign (
http://www.verisign.com) and Thawte (
Oracle Application Server also has a certificate authority, called OracleAS Certificate Authority (OCA). You can use it to set up your own certificate authority. See the Oracle Application Server Certificate Authority Administrator's Guide for details.
To get a certificate, you submit a certificate request to a CA. The certificate request contains your information including your public key. You can use tools to generate a certificate request; these tools can generate private and public key pairs for you. Examples of tools that can generate certificate requests include Oracle Wallet Manager and Sun's
keytool (for OC4J only). For information on Oracle Wallet Manager, see Chapter 13.
Among other items, a certificate includes the following pieces of data:
Certificate owner's name
Certificate owner's public key
Certificate expiration date
Certificate serial number
Certificates are valid until they expire or until they are revoked.
Note that if you use OracleAS Certificate Authority (OCA) to create certificates for your server, most browsers will not accept these certificates without input from the browser user. This is because most browsers are preconfigured to accept certificates from certain CAs, and OCA is not one of them. The browser will reject the certificate from the server unless the user chooses to accept certificates from the server or import the CA's certificate.
This problem exists for all CAs until the CA's certificate is imported into the browsers. For more information, see the Oracle Application Server Certificate Authority Administrator's Guide.
An Oracle wallet is a container that stores your credentials, such as certificates, certificate requests, and private keys. You can store Oracle wallets on the file system or in LDAP directories such as Oracle Internet Directory. Oracle wallets are password-protected.
You manage Oracle wallets using Oracle Wallet Manager. Use Oracle Wallet Manager to perform tasks such as creating Oracle wallets, creating certificate requests, importing certificates into the wallet, and uploading wallets to an LDAP directory.
Oracle Wallet Manager supports PKCS #11 and PKCS #12 wallets:
Scenario 1: You generate a certificate request using Oracle Wallet Manager and decide to store the private key on the file system. When you get your certificate from the CA, you can import it into an Oracle wallet. This wallet uses the PKCS #12 format. See Section 184.108.40.206.1 for details.
Scenario 2: You generate a certificate request using Oracle Wallet Manager and decide to store the private key on a hardware security module. When you get your certificate from the CA, you can import it into an Oracle wallet. This wallet uses the PKCS #11 format. See Section 220.127.116.11.2 for details.
Scenario 3: You already have a certificate in a wallet that uses the PKCS #12 format, and you want to use it with Oracle Application Server. The wallet was created using a third-party tool. In this case, use the tool that was used to create the wallet and export the wallet to a file on the file system. You can then import the wallet. See Section 18.104.22.168.3 for details.
Components That Use Oracle Wallets
Oracle Application Server components that act as SSL servers need Oracle wallets (the wallet already contains the certificate that you want the server to use). Examples of these components include Oracle HTTP Server, OracleAS Web Cache, OPMN, Oracle Internet Directory, and the Port Tunneling daemon (
You configure the component with the location of the Oracle wallet. For example, to configure Oracle HTTP Server for SSL, you specify the location of the wallet using the
SSLWallet directive. Refer to the component guide for specific instructions on how to specify the wallet location for the component.
Note:The OC4J component uses a keystore instead of an Oracle wallet to store its certificate. You use a tool called
If you need to authenticate your clients, you can configure the Oracle HTTP Server to require clients to send their certificates. Clients can also get their certificates from CAs.
If the clients are Oracle components, for example, OracleAS Web Cache can act as a client when communicating with Oracle HTTP Server, the client component can store its certificate in an Oracle wallet. OPMN also acts as a client when configured for SSL.
If the client is a browser, the client does not need an Oracle wallet. You can just import the certificate into the browser.
Other types of clients, such as SOAP or Web Services clients, have their own ways of configuring certificates and certificate stores.
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 11-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 11-2 Communication Paths Between Components in Oracle Application Server
On installation screens where you specify the Oracle Internet Directory host and port, there is an option marked "Use only SSL connections with this Oracle Internet Directory." If you select this option, you need to provide Oracle Internet Directory's SSL port number, and the installer configures the components to use SSL only to communicate with Oracle Internet Directory during runtime.
Oracle Application Server enables you to configure SSL for only the paths you want to secure. There are many paths used by components, as shown in Figure 11-2.
You might not want to secure all paths for the following reasons:
SSL is resource-intensive. If you have heavy SSL traffic, then you probably need to offload SSL processing to an SSL accelerator. See Section 11.7 for details.
If your computers are behind firewalls, you might need to secure only paths that are accessed by the public. For example, you might need to secure only OracleAS Web Cache and Oracle HTTP Server if the public can access only these components.
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:
Note:SSL connections to protocol converters terminate at the protocol converter. When the converters forward the requests to Oracle Application Server, most of them do so in an unencrypted fashion.
For the protocol converters that forward the requests to Oracle Application Server using SSL, this is still faster than not using a protocol converter because using a protocol converter eliminates most SSL key exchanges (which is the expensive operation).
Mathematics accelerators improve the speed of math operations used by SSL. Such devices are usually plugged into a server (often through TCP/IP). Such devices often have additional features such as key management and secure key stores.
Oracle Application Server supports mathematics accelerators that follow the PKCS #11 standard. For a list of certified accelerators, you can check the OracleMetaLink site,