Encrypt Traffic Using SSL Proxy and TLS

SSL Proxy Overview

Secure Sockets Layer (SSL) is an application-level protocol that provides encryption technology for the Internet. SSL, also called Transport Layer Security (TLS), ensures the secure transmission of data between a client and a server through a combination of privacy, authentication, confidentiality, and data integrity. SSL relies on certificates and private-public key exchange pairs for this level of security.

Server authentication guards against fraudulent transmissions by enabling a Web browser to validate the identity of a webserver. Confidentiality mechanisms ensure that communications are private. SSL enforces confidentiality by encrypting data to prevent unauthorized users from eavesdropping on electronic communications. Finally, message integrity ensures that the contents of a communication have not been tampered with.

SSL proxy is transparent; that is, it performs SSL encryption and decryption between the client and the server.

Sharing server keys is sometimes not feasible or might not be available in certain circumstances, in which case the SSL traffic cannot be decrypted. SSL proxy addresses this problem by ensuring that it has the keys to encrypt and decrypt the payload:

• For the server, SSL proxy acts as a client—Because SSL proxy generates the shared pre-master key, it determines the keys to encrypt and decrypt.

• For the client, SSL proxy acts as a server—SSL proxy first authenticates the original server and replaces the public key in the original server certificate with a key that is known to it. It then generates a new certificate by replacing the original issuer of the certificate with its own identity and signs this new certificate with its own public key (provided as a part of the proxy profile configuration). When the client accepts such a certificate, it sends a shared pre-master key encrypted with the public key on the certificate. Because SSL proxy replaced the original key with its own key, it is able to receive the shared pre-master key. Decryption and encryption take place in each direction (client and server), and the keys are different for both encryption and decryption.

Figure 1 shows how SSL proxy works on an encrypted payload. When Advanced Security services such as application firewall (AppFW), Intrusion Detection and Prevention (IDP),application tracking (AppTrack), UTM, and SkyATP is configured, the SSL proxy acts as an SSL server by terminating the SSL session from the client and establishing a new SSL session to the server. The SRX Series device decrypts and then reencrypts all SSL proxy traffic. SSL proxy uses the following:

• SSL-T-SSL terminator on the client side.

• SSL-I-SSL initiator on the server side.

IDP, AppFW, AppTracking, advanced policy-based routing (APBR), UTM, SkyATP, and ICAP service redirect can use the decrypted content from SSL proxy. If none of these services are configured, then SSL proxy services are bypassed even if an SSL proxy profile is attached to a firewall policy.

Figure 1: SSL Proxy on an Encrypted Payload

Benefits of SSL Proxy

• Decrypts SSL traffic to obtain granular application information and enable you to apply advanced security services protection and detect threats.

• Enforces the use of strong protocols and ciphers by the client and the server.

• Provides visibility and protection against threats embedded in SSL encrypted traffic.

• Controls what needs to be decrypted by using Selective SSL Proxy.

Perfect Forward Secrecy

Perfect Forward Secrecy (PFS) is a feature of specific key agreement protocols that provides assurances your session keys will not be compromised even if the private key of the server is compromised. By generating a unique session key for every session flow a user initiates, the compromise of a single session key will not affect any data other than that exchanged in the specific session protected by that particular key. For PFS to function, the key used to protect transmission of data must not be used to derive any additional keys, and if the key used to protect transmission of data was derived from some other keying material, that material must not be used to derive any further keys.

ECDHE stands for Elliptic Curve Diffie Hellman Ephemeral and is a key exchange mechanism based on elliptic curve cryptography. The ECDHE cipher suits are used to enable the PFS on SSL proxy.

ECDHE cipher suits provide the same level of security as the RSA with smaller keys. SSL proxy is targeted to support only ECDHE ciphers suites because they are less expensive computationally than DHE ciphers.

Supported Key Size

Table 1 provides the details of RSA keys supported on various SRX Series devices.

Supported Ciphers in Proxy Mode

An SSL cipher comprises encryption ciphers, an authentication method, and compression. Table 2 displays a list of supported ciphers. NULL ciphers are excluded.

ECDSA Cipher Suite Support for SSL Proxy

Starting in Junos OS Release 18.3R1, ECDSA cipher suites are supported for SSL proxy. ECDSA is a version of the Digital Signature Algorithm (DSA) and is based on Elliptic-curve cryptography (ECC).

To support ECDSA ciphers, the device must include the certificates containing ECC-capable public keys. You can include the ECC certificate along with an existing RSA certificate in an SSL proxy profile. Having both ECC and RSA certificate allows you to perform ECC-based key exchange or RSA-based key exchange depending on the client and the server device’s compatibility.

For example:

During an SSL handshake, ECDSA cipher can be used only when the server supports the ECC certificate. Otherwise, SSL proxy is done using RSA-based key exchange. If the SRX Series device has only ECC certificate (no RSA certificate), and the server supports only the RSA-based authentication, then the session is dropped with an error message.

You can include the ECDSA certificate option for the root CA (SSL forward proxy) and for the server certificate (SSL reverse proxy). For the server certificate, there is no restriction on the number of ECDSA or RSA certificate inclusion; however for the root CA, you can include one RSA certificate and one ECDSA certificate each.

A trusted CA certificate can either be an RSA-based certificate and an ECDSA-based certificate. All features supported on an RSA-based certificate such as certificate cache, certificate revocation list (CRL), certificate chain are supported on an ECDSA certificate.

Configuring Ciphers for SSL Proxy

• Preferred Ciphers–Preferred ciphers allow you to define an SSL cipher that can be used with acceptable key strength. Ciphers are divided in three categories depending on their key strength: strong, medium, or weak.

• Custom Ciphers–Custom ciphers allow you to define your own cipher list. If you do not want to use one of the three categories, you can select ciphers from each of the categories to form a custom cipher set. To configure custom ciphers, you must set preferred-ciphers to custom.

  The following example shows how to create a custom cipher. In this example, you set preferred-cipher to custom and add the cipher list (rsa-with-3des-ede-cbc-sha and rsa-with-aes-256-cbc-sha):

The following procedure shows how to configure a custom cipher for ECDSA ciphers.

1. Load the ECDSA certificate (rootCA.pem) and the key (rootCA.key) into PKI, and use the ECDSA certificate as a server certificate for the SSL forward proxy.

   You can generate a root CA certificate or you can import your own trusted CA certificate and private and public keys into the SRX Series device. For details on root CA certificates, see Configuring a Root CA Certificate

2. Create an SSL proxy profile. You must configure either the Root CA or the server certificate in an SSL proxy profile.

   Or
3. Enable preferred-cipher in the SSL proxy as a custom-cipher.
4. Attach a custom cipher (example: ecdhe-ecdsa-with-aes-256-cbc-sha384 and ecdhe-ecdsa-with-aes-128-cbc-sha256).

After performing the steps mentioned above, proceed with configuring the SSL proxy profile and applying the SSL proxy profile to a security policy.

Supported SSL Protocols

• TLS version 1.0—Provides authentication and secure communications between communicating applications.

• TLS version 1.1—This enhanced version of TLS provides protection against cipher block chaining (CBC) attacks.

• TLS version 1.2 — This enhanced version of TLS provides improved flexibility for negotiation of cryptographic algorithms.

Starting with Junos OS Release 15.1X49-D30 and Junos OS Release 17.3R1, TLS version 1.1 and TLS version 1.2 protocols are supported on SRX Series devices along with TLS version 1.0.

Starting with Junos OS Release 15.1X49-D20 and Junos OS Release 17.3R1, the SSL protocol 3.0 (SSLv3) support is deprecated.

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.

• By default, the ignore-server-auth-failure option is not defined as an action in the SSL proxy profile, and the following occurs:

  • 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.

• If the ignore-server-auth-failure option is defined as an action in the SSL proxy profile, the following occurs:

  • If the certificate is self-signed, a new certificate is generated by replacing the keys only. 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.

Trusted CA List

SSL proxy ensures secure transmission of data between a client and a server. Before establishing a secure connection, SSL proxy checks CA certificates to verify signatures on server certificates. For this reason, a reasonable list of trusted CA certificates is required to effectively authenticate servers.

• Loading the default trusted CA list—Junos OS provides a default list of certificates that contains well-known trusted CA certificates similar to the default certificates used by most common browsers. Without these default certificates, browsers would not be able to validate the identity of most websites and would mark them as untrusted sites. Alternatively, you can download trusted CAs from a browser to an SRX Series device. See Knowledge Base Article KB23144.

  The Junos OS package contains the default CA certificates as a Privacy-Enhanced Mail (PEM) file (for example, trusted_CA.pem). After you download the package, you can easily load the default certificates on your system using the request security pki ca-certificate ca-profile-group load ca-group-name ca-default filename default command. You can use the default trusted CA bundle file embedded into Junos OS or you can download the latest CA bundle list from another 3rd party such as Mozilla (https://curl.haxx.se/docs/caextract.html). The list of trusted Certificate Authority can change over time so we recommend you to use the latest CA bundle.

  We recommend you load the default trusted CA list if you want to trust the same CA certificates as common browsers and avoid importing CA certificates manually.

  Note

  By default, Junos OS does not trust any CA certificate.

• Importing the trusted CA list manually—You can import your own trusted CA certificates using the Public Key Infrastructure (PKI). The PKI helps verify and authenticate the validity of the trusted CA certificates. You create CA profile groups that include trusted CA certificates, then import the group on your device for server authentication.

• Ignoring server authentication—You can use the ignore-server-auth-failure option to ignore server authentication completely. In this case, SSL proxy ignores errors encountered during the server certificate verification process (such as CA signature verification failure, self-signed certificates, and certificate expiry).

  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.

Root CA

In a public key infrastructure (PKI) hierarchy, the root CA is at the top of the trust path. The root CA identifies the server certificate as a trusted certificate.

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.

Whitelists

Because SSL encryption and decryption might consume memory resources on the SRX Series device, network administrators can selectively bypass SSL proxy processing for some sessions. Such sessions mostly include connections and transactions with trusted servers or domains with which network administrators are very familiar. There are also legal requirements to exempt financial and banking sites. Such exemptions are achieved by configuring the IP addresses or domain names of the servers under whitelists.

Starting with Junos OS Release 15.1X49-D80 and Junos OS Release 17.3R1, the whitelisting feature is extended to include URL categories supported by UTM in the whitelist configuration of SSL forward proxy. In this implementation, the Server Name Indication (SNI) field is extracted by the UTM module from client hello messages to determine the URL category. Each URL category has a unique ID. The list of URL categories under whitelist is parsed and the corresponding category IDs are pushed to the Packet Forwarding Engine for each SSL forward proxy profile. The SSL forward proxy then determines through APIs whether to accept, and proxy, or to ignore the session.

Starting with Junos OS Release 17.4R1, the whitelisting feature is extended to support custom URL categories supported by UTM in the whitelist configuration of SSL forward proxy.

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).

Session Resumption

An SSL session refers to the set of parameters and encryption keys created by performing a full handshake. A connection is the conversation or active data transfer that occurs within the session. The computational overhead of a complete SSL handshake and generation of master keys is considerable. In short-lived sessions, the time taken for the SSL handshake can be more than the time for data transfer.

To improve throughput and still maintain an appropriate level of security, SSL session resumption provides a session caching mechanism so that session information, such as the pre-master secret key and agreed-upon ciphers, can be cached for both the client and server. The cached information is identified by a session ID. In subsequent connections both parties agree to use the session ID to retrieve the information rather than create a new pre-master secret key. Session resumption shortens the handshake process and accelerates SSL transactions.

Session Renegotiation

After a session is created and SSL tunnel transport has been 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.

A change in an SSL proxy profile that modifies a certificate, cipher strength, or trusted CA list flushes cache entries when the modified policy is committed. When a session is resumed, the SSL parameters associated with its session ID are retrieved from the cache. If the SSL proxy profile is not altered, cache entries corresponding to that profile are not flushed and the session continues. If the cache has been flushed, however, a full handshake must be performed to establish the new SSL parameters. (There is no impact to non-SSL sessions.)

SSL Proxy Logs

When logging is enabled in an SSL proxy profile, SSL proxy can generate the messages shown in Table 3.

All logs contain similar information as shown in the following example (actual order of appearance):

The message field contains the reason for the log generation. One of three prefixes shown in Table 4 identifies the source of the message. Other fields are descriptively labeled.

Sample logs:

For SSL_PROXY_SESSION_WHITELIST messages, an additional host field is included after the session-id and contains the IP address of the server or domain that has been whitelisted.

Leveraging Dynamic Application Identification

SSL proxy uses application identification services to dynamically detect if a particular session is SSL encrypted. SSL proxies are allowed only if a session is SSL encrypted. The following rules apply for a session:

• Session is marked Encrypted=Yes in the application system cache. If the session is marked Encrypted=Yes, it indicates that the final match from application identification for that session is SSL encrypted, and SSL proxy transitions to a state where proxy functionality can be initiated.

• Session is marked Encrypted=No in the application system cache. If a non-SSL entry is found in the application system cache, it indicates that the final match from application identification for that session is non-SSL and SSL proxy ignores the session.

• An entry is not found in the application system cache. This can happen on the first session, or when the application system cache has been cleaned or has expired. In such a scenario, SSL proxy cannot wait for the final match (requires traffic in both directions). In SSL proxy, traffic in reverse direction happens only if SSL proxy has initiated an SSL handshake. Initially, for such a scenario SSL proxy tries to leverage prematch or aggressive match results from application identification , and if the results indicate SSL, SSL proxy will go ahead with the handshake.

• Application identification fails due to resource constraints and other errors. Whenever the result from application identification is not available, SSL proxy will assume static port binding and will try to initiate SSL handshake on the session. This will succeed for actual SSL sessions, but it will result in dropped sessions for non SSL sessions.

Logical Systems Support

It is possible to enable SSL proxy on firewall policies that are configured using logical systems; however, note the following limitations:

• The “services” category is currently not supported in logical systems configuration. Because SSL proxy is under “services,” you cannot configure SSL proxy profiles on a per-logical-system basis.

• Because proxy profiles configured at a global level (within “services ssl proxy”) are visible across logical system configurations, it is possible to configure proxy profiles at a global level and then attach them to the firewall policies of one or more logical systems.

Limitations

Configuring SSL Forward Proxy

• SSL Proxy Configuration Overview

• Configuring a Root CA Certificate

• Configuring a CA Profile Group

• Configuring a Trusted CA Profile

• Importing a Root CA Certificate into a Browser

• Applying an SSL Proxy Profile to a Security Policy

• Creating a Whitelist of Exempted Destinations

• Configuring SSL Proxy Logging

• Exporting Certificates to a Specified Location

• Ignoring Server Authentication

SSL Proxy Configuration Overview

Figure 2 displays an overview of how SSL proxy is configured. It includes some required steps, such as configuring the root CA certificate, loading a CA profile group, and applying an SSL proxy profile to a security policy, and some optional steps, such as creating whitelists and SSL proxy logging.

Figure 2: SSL Proxy Configuration Overview

Configuring a Root CA Certificate

A CA can issue multiple certificates in the form of a tree structure. A root certificate is the topmost certificate of the tree, the private key of which is used to sign other certificates. All certificates immediately below the root certificate inherit the signature or trustworthiness of the root certificate. This is somewhat like the notarizing of an identity.

You can configure a root CA certificate by first obtaining a root CA certificate (by either generating a self-signed one or importing one) and then applying it to an SSL proxy profile. There are two ways you can obtain a root CA certificate—by using the Junos OS CLI on an SRX Series device or by using OpenSSL on a UNIX device.

1. From operational mode, generate a PKI public/private key pair for a local digital certificate.
2. From operational mode, define a self-signed certificate. Specify certificate details such as the certificate identifier (generated in the previous step), a fully qualified domain name (FQDN) for the certificate, and an e-mail address of the entity owning the certificate. You can also specify other information such as the common name and the organization involved. By configuring the add-ca-constraint option, you make sure that the certificate can be used for signing other certificates.
3. From configuration mode, apply the loaded certificate as root-ca in the SSL proxy profile.
4. Import the root CA as a trusted CA into client browsers. This is required for the client browsers to trust the certificates signed by the SRX Series device. See Importing a Root CA Certificate into a Browser.

1. Create folders keys and certs.
2. Change to the openssl directory.
3. Create a CA certificate key. The following command creates an RSA key using the 3DES encryption named ca.key that is 2048 in length. You also need to enter a password that is used to encrypt the private key. This is critical to security if the key is lost because it will still be encrypted.
4. Create a CA certificate based on the CA private key (created in the previous step). The expiration date for this certificate is 3 years or 1095 days. However, you can set it to a different value. When creating the certificate, you need to enter the password and the certificate information that includes distinguished name (DN), country name, and so forth.
5. Import the CA private and public keys into the SRX Series device. Copy the ca.key and ca.cer keys to the /var/tmp directory on the SRX Series device. You can copy using SCP, or open the files and copy them into “vi” on the SRX Series device to create new files.
6. From configuration mode, apply the loaded certificate as root-ca in the SSL proxy profile.
7. Import the root CA as a trusted CA into client browsers. This is required for the client browsers to trust the certificates signed by the SRX Series device. See Importing a Root CA Certificate into a Browser.

Configuring a CA Profile Group

The CA profile defines the certificate information to be used for authentication. It includes the public key that SSL proxy uses when generating a new certificate. Junos OS allows you to create a group of CA profiles and load multiple certificates in one action, view information about all certificates in a group, and delete unwanted CA groups.

1. Obtain a list of trusted CA certificates by following one of these methods:

   • Junos OS provides a default list of trusted CA certificates that you can load on your system using the default command option. The Junos OS package contains the default CA certificates as a PEM file (for example, trusted_CA.pem). After you download the Junos OS package, the default certificates are available on your system.

     From operational mode, load the default trusted CA certificates (the group name identifies the CA profile group):

   • Alternatively, you can define your own list of trusted CA certificates and import them on your system. You get the list of trusted CAs in a single PEM file (for example IE-all.pem) and save the PEM file in a specific location (for example, /var/tmp). See Knowledge Base Article KB23144.

     From operational mode, load the trusted list to the device (the group name identifies the CA profile group):
2. From configuration mode, attach the trusted CA or trusted CA group to the SSL proxy profile. You can attach all trusted CA or one trusted CA at a time:

   • To attach one CA profile group (the group name identifies the CA profile group):

   • To attach all CA profile groups:

You can easily display information about all certificates in a CA profile group:

You can delete a CA profile group. Remember that deleting a CA profile group deletes all certificates that belong to that group:

Configuring a Trusted CA Profile

1. From configuration mode, configure the CA profile used for loading the certificate.
2. From operational mode, load the certificate using PKI commands.
3. From configuration mode, disable the revocation check (if required).
4. From configuration mode, configure the loaded certificate as a trusted CA in the SSL proxy profile.
   Note

   More than one trusted CA can be configured for a profile.

5. (Optional) If you have multiple trusted CA certificates, you do not have to specify each trusted CA separately. You can load all the trusted CA certificates using the following command from configuration mode.
   Note

   Alternatively, you can import a set of trusted CAs from your browser into the SRX Series device. See Knowledge Base article KB23144.

Importing a Root CA Certificate into a Browser

In order to have your browser or system automatically trust all certificates signed by the root CA configured in the SSL proxy profile, you must instruct your platform or browser to trust the CA root certificate.

1. Generate a PEM format file for the configured root CA.
2. Import a root CA certificate into a browser.

   From Internet Explorer (version 8.0):

   1. From the Tools menu, select Internet Options.
   2. On the Content tab, click Certificates.
   3. Select the Trusted Root Certification Authorities tab and click Import.
   4. In the Certificate Import Wizard, navigate to the required root CA certificate and select it.

   From Firefox (version 39.0):

   1. From the Tools menu, select Options.
   2. From the Advanced menu, select the Certificates tab and click View Certificate.
   3. In the Certificate Manager window, select the Authorities tab and click Import.
   4. Navigate to the required root CA certificate and select it.

   From Google Chrome (45.0):

   1. From the Settings menu, select Show Advanced Settings.
   2. From the Advanced menu, select the Certificates tab and click View Certificate.
   3. Under HTTPS/SSL, click Manage Certificates.
   4. In the Certificate window, select Trusted Root Certification Authorities and click Import.
   5. In the Certificate Import Wizard, navigate to the required root CA certificate and select it.

Applying an SSL Proxy Profile to a Security Policy

SSL proxy is enabled as an application service within a security policy. In a security policy, you specify the traffic that you want the SSL proxy enabled on as match criteria and then specify the SSL proxy CA profile to be applied to the traffic. Figure 3 displays a graphical view of SSL proxy profile and security policy configuration.

Figure 3: Applying an SSL Proxy Profile to a Security Policy

1. Create a security policy and specify the match criteria for the policy. As match criteria, specify the traffic for which you want to enable SSL proxy.
2. Apply the SSL proxy profile to the security policy.

Creating a Whitelist of Exempted Destinations

Because SSL encryption and decryption might consume memory resources on the SRX Series device, network administrators can selectively bypass SSL proxy processing for some sessions. Such sessions mostly include connections and transactions with trusted servers or domains with which network administrators are very familiar. There are also legal requirements to exempt financial and banking sites. Such exemptions are achieved by configuring the IP addresses or domain names of the servers under whitelists.

1. Configure the domain in the address book.
2. Specify the global address book address in the SSL proxy profile.

Whitelist addresses and address sets are created under the global address book. The following type of addresses (from the global address book) are supported:

• IPv4 addresses (plain text). For example:

• IPv4 address range. For example:

• IPv4 wildcard. For example:

  Noncontiguous netmasks are not supported. For example:

  • 203.0.113.9/255.255.0.0 is supported.

  • 203.0.113.9/255.255.0.255 is NOT supported.

• IPv6 address (plain text). For example:

• DNS name. For example:

• Translated IP addresses. Sessions are whitelisted based on the actual IP address and not on the translated IP address. Because of this, in the whitelist configuration of the SSL proxy profile, the actual IP address should be provided and not the translated IP address.

  For example, consider a destination NAT rule that translates destination IP address 192.0.2.10/24 to 198.51.100.8/24 using the following commands:

In this scenario, to exempt a session from SSL proxy inspection, the following IP address should be added to the whitelist:

Starting with Junos OS Release 15.1X49-D80 and Junos OS Release 17.3R1, the whitelisting feature is extended to include URL categories supported by UTM in SSL forward proxy configuration. In this implementation, the Server Name Indication (SNI) field is extracted by the UTM module from client hello messages to determine the URL category. Each URL category has a unique ID. The list of URL categories under whitelist is parsed and the corresponding category IDs are pushed to the Packet Forwarding Engine for each SSL forward proxy profile. The SSL forward proxy then determines through APIs whether to accept, and proxy, or to ignore the session.

Starting with Junos OS Release 17.4R1, the whitelisting feature is extended to support custom URL categories supported by UTM.

The below example shows how to configure custom URL categories. In this example, Enhanced_Financial_Data_and_Services is one of the supported URL categories:

Configuring SSL Proxy Logging

When configuring SSL proxy, you can choose to set the option to receive some or all of the logs. SSL proxy logs contain the logical system name, SSL proxy whitelists, policy information, SSL proxy information, and other information that helps you troubleshoot when there is an error.

You can configure logging of all or specific events, such as error, warning, and information events. You can also configure logging of sessions that are whitelisted, dropped, ignored, or allowed after an error occurs.

You can use enable-flow-tracing option to enable debug tracing.

Exporting Certificates to a Specified Location

When a self-signed certificate is generated using a PKI command, the newly generated certificate is stored in a predefined location (var/db/certs/common/local).

Use the following command to export the certificate to a specific location (within the device). You can specify the certificate ID, the filename, and the type of file format (DER/PEM):

Ignoring Server Authentication

Junos OS allows you to configure an option to ignore server authentication completely. If you configure your system to ignore authentication, then any errors encountered during server certificate verification at the time of the SSL handshake are ignored. Commonly ignored errors include the inability to verify CA signature, incorrect certificate expiration dates, and so forth. If this option is not set, all the sessions where the server sends self-signed certificates are dropped when errors are encountered.

We do not recommend using 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 of dropped SSL sessions.

From configuration mode, specify to ignore server authentication:

Enabling Debugging and Tracing for SSL Proxy

Debug tracing on both Routing Engine and the Packet Forwarding Engine can be enabled for SSL proxy by setting the following configuration:

SSL proxy is supported on SRX340, SRX345, SRX550M, SRX1500, SRX4100, SRX4200, SRX5400, SRX5600, SRX5800 devices and vSRX instances. Table 5 shows the supported levels for trace options.

Table 6 shows the flags that are supported.

You can enable logs in the SSL proxy profile to get to the root cause for the drop. The following errors are some of the most common:

• Server certification validation error. Check the trusted CA configuration to verify your configuration.

• System failures such as memory allocation failures.

• Ciphers do not match.

• SSL versions do not match.

• SSL options are not supported.

• Root CA has expired. You need to load a new root CA.

You can enable the ignore-server-auth-failure option in the SSL proxy profile to ensure that certificate validation, root CA expiration dates, and other such issues are ignored. If sessions are inspected after the ignore-server-auth-failure option is enabled, the problem is localized.

Transport Layer Security (TLS) Overview

Transport Layer Security (TLS) is an application-level protocol that provides encryption technology for the Internet. TLS relies on certificates and private-public key exchange pairs for this level of security. It is the most widely used security protocol for the applications that require data to be securely exchanged over a network, such as file transfers, VPN connections, instant messaging, and voice over IP (VoIP).

TLS protocol is used for certificate exchange, mutual authentication, and negotiating ciphers to secure the stream from potential tampering and eavesdropping. TLS is sometimes called as Secure Sockets Layer (SSL). TLS and SSL are not interoperable, though TLS currently provides some backward compatibility.

SRX Series devices provides TLS inspection that use the TLS protocol suite consisting of different TLS versions, ciphers, and key exchange methods. TLS inspection feature enables SRX Series devices to inspect HTTP traffic encrypted in TLS on any port.

• Benefits of TLS

• TLS Versions

• Three Essential Services of TLS

• TLS Handshake

• Encrypting Syslog Traffic with TLS

Benefits of TLS

• TLS ensures the secure transmission of data between a client and a server through a combination of privacy, authentication, confidentiality, and data integrity.

TLS Versions

Following are the versions of TLS:

• TLS version 1.0—Provides secure communication over networks by providing privacy and data integrity between communicating applications

• TLS version 1.1—This enhanced version of TLS provides protection against cipher-block chaining (CBC) attacks.

• TLS version 1.2 — This enhanced version of TLS provides improved flexibility for negotiation of cryptographic algorithms.

  Starting with Junos OS Release 12.3X48-D30, SRX Series devices support TLS version 1.2. SRX Series devices running earlier release of 12.3X48-D30, supports TLS version 1.0.

Three Essential Services of TLS

The TLS protocol is designed to provide three essential services to the applications running above it: encryption, authentication, and data integrity.

• Encryption—In order to establish a cryptographically secure data channel, the server and the client must agree on which cipher suites are used and the keys used to encrypt the data. The TLS protocol specifies a well-defined handshake sequence to perform this exchange. TLS uses public key cryptography, which allows the client and server to negotiate a shared secret key without having to establish any prior knowledge of each other, and to do so over an unencrypted channel.

• Authentication—As part of the TLS handshake, the protocol allows both server and the client to authenticate their identity. Implicit trust between the client and the server (because the client accepts the certificate generated by the server) is an important aspect of TLS. 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.

• Integrity—With encryption and authentication in place, the TLS protocol does message framing mechanism and signs each message with a Message Authentication Code (MAC). The MAC algorithm does the effective checksum, and the keys are negotiated between the client and the server.

TLS Handshake

Each TLS session begins with a handshake during which the client and server agree on the specific security key and the encryption algorithms to use for that session. At this time, the client also authenticates the server. Optionally, the server can authenticate the client. Once the handshake is complete, transfer of encrypted data can begin.

Encrypting Syslog Traffic with TLS

TLS protocol ensures the syslog messages are securely sent and received over the network. TLS uses certificates to authenticate and encrypt the communication. The client authenticates the server by requesting its certificate and public key. Optionally, the server can also request a certificate from the client, thus mutual authentication is also possible.

A certificate on the server that identifies the server and the certificate of certificate authority (CA) issued by the server must be available with the client for TLS to encrypt syslog traffic.

For mutual authentication of client and the server, a certificate with the client that identifies the client and the certificate of CA issued by client must be available on the server. Mutual authentication ensures that the syslog server accepts log messages only from authorized clients.

Configuring the TLS Syslog Protocol

• Requirements

• Overview

• Configuration

• Verification

Requirements

Before you begin, enable server certificate verification and encryption or decryption capabilities.

Overview

TLS syslog protocol enables log sources to receive encrypted syslog events from network devices that supports TLS syslog event forwarding. The log source creates a listen port for incoming TLS syslog events and generates a certificate file for the network devices.

In this example, you will configure a syslog collector associated with one SSL-I profile. Each SSL-I profile will enable the user to specify things like preferred ciphers suite and trusted CA certificates. Multiple SSL-I profiles can be configured and associated to different collector servers.

Configuration

CLI Quick Configuration

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

1. Set the log mode to stream.
2. Set the format for remote security message logging to sd-syslog (structured system log).
3. Set the host source interface number.
4. Set security log transport protocol tls to be used to log the data.
5. Specify the TLS profile name.
6. Set the log stream to use the structured syslog format for sending logs to server 1.
7. Set the category of server 1 logging to all .
8. Set server host parameters by entering the server name or IP address.
9. Define the protocol version all for SSL initiation access profile.
10. Attach all CA profile groups to the SSL initiation profile to use when requesting a certificate from the peer.
11. Define the SSL initiation access profile to ignore the server authentication failure.

Results

From configuration mode, confirm your configuration by entering the show security log command. If the output does not display the intended configuration, then repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification