SSL Certificates

Server Authentication

Implicit trust between the client and the device (because the client accepts the certificate generated by the device) is an important aspect of SSL proxy. It is extremely important that server authentication is not compromised; however, in reality, self-signed certificates and certificates with anomalies are in abundance. Anomalies can include expired certificates, instances of common name not matching a domain name, and so forth.

Server authentication is governed by setting the ignore-server-auth-failure option in the SSL proxy profile. The results of setting this option is available in Table 1.

Table 1: Ignore Server Authentication Failure Option

SSL Proxy Profile Action	Results
The ignore-server-auth-failure option is not set (Default option)	If authentication succeeds, a new certificate is generated by replacing the keys and changing the issuer name to the issuer name that is configured in the root CA certificate in the proxy profile. If authentication fails, the connection is dropped.
The ignore-server-auth-failure option is set	If the certificate is self-signed, a new certificate is generated by replacing the keys. The issuer name is not changed. This ensures that the client browser displays a warning that the certificate is not valid. If the certificate has expired or if the common name does not match the domain name, a new certificate is generated by replacing the keys and changing the issuer name to SSL-PROXY: DUMMY_CERT:GENERATED DUE TO SRVR AUTH FAILURE. This ensures that the client browser displays a warning that the certificate is not valid. We do not recommend this option for authentication, because configuring it results in websites not being authenticated at all. However, you can use this option to effectively identify the root cause for dropped SSL sessions. See Enabling Debugging and Tracing for SSL Proxy.

Client Authentication

Currently, client authentication is not supported in SSL proxy. If a server requests client authentication, a warning is issued that a certificate is not available. The warning lets the server determine whether to continue or to exit.

Optimizing the SSL Performance

The SSL/TLS handshake is a CPU-intensive process. Since SSL/TLS is the most widely used security protocol on the web, it’s performance results in significant impact on the web performance.

Starting from Junos OS Release 15.1X49-D120, you can use the following options for optimizing the performance:

• Use optimized RSA key exchanges

• Use Authenticated Encryption with Associated Data (AEAD)—AES128-CBC-SHA, AES256-CBC-SHA

• Maintaining certificate cache—Certificate cache stores the interdicted server certificate along with the server certificate details. During SSL/TLS handshake, SSL proxy can present the cached interdicted certificate to client instead of generating the new interdicted certificate.

Improving the SSL performance results in improved website performance without compromising security and maximized user experience.

You can optionally configure the following settings for your certificate cache. However, we recommend retaining the default values.

Example:

• (Optional) Set the certificate cache timeout value (example- 300 seconds) .

  In this example, the certificate cache stores the certificate details for 300 seconds. The default timeout value is 600 seconds.

• (Optional) Disable the certificate cache.

  When you disable certificate cache, the device allows the SSL full handshake for a new connection. By default certificate cache is enabled.

• (Optional) Invalidate the existing certificate cache.

  In this example, the device invalidates the existing certificate cache when certificate revocation list (CRL) is updated. By default, invalidate certificate cache on CRL update is disabled.

Session Resumption

SSL session resumption provides a mechanism to resume a previous session using already negotiated session IDs. Session resumption saves the client and server the computational overhead of a complete SSL handshake and generation of new primary keys.

Session resumption shortens the handshake process and accelerates SSL transactions resulting in improved performance while maintaining appropriate level of security.

TLS 1.2 supports session resumption with session identifiers and session tickets mechanisms. An SSL session resumption includes the following steps:

• A session caching mechanism caches session information, such as the pre-master secret key and agreed-upon ciphers for both the client and server.

• Session ID identifies the cached information.

• In subsequent connections both parties agree to use the session ID to retrieve the information rather than create a pre-master secret key.

Starting in Junos OS Release 22.1R1, TLS 1.3 supports session resumption using a pre-shared key (PSK) in SSL proxy. Session resumption using PSK allows resuming a session with a previously established shared secret key to reduce SSL handshake overhead.

PSK is a unique encryption key derived from the initial TLS handshake. After a successful TLS handshake, the server sends a PSK identity to the client. The client uses that PSK identity in the future handshakes to negotiate the use of associated PSK to resume the session.

An SSL session resumption with TLS1.3 includes the following steps:

1. After an initial TLS handshake, the server sends a new Session Ticket message to the client, which contains the PSK identity (encrypted copy of the PSK).

2. Next time, when the client attempts to resume the session, it sends the same Session Ticket to the server in the Hello message.
3. The server decrypts the message, identifies the PSK, and retrieves the session information from its cache to resume the session.

An SSL-I (SSL initiation) uses PSK with ECDHE key exchange mode, and SSL-T (SSL termination) uses PSK and PSK with ECDHE exchange modes.

SSL proxy session supports interoperability between TLS1.3 and TLS1.2 and earlier versions on two ends of a connection for session resumption.

By default, session resumption is enabled for SSL proxy. You can clear the session resumption or re-enable as per your requirements.

• To clear the session resumption:
• To re-enable session resumption:

Use the following command to configure the session timeout value.

You can configure the timeout value between 300 seconds to 86400 seconds. The default value is 86400 seconds (24 hours).

Session Renegotiation

The SRX Series Firewall support session renegotiation. After a session is created and SSL tunnel transport is established, a change in SSL parameters requires renegotiation. SSL proxy supports both secure (RFC 5746) and nonsecure (TLS v1.0, TLS v1.1, and TLS v1.2) renegotiation. When session resumption is enabled, session renegotiation is useful in the following situations:

• Cipher keys need to be refreshed after a prolonged SSL session.

• Stronger ciphers need to be applied for a more secure connection.

If you modify the SSL proxy profile by changing a certificate, or cipher strength, or trusted CA list, then the system flushes the cache entries when you commit the modified policy. In this case, a full handshake is required to establish the new SSL parameters. (There is no impact to non-SSL sessions.)

If the SSL proxy profile is not altered, cache entries corresponding to that profile are not flushed and the session continues.

Negotiating StartTLS for SMTP Sessions

The StartTLS enables an SMTP session from an initial plain TCP connection to a more secure TLS connection. StartTLS allows SMTP session between the server and client over the TLS layer after successful negotiation between the peers. StartTLS upgrades an existing insecure plain SMTP connection to a secure SSL/TLS connection.

You can set threshold that allow you to decide how long to wait before ignoring the the session if StartTLS is not received from the client.

You can configure the following options:

• byte-threshold—Minimum bytes of unencrypted session allowed before ignoring the session if StartTLS is not received from the client. Range 100 to 300.
• packet-threshold—Number of unencrypted packets allowed in client-to-server direction before ignoring the session if StartTLS is not received from the client. Range 1 to 15.

Example:

In this exaple, SSL proxy allows 100 bytes of plain (unencrypted) SMTP traffic. After reaching 100 bytes, it ignores the session if StartTLS is not received from the client.

In this example, SSL proxy allows 2 packets of plain (unencrypted) SMTP traffic. After reaching 2 packets, it ignores the session if StartTLS is not received from the client.

Dynamic Resolution of Domain Names

The IP addresses associated with domain names are dynamic and can change at any time. Whenever a domain IP address changes, it is propagated to the SSL proxy configuration (similar to what is done in the firewall policy configuration).