| Oracle® Traffic Director Administrator's Guide 11g Release 1 (11.1.1.7.0) Part Number E21036-04 |
|
|
PDF · Mobi · ePub |
| Oracle® Traffic Director Administrator's Guide 11g Release 1 (11.1.1.7.0) Part Number E21036-04 |
|
|
PDF · Mobi · ePub |
This section describes how you can use SSL/TLS to secure communication between clients and Oracle Traffic Director instances. The information in this section is aimed at readers who are familiar with the concepts of SSL/TLS, certificates, ciphers, and keys. For basic information about those concepts, see Section 11.2.7, "SSL/TLS Concepts."
This section contains the following subsections:
Section 11.2.1, "Overview of the SSL/TLS Configuration Process"
Section 11.2.3, "Associating Certificates with Virtual Servers"
Section 11.2.4, "Configuring SSL/TLS Ciphers for a Listener"
To enable SSL/TLS for an Oracle Traffic Director instance, you must associate an RSA or ECC certificate, or both, with one more listeners of the instance. Additionally, you can associate an RSA or ECC certificate, or both, directly with virtual servers. The process of configuring SSL/TLS for Oracle Traffic Director instances involves the following steps:
Obtain the required certificates, which could be self-signed, issued by a third-party Certificate Authority (CA) like VeriSign or a certificate that you generated.
For more information, see the following sections:
Install the certificates as described in Section 11.4.3, "Installing a Certificate."
Associate the certificates with the required HTTP or TCP listeners as described in Section 11.2.2, "Configuring SSL/TLS for a Listener."
You can also associate certificates directly with virtual servers as described in Section 11.2.3, "Associating Certificates with Virtual Servers." For information about the logic that Oracle Traffic Director uses to select the certificate to be sent to a client during the SSL/TLS handshake, see Section 11.2.5, "Certificate-Selection Logic."
Configure ciphers supported for the HTTP or TCP listeners as described in Section 11.2.4, "Configuring SSL/TLS Ciphers for a Listener."
You can configure a listener to receive HTTPS or TCP requests by using either the administration console or the CLI. Before you start, obtain the required certificates and install them as described in sections Section 11.4.1, Section 11.4.2, and Section 11.4.3.
Note:
When you modify listeners, you are, in effect, modifying a configuration. So for the updated configuration to take effect in the Oracle Traffic Director instances, you should redeploy the configuration as described in Section 4.3, "Deploying a Configuration."
If you associate new certificates with a listener or remove previously associated certificates, for the changes to take effect, you must restart the instances. It is not sufficient to merely deploy the updated configuration.
The CLI examples in this section are shown in shell mode (tadm>). For information about invoking the CLI shell, see Section 2.3.1, "Accessing the Command-Line Interface."
Configuring SSL/TLS for a Listener Using the Administration Console
To configure SSL/TLS for an HTTP or TCP listener by using the administration console, do the following:
Log in to the administration console, as described in Section 2.3.2, "Accessing the Administration Console."
Click the Configurations button that is situated at the upper left corner of the page.
A list of the available configurations is displayed.
Select the configuration for which you want to configure SSL/TLS-enabled listeners.
In the navigation pane, expand Listeners and select the listener for which you want to enable and configure SSL/TLS.
The Listener Settings page is displayed.
In the SSL Settings section, select the SSL Enabled check box.
In the RSA Certificate and ECC Certificate fields, select the certificates that you want to use to authenticate the server.
If you associate a listener with an RSA certificate and with an ECC certificate, the certificate that the server eventually presents to the client is determined during the SSL/TLS handshake, based on the cipher suite that the client and the server negotiate to use.
You can also specify the following advanced SSL/TLS settings in the Advanced Settings section of the Listener Settings page:
Enable and disable settings for client authentication. For more information, see Section 11.8, "Configuring Client Authentication."
Enable and disable strict SNI host matching. For more information, see the Section 11.2.6, "About Strict SNI Host Matching." section.
Enable and disable the following TLS-specific features:
Version Rollbacks
Select this check box if you want Oracle Traffic Director to detect and block attempts at rolling back the TLS version. For example, if the client requested TLS 1.0, but an attacker changed it to a lower version (say, SSL 3.0), Oracle Traffic Director can detect and block the rollback even if it supports the lower version.
Session Ticket Extension
If enabled, TLS sessions can be resumed without storing the session state of each client on the server. Oracle Traffic Director encapsulates the session state of each client in a ticket and forwards the ticket to the client. The client can subsequently resume the TLS session by using the previously obtained session ticket.
Enable and disable SSL and TLS ciphers. For more information, see Section 11.2.4, "Configuring SSL/TLS Ciphers for a Listener."
On-screen help and prompts are provided for all of the parameters.
When you change the value in a field or tab out of a text field that you changed, the Save button near the upper right corner of the page is enabled.
At any time, you can discard the changes by clicking the Reset button.
After making the required changes, click Save.
A message, confirming that the updated listener was saved, is displayed in the Console Messages pane.
Click the Deployment Pending button that is displayed at the top of the main pane, and on the resulting dialog box, confirm the deployment by clicking Deploy.
Restart the instances of the configuration by clicking Start/Restart Instances in the Common Tasks pane.
Configuring SSL/TLS for a Listener Using the CLI
To view the SSL/TLS properties of an HTTP or TCP listener, run the get-ssl-prop command, as shown in the following example:
tadm> get-ssl-prop --config=soa --http-listener=ls1
enabled=false
strict-sni-vs-host-match=false
client-auth=false
tls=true
max-client-auth-data=1048576
tls-session-tickets-enabled=false
ssl3=true
tls-rollback-detection=true
client-auth-timeout=60
To configure SSL/TLS for an HTTP or TCP listener, run the set-ssl-prop command, as shown in the following example:
tadm> set-ssl-prop --config=soa --http-listener=ls1 enabled=true server-cert-nickname=rsa-cert1
OTD-70201 Command 'set-ssl-prop' ran successfully.
For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by running the deploy-config command, and restart the instances by running the restart-instance command.
For more information about the CLI commands mentioned in this section, see the Oracle Traffic Director Command-Line Reference or run the command with the --help option.
Note:
When you enable SSL/TLS for an HTTP or TCP listener, initialization of PKCS#11 cryptographic tokens for the certificates database in the configuration is enabled automatically. For more information about configuring PKCS#11 tokens, see Section 11.5, "Managing PKCS#11 Tokens."
You can associate one RSA and one ECC certificate with each virtual server, by using either the administration console or the CLI. For information about the logic that Oracle Traffic Director uses to select the certificate to be sent to a client during the SSL/TLS handshake, see Section 11.2.5, "Certificate-Selection Logic."
Before you start, obtain the required certificates and install them as described in sections Section 11.4.1, Section 11.4.2, and Section 11.4.3.
Note:
When you modify virtual servers, you are, in effect, modifying a configuration. So for the updated configuration to take effect in the Oracle Traffic Director instances, you should redeploy the configuration as described in Section 4.3, "Deploying a Configuration."
If you associate new certificates with a virtual server or remove previously associated certificates, for the changes to take effect, you must restart the instances. It is not sufficient to merely deploy the updated configuration.
The CLI examples in this section are shown in shell mode (tadm>). For information about invoking the CLI shell, see Section 2.3.1, "Accessing the Command-Line Interface."
Associating Certificates with Virtual Servers Using the Administration Console
To associate certificates with virtual servers by using the administration console, do the following:
Log in to the administration console, as described in Section 2.3.2, "Accessing the Administration Console."
Click the Configurations button that is situated at the upper left corner of the page.
A list of the available configurations is displayed.
Select the configuration for which you want to associate certificates with virtual servers.
In the navigation pane, expand Virtual Servers and select the virtual server for which you want to associate certificates.
The Virtual Server Settings page is displayed.
Go to the Certificates section of the Virtual Server Settings page.
In the RSA Certificate and ECC Certificate fields, select the certificates that you want to use to authenticate the server.
When you change the value in a field or tab out of a text field that you changed, the Save button near the upper right corner of the page is enabled.
At any time, you can discard the changes by clicking the Reset button.
After making the required changes, click Save.
A message, confirming that the updated listener was saved, is displayed in the Console Messages pane.
Click the Deployment Pending button that is displayed at the top of the main pane, and on the resulting dialog box, confirm the deployment by clicking Deploy.
Restart the instances of the configuration by clicking Start/Restart Instances in the Common Tasks pane.
Associating Certificates with Virtual Servers Using the CLI
To view the certificates that are currently associated with a virtual server, run the get-virtual-server-prop command, as shown in the following example:
tadm> get-virtual-server-prop --config=soa --vs=soa.example.com server-cert-nickname
cert-rsa-soa
To associate a certificate with a virtual server, run the set-virtual-server-prop command, as shown in the following example:
tadm> set-virtual-server-prop --config=soa --vs=soa.example.com server-cert-nickname=cert-ecc-soa
OTD-70201 Command 'set-virtual-server-prop' ran successfully.
For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by running the deploy-config command, and restart the instances by running the restart-instance command.
For more information about the CLI commands mentioned in this section, see the Oracle Traffic Director Command-Line Reference or run the command with the --help option.
Note:
If you associate a virtual server with an RSA certificate and with an ECC certificate, the certificate that the server eventually sends to the client is determined during the SSL/TLS handshake, based on the cipher suite that the client and the server negotiate to use.
Make sure that a certificate of the same type—ECC or RSA—that you want to associate with the virtual server, is also associated with the listeners to which the virtual server is bound.
During the SSL/TLS handshake, the client and server inform each other about the SSL and TLS ciphers that they support and then negotiate the cipher—typically, the strongest—that they will use for the SSL/TLS session. For basic conceptual information about ciphers, see "About Ciphers".
You can configure the ciphers that Oracle Traffic Director supports for a listener by using either the administration console or the CLI.
Configuring Ciphers for a Listener Using the Administration Console
To configure the ciphers supported for an HTTP or TCP listener by using the administration console, do the following:
Log in to the administration console, as described in Section 2.3.2, "Accessing the Administration Console."
Click the Configurations button that is situated at the upper left corner of the page.
A list of the available configurations is displayed.
Select the configuration for which you want to configure ciphers.
In the navigation pane, expand Listeners and select the listener for which you want to configure ciphers.
The Listener Settings page is displayed.
Go to the Advanced Settings section of the page and scroll down to the SSL subsection.
In the SSL3/TLS Ciphers field, select the check boxes for the ciphers that you want to enable for the listener, and deselect the check boxes for the ciphers that you want to disable.
After making the required changes, click Save.
A message, confirming that the updated listener was saved, is displayed in the Console Messages pane.
Click the Deployment Pending button that is displayed at the top of the main pane, and on the resulting dialog box, confirm the deployment by clicking Deploy.
For the cipher changes to take effect, restart the instances of the configuration by clicking Start/Restart Instances in the Common Tasks pane.
Configuring Ciphers for a Listener Using the CLI
To view the ciphers that are currently enabled for an HTTP or TCP listener, run the list-ciphers command, as shown in the following example:
tadm> list-ciphers --config=soa --http-listener=http-listener-1|--tcp-listener=tcp-listener-1
This command returns a list of all the ciphers that Oracle Traffic Director supports and indicates whether they are enabled for the listener.
To enable specific ciphers for a listener, run the enable-ciphers command.
For example, the following command enables two additional ciphers—TLS_RSA_WITH_AES_128_CBC_SHA and TLS_RSA_WITH_AES_256_CBC_SHA—for the listener http-listener-1 in the configuration soa.
tadm> enable-ciphers --config=soa --http-listener=http-listener-1 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA
To disable ciphers for a listener, run the disable-ciphers command, as shown in the following example:
tadm> disable-ciphers --config=soa --http-listener=http-listener-1 TLS_RSA_WITH_AES_256_CBC_SHA
OTD-70201 Command 'disable-ciphers' ran successfully.
For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the deploy-config command.
For more information about the CLI commands mentioned in this section, see the Oracle Traffic Director Command-Line Reference or run the commands with the --help option.
Cipher Suites Supported by Oracle Traffic Director
During the SSL/TLS handshake, Oracle Traffic Director and clients negotiate the cipher suites to be used. Table 11-1 lists the cipher suites supported in Oracle Traffic Director. You can view this list by running the list-ciphers CLI command, as described earlier in this section. The name of each cipher suite indicates the key-exchange algorithm, the hashing algorithm, and the encryption algorithm, as depicted in.
Protocols supported
TLS: TLS 1.0
SSL: SSL 3 and TLS 1.0
Key exchange algorithms supported
RSA
RSA_EXPORT
RSA_EXPORT1024
RSA_FIPS
ECDHE_RSA
ECDH_RSA
ECDH_ECDSA
ECDHE_ECDSA
Encryption algorithms supported
AES_256_CBC: 256-bit key
CAMELLIA_256_CBC: 256-bit key
3DES_EDE_CBC: 168-bit key
AES_128_CBC: 128-bit key
CAMELLIA_128_CBC: 128-bit key
RC4_128: 128-bit key
SEED_CBC: 128-bit key
DES_CBC: 56-bit key
RC4_56: 56-bit key
RC4_40 and RC2_CBC_40: 128-bit key but only 40 bits have cryptographic significance
NULL: No encryption
Message Authentication Code (MAC) algorithms supported
SHA: 160-bit hash
MD5: 128-bit hash
NULL: No hashing
Table 11-1 Cipher Suites Supported in Oracle Traffic Director
| Cipher Suite | FIPS 140 Compliant? | Exportable? |
|---|---|---|
|
SSL_RSA_WITH_RC4_128_MD5 |
||
|
SSL_RSA_WITH_RC4_128_SHA |
||
|
SSL_RSA_WITH_3DES_EDE_CBC_SHA |
||
|
SSL_RSA_WITH_DES_CBC_SHA |
||
|
SSL_RSA_EXPORT_WITH_RC4_40_MD5 |
Yes |
|
|
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 |
Yes |
|
|
SSL_RSA_WITH_NULL_MD5 |
||
|
SSL_RSA_WITH_NULL_SHA |
||
|
SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA |
Yes |
|
|
SSL_RSA_FIPS_WITH_DES_CBC_SHA |
Yes |
|
|
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA |
Yes |
|
|
TLS_ECDHE_RSA_WITH_NULL_SHA |
||
|
TLS_ECDHE_RSA_WITH_RC4_128_SHA |
||
|
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA |
Yes |
|
|
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA |
Yes |
|
|
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA |
Yes |
|
|
TLS_ECDH_RSA_WITH_RC4_128_SHA |
||
|
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA |
Yes |
|
|
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA |
Yes |
|
|
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA |
Yes |
|
|
TLS_ECDH_ECDSA_WITH_RC4_128_SHA |
||
|
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA |
Yes |
|
|
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA |
Yes |
|
|
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA |
Yes |
|
|
TLS_ECDHE_ECDSA_WITH_NULL_SHA |
||
|
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA |
||
|
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA |
Yes |
|
|
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA |
Yes |
|
|
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA |
Yes |
|
|
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA |
Yes |
|
|
TLS_RSA_WITH_AES_128_CBC_SHA |
Yes |
|
|
TLS_RSA_WITH_AES_256_CBC_SHA |
Yes |
|
|
TLS_RSA_WITH_SEED_CBC_SHA |
||
|
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA |
||
|
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA |
Source for FIPS 40-compliance information: http://www.mozilla.org/projects/security/pki/nss/ssl/fips-ssl-ciphersuites.html
When an HTTPS request is received, the certificate that Oracle Traffic Director sends to the client during the SSL/TLS handshake could be one of the following:
A certificate associated with a virtual server bound to a configured HTTP/TCP listener
A certificate associated with the default virtual server of the listener
A certificate associated with the listener
Oracle Traffic Director uses the following logic to determine the certificate that should be sent to the client during the SSL/TLS handshake.
Table 11-2 Certificate-Selection Logic
| Condition | Case A | Case B | Case C | Case D |
|---|---|---|---|---|
|
Client sent SNI host extension |
Yes |
Yes |
Yes |
No |
|
A matchingFoot 1 virtual server is found. |
Yes |
No |
No |
-- |
|
The matching virtual server has a certificate of a type—RSA or ECC— that matches the ciphers sent by the client. |
Yes |
-- |
-- |
-- |
|
The default virtual server of the listener has a certificate of a type—RSA or ECC— that matches the ciphers sent by the client. |
-- |
Yes |
-- |
-- |
|
The listener has a certificate of a type—RSA or ECC— that matches the ciphers sent by the client. |
-- |
-- |
Yes |
Yes |
|
Certificate selected: |
Certificate of the matching virtual server |
Certificate of the default virtual server |
Certificate of the listener |
Certificate of the listener |
Footnote 1 A matching virtual server is a virtual server that is bound to the listener and has a host pattern that matches the Host: header sent by the client.
When a client sends an HTTPS request to an SSL/TLS-enabled Oracle Traffic Director instance, the server needs to send a certificate to the client to initiate the SSL/TLS handshake. If the host name in the request does not match the server name (common name, CN) in the certificate provided by the server, a warning message is displayed by the client to the user. To continue with the SSL/TLS handshake process, the user must then explicitly choose to trust the certificate.
If an Oracle Traffic Director instance contains multiple, name-based virtual servers configured with a single IP address and port combination, to determine the appropriate certificate that should be sent to the client, the server needs to know the value of the Host header in the HTTP request, which it cannot read until after the SSL/TLS connection is established.
An extension to the SSL and TLS protocols, called Server Name Indication (SNI), addresses this issue, by allowing clients to provide the requested host name during the SSL/TLS handshake in the SNI host extension. Oracle Traffic Director uses the host name in the SNI host extension to determine the virtual server certificate that it should send to the client. For information about associating certificates with virtual servers, see Section 11.2.3, "Associating Certificates with Virtual Servers."
Support for SNI is enabled by default for SSL/TLS-enabled HTTP listeners in Oracle Traffic Director. For stricter control, like if you want to prevent non-SNI clients from accessing name-based virtual servers, you should enable the Strict SNI Host Matching parameter.
When Strict SNI Host Matching is enabled for an HTTP listener, and if for that listener at least one of the virtual servers has certificates, then Oracle Traffic Director returns a 403-Forbidden error to the client, if any of the following conditions is true:
The client did not send the SNI host extension during the SSL/TLS handshake.
The request does not have the Host: header.
The host name sent by the client in the SNI host extension during the SSL/TLS handshake does not match the Host: header in the request.
This section provides basic information about security-related concepts. It contains the following topics:
Secure Socket Layer (SSL) is a protocol for securing Internet communications and transactions. It enables secure, confidential communication between a server and clients through the use of digital certificates. Oracle Traffic Director supports SSL v3 and Transport Layer Security (TLS) v1.
In a 2-way HTTP over SSL (HTTPS) connection, each party—say a browser or a web server—first verifies the identity of the other. This phase is called the SSL/TLS handshake. After the identities are verified, the connection is established and data is exchanged in an encrypted format. The following are the steps in the SSL/TLS handshake between an SSL-enabled browser and an SSL-enabled server:
The browser attempts to connect to the server by sending a URL that begins with https:// instead of http://.
The server sends its digital certificate (see "About Certificates") and public key to the client.
The client checks whether the server's certificate is current (that is, it has not expired) and is issued by a certificate authority (CA) that the client trusts.
If the certificate is valid, the client generates a one-time, unique session key and encrypts it with the server's public key, and then sends the encrypted session key to the server.
The server decrypts the message from the client by using its private key and retrieves the session key.
At this point, the client has verified the identity of the server; and only the client and the server have a copy of the client-generated, unique session key. Till the session is terminated, the client and the server use the session key to encrypt all communication between them.
A cipher is an algorithm, a mathematical function, used for encrypting and decrypting data. Some ciphers are stronger and more secure than others. Usually, the more bits a cipher uses, the harder it is to decrypt the data encrypted using that cipher.
SSL v3 and TLS v1 support a variety of ciphers. Clients and servers may support different cipher suites (sets of ciphers), depending on factors such as the protocol they support, the organizational policies on encryption strength, and government restrictions on export of encrypted software.
In any 2-way encryption process, the client and the server must use the same cipher suite. During the SSL/TLS handshake process, the server and client negotiate the cipher suite—typically, the strongest one—that they will use to communicate.
Encryption using ciphers, by itself, does not ensure data security. A key must be used with the encrypting cipher to produce the actual encrypted result, or to decrypt previously encrypted information. The encryption process uses two keys—a public key and a private key. The keys are mathematically related; so information that is encrypted using a public key can be decrypted only using the associated private key, and vice versa. The public key is published by the owner as part of a certificate (see "About Certificates"); only the associated private key is safeguarded.
A certificate is a collection of data that uniquely identifies a person, company, or other entity on the Internet. It enables secure, confidential communication between two entities. Personal certificates are used by individuals; server certificates are used to establish secure sessions between the server and clients over SSL.
Certificates can be self-signed (by the server), signed by a trusted third party called Certification Authority (CA) or one that you created. The holder of a certificate can present the certificate as proof of identity to establish encrypted, confidential communication. The CA could be a third-party vendor or an internal department responsible for issuing certificates for an organization's servers.
Certificates are based on public-key cryptography, which uses a pair of keys (very long numbers) to encrypt information so that it can be read only by its intended recipient. The recipient then decrypts the information using one of the keys.
A certificate binds the owner's public key to the owner's identity. In addition to the public key, a certificate typically includes information such as the following:
The name of the holder and other identification, such as the URL of the server using the certificate
The name of the CA that issued the certificate
The digital signature of the issuing CA
The validity period of the certificate
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|