Application Layer Gateway Rules : Ensuring private keys stay in the data center
  
Ensuring private keys stay in the data center
Rule Title: If TLS WAN optimization is used, SSL optimization must protect private keys ensuring that they stay in the data center by ensuring end-to-end security.
STIG ID: RICX-AG-000038
Rule ID: SV-77305r1_rule Severity: CAT II
Vuln ID: V-62815 Class: Unclass
Protecting the end-to-end security of TLS is required to ensure integrity and confidentiality of the data in transit.
RiOS TLS optimization accelerates data transfers that are encrypted using TLS for SteelHead appliances that are deployed locally to both the client-side and server-side of the network. All of the same optimized connections that are applied to normal nonencrypted TCP traffic can also apply to encrypted TLS traffic. SteelHead appliances accomplish this without compromising end-to-end security and the established trust model. Private keys remain in the data center and are not exposed in remote locations where they might be compromised.
The RiOS TLS optimization solution starts with SteelHead appliances that have a configured trust relationship, enabling them to exchange information securely over their own dedicated TLS connection. Each client uses unchanged server addresses and each server uses unchanged client addresses; no application changes or explicit proxy configuration is required. RiOS uses a unique technique to split the TLS handshake. The handshake is the sequence of message exchanges at the start of a TLS connection. In an ordinary TLS handshake, the client and server first establish identity using public-key cryptography, and then negotiate a symmetric session key to use for data transfer. When using RiOS TLS acceleration, the initial TLS message exchanges take place between the client application (for example, a Web browser) and the server-side SteelHead appliance.
SteelHead WAN optimization platform works to ensure that TLS acceleration delivers the following:
sensitive cryptographic information is kept in the secure vault—a separate, encrypted store on the disk.
built-in support for popular Certificate Authorities (CAs) such as VeriSign, Thawte, Entrust, and GlobalSign. In addition, SteelHead appliances allow the installation of other commercial or privately operated Certificate Authorities (CAs).
import of server proxy certificates and keys in PEM, PKCS12, or DER formats. SteelHead appliances also support the generation of new keys and self-signed certificates. If your certificates and keys are in another format, first you must convert them to a supported format before you can import them into the SteelHead appliance.
separate control of cipher suites for client connections, server connections, and peer connections.
bulk export or bulk import server configurations (including keys and certificates) from or to, respectively, the server-side SteelHead appliance.
Verifying end-to-end SSL security settings
Verify that TLS optimization services are configured to ensure end-to-end security and protect private keys from unauthorized access.
1. Connect to the Management Console.
2. Choose Optimization > SSL: SSL Main Settings to display the SSL Main Settings page.
3. Verify that the Enable SSL Optimization check box is selected.
4. Verify that the SSL Server Certificates contain the certificates for SSL services that the organization wants to optimize.
5. If Enable SSL Optimization is not checked or there are no SSL Sever Certificates, this is a security vulnerability finding.
Configuring end-to-end SSL security settings
Configure TLS optimization services to provide end-to-end security and protection for private keys.
To configure SSL security settings:
1. Connect to the Management Console.
2. Choose Optimization > SSL: SSL Main Settings to display the SSL Main Settings page.
3. Choose SSL Server Certificates.
4. Click Add a New SSL Certificate to expand the page.
5. Select Import Existing Private Key and CA-Signed Public Certificates.
6. Select Local File and navigate to the certificate location on the management workstation.
7. Click Add.
8. Select the Enable SSL Optimization check box.
9. Click Apply.
To enable secure peering:
1. If you are securing encrypted MAPI traffic or Citrix traffic, enable one of these on both the server-side and client-side SteelHeads:
Choose Optimization > Protocols: MAPI and select Enable Encrypted Optimization.
—or—
Choose Optimization > Protocols: Citrix and select Enable SecureICA Encryption. Both SteelHeads must be running RiOS v7.0 or later.
If you are securing SMB-signed traffic, choose Configure > Optimization > CIFS and select Enable SMB Signing on the server-side SteelHead.
2. Either use N TP time synchronization or manually synchronize the clocks on both the server-side and client-side SteelHeads. The peer SteelHead time must be the same for the trust relationship to work.
3. On both the server-side and client-side SteelHeads, choose Configure > Optimization > Secure Peering (SSL) to display the Secure Peering (SSL) page.
4. Under SSL Secure Peering Settings, complete these configuration options:
Traffic Type specifies one of these traffic types from the drop-down list:
SSL Only—The peer client-side SteelHead and the server-side SteelHead authenticate each other and then encrypt and optimize all SSL traffic; for example, HTTPS traffic on port 443. This is the default setting.
SSL and Secure Protocols—The peer client-side SteelHead and the server-side SteelHead authenticate each other and then encrypt and optimize all traffic traveling over these secure protocols: Citrix, SSL, SMB-signed, and encrypted MAPI.
MAPI encryption or SecureICA encryption must be enabled on both the client-side and server-side SteelHeads when securing encrypted MAPI traffic, or encrypted Citrix ICA traffic (RiOS v7.0 and later).
Enabling this option requires an optimization service restart.
All—The peer client-side SteelHead and the server-side SteelHead authenticate each other and then encrypt and optimize all traffic. Only the optimized traffic is secure; pass-through traffic is not. Enabling this option requires an optimization service restart.
Selecting All can cause up to a 10 percent performance decline in higher-capacity SteelHeads. Take this performance metric into account when sizing a complete secure SteelHead peering environment.
Fallback to No Encryption specifies that the SteelHead optimizes but does not encrypt the connection when it is unable to negotiate a secure, encrypted inner channel connection with the peer. This is the default setting. Enabling this option requires an optimization service restart.
We strongly recommend enabling this setting on both the client-side and the server-side SteelHeads, especially in mixed deployments where one SteelHead is running RiOS v6.0 or later and the other SteelHead is running an earlier RiOS version.
This option applies only to non-SSL traffic and is unavailable when you select SSL Only as the traffic type.
Clear the check box to pass through connections that do not have a secure encrypted inner channel connection with the peer. Use caution when disabling this setting, as doing so specifies that you strictly do not want traffic optimized between non-secure SteelHeads. Consequently, when this setting is disabled connections might be dropped: for example, consider a configuration with a client-side SteelHead running RiOS v5.5.x or earlier and a server-side SteelHead running RiOS v6.0. When this setting is disabled on the server-side SteelHead and All is selected as the traffic type, it will not optimize the connection when a secure channel is unavailable, and might drop it.
5. Click Apply.
6. If you have changed an encryption setting, you need to restart the optimization service.
The SteelHead supports RSA private keys for peers and SSL servers.