An Overview of SSL

This section provides a quick primer on SSL and a useful background to concepts and interactions that you need to understand in order to configure WebLogic's SSL. If you feel confident about the terms and concepts involved in the world of SSL, you can skip to the next section, which dives into WebLogic's SSL configuration.

WebLogic's SSL implementation fulfills three important goals of secure communication: confidentiality, data integrity, and authentication. SSL is now often found under the name of Transport Layer Security (TLS), the new protocol based on SSL and currently being developed by the Internet Engineering Task Force (IETF). As the name indicates, TLS offers security at the transport layer, somewhere between the network layer (e.g., TCP/IP) and application layer (e.g., HTTP) protocols. A thorough description of SSL and its use within Java security services deserves a book of its own. We recommend Java Security, Second Edition, by Scott Oaks (O'Reilly) for a deeper understanding of SSL and related concepts. In this section, we give an overview of the key concepts that are relevant to configuring WebLogic's SSL implementation.

Suppose a client, such as a browser, needs to securely communicate with a WebLogic server. SSL can ensure that this communication remains secure in the following ways:

Confidentiality

SSL maintains the privacy of the conversation between the client and server. By encrypting the data sent between both parties, SSL makes it difficult for a third party to discover the true contents of the conversation. SSL supports a number of different cryptographic routines from which you can choose.

Integrity

SSL can help ensure that the data has not been tampered with. Integrity checks based on encrypted checksums called digests allow both parties to ensure that the data was not tampered with en route.

Authentication

SSL can help establish the identity of both parties involved in the secure communication. In general, the client verifies the server's identity before initiating a conversation, but the server also may wish to verify the client's identity. This verification is possible only when each party provides a certificate as proof of its identity. This certificate is signed by a CA that can vouch for the authenticity of the certificate.

Let's take a closer look at how SSL supports these features of secure communication.

16.1.1 Encryption

Encryption is a time-tested way of maintaining the confidentiality of the conversation between two parties. A strong encryption algorithm makes it hard for an external party to decipher the message. This means that both parties can be reasonably sure that no one else can interpret the transmitted message. Encryption involves the use of keys numerical values that are used to encrypt the message before it is sent or decipher the message after it has been received. Depending on how the keys are managed, there are two flavors of cryptography to choose from:

Symmetric cryptography

Both parties use the same key to encrypt and decrypt the message. Symmetric cryptography is reasonably fast and provides a safe and reliable way to send an encrypted message. An outside party cannot interpret the message unless it has access to the shared private key. It also means that both parties need to have prior knowledge of the key. Thus, the difficult problem lies in securely transferring the key to the intended recipient.

Asymmetric cryptography

Also called public-key cryptography, this removes the need for using the same key for encryption and decryption. Instead, it uses a pair of keys: a public key that is openly distributed, and a private key that is kept secret with the owner. If one key is used to encrypt a message, the other key must be used to decrypt it. For instance, a client can use the public key to encrypt a message, and the server can then decrypt the same message using its private key. No longer do we have the problem of distributing a private key. Only the public key is needed as the message can be decrypted only using the recipient's private key. Still, public-key cryptography is much slower than symmetric cryptography.

SSL strikes a compromise and uses both. It uses the slower asymmetric cryptography during the initial connection handshake when it needs to securely agree on a symmetric key to use for subsequent communication. Once both parties reach an agreement, the symmetric key is used to encrypt all subsequent communication.

WebLogic supports the RSA algorithm for asymmetric cryptography, and DES-CBC, two-key triple-DES, and RC4 for symmetric cryptography.

16.1.2 Message Digests

Message encryption is not enough. There is still the small probability that a malevolent hacker could tamper with the encrypted message so that when it is decrypted the recipient gets a corrupted version. SSL solves this integrity problem by introducing the notion of a message digest. A digest is a fixed-length representation of a message generated by applying a hash function to the original message. A good hash algorithm makes it computationally infeasible to generate two messages that would yield the same digest. With this kind of guarantee, a digest acts as a "fingerprint" for the message.

By sending the message digest along with the encrypted message, SSL enhances the integrity of the data. When the recipient decrypts the message, it computes its own digest and compares it with the received digest. If the two versions do not match, the recipient knows that the message was almost certainly was tampered with.

WebLogic supports the MD5 and SHA algorithms for creating message digests. SHA generates 160-bit message digests, while MD5 generates 128-bit message digests. Even though SHA is slower than MD5, the larger digest size makes it more secure.

16.1.3 Certificates

Even encryption and message digests together are not enough to completely guarantee secure communications. Both parties involved in the communication must be able to trust each other. Usually, the client needs to be able to verify the server's identity and guarantee the authenticity of the server's public key. This is called one-way SSL. The server accepts connections from any client because the client is not required to provide a certificate. In addition, WebLogic can be configured for two-way SSL, also called mutual SSL, in which the client also needs to present a certificate to the server.

Thus, SSL uses certificates to establish this trust between both parties. For instance, if the server needs to authenticate itself to the client, it sends back a signed copy of its digital certificate. The server's public key will be embedded in the digital certificate. The server is authenticated only when the client validates and accepts the server's digital certificate. These validation checks may include verifying whether the certificate has expired, whether the certificate has been signed by a trusted certificate authority, and more. The client may choose to abort the SSL connection if any of these validation checks fail.

WebLogic recognizes only those digital certificates that adhere to the X.509 v3 standard. It requires that the certificates hold at least the following information:

• The real identity of the certificate's owner, also known as the subject. This could be the domain name of a server or the email address of an individual.
• The name of a CA that issued the certificate, and the period for which the certificate is valid.
• The subject's public key that can be used by the recipient to encrypt the actual data before sending it back to the subject.

An SSL-enabled application, such as a web browser, typically accepts any valid certificates signed by a trusted CA. A digital certificate can be invalidated if it has expired or if the digital certificate of the trusted CA (used to sign the certificate) has expired. A server certificate can also be invalidated if the server's URL doesn't match the domain name embedded in the certificate.

16.1.4 Certificate Authorities

Digital certificates are issued by a trusted third party, called a certificate authority (CA). A CA signs the certificates with its own private key before it issues them. Given the server's certificate, a client now can verify the certificate by using the public key of the certificate authority. As a matter of caution, the client does not trust just any certificate authority. When a CA publishes its public key, it is signed with a certificate issued by a higher-level CA. Of course, the higher-level CA can do the same. This certificate chain stops with a self-signed certificate, whereby the issuer of the certificate is the same as the subject of the certificate. This also is referred to as the root key. Hopefully somewhere along the chain, the client will recognize a CA that it can trust. Only then can the client trust the original CA that issued the server's certificate.

You should be careful about trusting self-signed certificates. Certificate chains can't go on forever and must stop at some point. The certificate chain ends once you've reached a self-signed certificate. Root certificates are hard to forge because they are so widely published, making it harder for a server (or client) to palm you an invalid root certificate. For instance, your browser will already be populated with a number of root keys from various trusted CAs. If WebLogic is configured for mutual authentication, the server must be equipped with a list of trusted CAs so that it can validate incoming client certificates. Thus, WebLogic must have access to a number of root certificates of CAs that it trusts.

A CA issues a certificate after receiving a Certificate Signature Request (CSR); WebLogic provides tools to generate such a request.

16.1.5 Cipher Suites

During an SSL handshake, the two parties have to agree on a number of issues:

• A key exchange mechanism, which determines the asymmetric algorithm that is used to exchange the symmetric key
• A cipher for the data transfer, which determines the symmetric algorithm that is used to encrypt the data
• A message digest algorithm, which determines the hash algorithm that is used to generate the digest

The combination of these three schemes provides a certain level of encryption. The exact set of ciphers that you are allowed to use is controlled by the WebLogic license file. You also can programmatically limit the set of ciphers that are accepted on an SSLSocket by calling the setEnabledCipherSuites( ) method. WebLogic supports only RSA for exchanging keys. The message digest algorithm can be either SHA or MD5. The cipher for the bulk of the data transfer must be one of CBC-DES, triple-DES, or RC4.

The length of the keys adds another dimension to the level of encryption. The larger the key length, the more secure the data is likely to be and the more resistant it is to brute-force attacks. WebLogic is available with exportable and domestic-strength SSL:

• Exportable SSL supports 512-bit certificates and 40- and 50-bit bulk data encryption.
• Domestic-strength SSL supports 768- and 1024-bit certificates and 128-bit bulk data encryption.

Clearly, domestic-strength SSL is more secure. The particular SSL strength that you can use depends on your local and U.S. government restrictions. In fact, your WebLogic license determines the SSL strength supported by your servers. If the license permits only exportable-strength SSL, and you configure WebLogic to use domestic-strength SSL, the server defaults to the exportable-strength SSL instead.

Table 16-1 lists the various cipher suites supported by WebLogic.

The name of the cipher suite captures all of the information about the cipher suite itself. For instance, the TLS_RSA_WITH_DES_CBC_SHA suite indicates that the RSA algorithm will be used for the exchanging the symmetric key, the DES-CBC algorithm will be used for bulk data encryption, and the SHA algorithm will be used for generating the message digests.

16.1.6 Keystores

A Java Keystore (JKS) is a standard mechanism for protecting and storing private keys and certificate chains, and for managing the list of certificates of all trusted CAs. You can choose from various tools to insert, remove, or list the items stored in the keystore.

A keystore can hold two kinds of entries: a key entry that holds the private key and the associated certificate chain, or a certificate entry that holds a trusted CA certificate. Each keystore entry may be accessed via a unique, case-insensitive alias. The entire keystore is protected with its own password. Each entry in the keystore is protected by its own password. In this way, the keystore provides a secure, tamper-proof repository for private keys, certificate chains, and trusted CA certificates.

WebLogic doesn't always use the configured aliases. For example, if you store private keys in a keystore, you need to supply an alias so that WebLogic can determine the private key to be retrieved from the keystore. On the other hand, a keystore may contain a number of trusted CA certificates. In this case, WebLogic retrieves all of the entries within the keystore and therefore doesn't require an alias for each keystore entry. Note that some tools require you to supply an alias when you add an item, even if you are not going to use it.