Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Configuring SSL Proxy

 

SRX Series device support SSL forward proxy and SSL reverse proxy.

Configuring SSL Forward Proxy

SSL Proxy Configuration Overview

Figure 1 displays an overview of how SSL proxy is configured. Configuring SSL proxy includes:

  • Configuring the root CA certificate

  • Loading a CA profile group

  • Configure SSL proxy profile and associate root CA certificate and CA profile group

  • Create a security policy by defining input traffic match criteria

  • Applying an SSL proxy profile to a security policy

  • Optional steps such as creating whitelists and SSL proxy logging

Figure 1: SSL Proxy Configuration Overview
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.

Generate a Root CA Certificate with CLI

To define a self-signed certificate in CLI, you must provide the following details:

  • Certificate identifier (generated in the previous step)

  • Fully qualified domain name (FQDN) for the certificate

  • e-mail address of the entity owning the certificate

  • Common name and the organization involved

Generate a root CA certificate using the Junos OS CLI:

  1. From operational mode, generate a PKI public/private key pair for a local digital certificate.

    Example:

  2. Define a self-signed certificate.

    Example:

    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.

    Example:

  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.

Generate a Root CA Certificate with OpenSSL

To generate a root CA certificate using OpenSSL:

  1. Create folders keys and certs.
  2. Change to the openssl directory.
  3. Create a CA certificate key.

    This step 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 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.

You can load a group of CA profiles by obtaining a list of trusted CA certificates, defining a CA group, and attaching the CA group to the SSL proxy profile.

  1. Obtain a list of trusted CA certificates by using one of the following methods. When a connection is initiated, the connecting device (such as a Web browser) checks whether the certificate is issued by a trusted CA. Without these certificates, browsers cannot validate the identity of most websites and mark them as untrusted sites.
    • Junos OS provides a default list of trusted CA certificates that you can load on your system. 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):

      Example:

      We recommend using this method.

    • 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):

      Example:

    • 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, ensure that you use the latest CA bundle.

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

  2. 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:
    • Attach all CA profile groups:

      Example

    • Attach one CA profile group (the group name identifies the CA profile group).

      Example

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:

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.

To import a root CA 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 2 displays a graphical view of SSL proxy profile and security policy configuration.

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

To enable SSL proxy in a security policy:

This example assumes that you have already creates security zones trust and untrust and creating a security policy for the traffic from trust zone to untrust zone.

  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.

    Example:

  2. Apply the SSL proxy profile to the security policy.

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.

Configuring Certificate Authority Profiles

A certificate authority (CA) profile configuration contains information specific to a CA. You can have multiple CA profiles on an SRX Series device. For example, you might have one profile for orgA and one for orgB. Each profile is associated with a CA certificate. If you want to load a new CA certificate without removing the older one then create a new CA profile (for example, Microsoft-2008). You can group multiple CA profiles in one trusted CA group for a given topology.

In this example, you create a CA profile called ca-profile-security with CA identity microsoft-2008. You then create proxy profile to the CA profile.

  1. From configuration mode, configure the CA profile used for loading the certificate.

    Example:

  2. Commit the configuration.
  3. From operational mode, load the certificate using PKI commands.

    Example:

  4. From configuration mode, disable the revocation check (if required).

    Example:

  5. From configuration mode, configure the loaded certificate as a trusted CA in the SSL proxy profile.

    Example:

    Note

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

  6. (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.

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:

SSL Reverse Proxy

Overview

The proxy model implementation for server protection (often called reverse proxy) is supported on SRX Series devices to provide improved handshaking and support for more protocol versions. You can enable Layer 7 services (application security, IPS, UTM, SKY ATP) on the traffic decrypted by SSL reverse proxy.

Starting in Junos OS Release 15.1X49-D80 and 17.3R1, SSL reverse proxy is supported on SRX5000 Series, SRX4100, SRX4200, SRX1500 devices.

Note

Starting in Junos OS Release 15.1X49-D80 and 17.3R1, we recommend using the SSL reverse proxy and Intrusion Detection and Prevention (IDP) instead of using the IDP SSL inspection functionality.

Starting from Junos OS 15.1X49-D80 and 17.3R1, IDP SSL Inspection is deprecated—rather than immediately removed—to provide backward compatibility and a chance to bring your configuration into compliance with the new configuration.

Table 1 provides the changes applicable on SRX Series devices post 15.1X48-D80 and 17.3R1 releases.

Table 1: Comparing Reverse Proxy Before and After Junos OS Release 15.1X49-D80

Feature

Prior to 15.1X49-D80

15.1X49-D80 and 17.3R1 later

Proxy model

Runs only in tap mode Instead of participating in SSL handshake, it listens to the SSL handshake, computes session keys and then decrypts the SSL traffic.

Terminates client SSL on the SRX Series device and initiates a new SSL connection with a server. Decrypts SSL traffic from the client/server and encrypts again (after inspection) before sending to the server/client.

Protocol version

Does not support TLS Version 1.1 and 1.2.

Supports all current protocol versions.

Key exchange methods

  • Supports RSA

  • Does not support DHE.

  • Supports RSA

  • Support DHE or ECDHE

Echo system

Tightly coupled with IDP engine and its detector.

Uses existing SSL forward proxy with TCP proxy underneath.

Security services

Decrypted SSL traffic can be inspected only by IDP.

Just like forward proxy, decrypted SSL traffic is available for all security services.

Ciphers supported

Limited set of ciphers are supported.

All commonly used ciphers are supported.

You must configure either root-ca or server-certificate in an SSL proxy profile. Otherwise the commit check fails. See Table 2.

Table 2: Supported SSL Proxy Configurations

server-certificate configured

root-ca configured

Profile type

No

No

Commit check fails. You must configure either server-certificate or root-ca.

Yes

Yes

Commit check fails. Configuring both server-certificate and root-ca in the same profile is not supported.

No

Yes

Forward proxy

Yes

No

Reverse proxy

Configuring multiple instances of forward and reverse proxy profiles are supported. But for a given firewall policy, only one profile (either a forward or reverse proxy profile) can be configured. Configuring both forward and reverse proxy on the same device is also supported.

You cannot configure the previous reverse proxy implementation with the new reverse proxy implementation for a given firewall policy. If both are configured, you will receive a commit check failure message.

The following are the minimum steps to configure reverse proxy:

  1. Load the server certificates and their keys into the SRX Series device certificate repository using the CLI command request security pki local-certificate load filename filename key key certificate-id certificate-id passphrase exmample@1234. For example:
  2. Attach the server certificate identifier to the SSL Proxy profile using the CLI command set services ssl proxy profile profile server-certificate certificate-id passphrase exmample@1234. For example

    user@host# set services ssl proxy profile server-protection-profile server-certificate server2_cert_id

  3. Use the show services ssl CLI command to verify your configuration. For example:

The SSL forward proxy and reverse proxy require a profile to be configured at the firewall rule level. In addition, you must also configure server certificates with private keys for reverse proxy. During an SSL handshake, the SSL proxy performs a lookup for a matching server private key in its server private key hash table database. If the lookup is successful, the handshake continues. Otherwise, SSL proxy aborts the hand shake. Reverse proxy does not prohibit server certificates. It forwards the actual server certificate/chain as is to the client without modifying it. Intercepting the server certificate occurs only with forward proxy.

The following shows example forward and reverse proxy profile configurations.

Configuring the SSL Reverse Proxy

This example shows how to configure reverse proxy to enable server protection. For server protection, additionally, server certificate(s) with private key(s) must be configured.

A reverse proxy protects servers by hiding the details of the servers from the clients, there by adding an extra layer of security.

To configure an SSL reverse proxy, you must:

  • Load the server certificate(s) and their key(s) into SRX Series device’s certificate repository.

  • Attach the server certificate identifier(s) to the SSL proxy profile.

  • Apply SSL proxy profile as application services in a security policy.

To configure SSL reverse proxy:

  1. Load the signing certificate and the respective key for the SSL proxy profile in PKI memory.
  2. Attach the server certificate to the SSL proxy profile.
  3. 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.
  4. Apply the SSL proxy profile to the security policy. This example assumes that security zones are created as per requirements.

Verifying the SSL Reverse Proxy Configuration on the Device

Purpose

Viewing the SSL reverse proxy statistics on the SRX Series device.

Action

You can view the SSL proxy statistics by using the show services ssl proxy statistics command.

Creating a Whitelist of Exempted Destinations for SSL Proxy

SSL encryption and decryption might consume memory resources on the SRX Series devices. To limit this, you can selectively bypass SSL proxy processing for some sessions such as sessions that transacts with familiar trusted servers or domains. You can also exempt the sessions with financial and banking sites due to legal requirements.

To exempt the sessions from SSL proxy, you can create a whitelists by adding IP addresses or domain names of the servers. Whitelists include addresses that you want to exempt from undergoing SSL proxy processing.

Use the following steps to create whitelists:

  • Specify IP addresses and domain name in your global address book.

  • Refer the global address book in SSL proxy profile.

You can configure the following types of the IP addresses in global address book.

  • IPv4 addresses (plain text). For example:

  • IPv4 address range. For example:

  • IPv4 wildcard. For example:

  • DNS name. For example:

  • IPv6 address. For example:

Whitelists do not support the following types of IP addresses:

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

  • Noncontiguous netmasks. For example:

    • IP address -203.0.113.0 and mask 255.255.255.0 that is 203.0.113.0/24 is supported.

    • IP address - 203.0.113.9 and mask 255.0.255.0 is not supported.

Following example shows you how to use whitelists in SSL proxy profile.

In this example, you exempt all sessions to www.mycompany.com. For this, you first specify the domain in the address book and then configure the address in the SSL proxy profile.

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

Creating a Whitelist of Exempted URL Categories for SSL Proxy

You can configure the URL categories supported in UTM module to exempt from SSL inspection on SRX Series device. To use URL categories from UTM, SRX Series device integrates the SSL proxy profile with the EWF feature. With this now, you can configure a list of URL categories under an SSL proxy profile as whitelist along with address-books. You can configure the list from the predefined set of URL categories or custom URL categories supported by UTM.

The security device uses the Server Name Indication (SNI) field extracted by the UTM module to determine the URL category. The SSL proxy uses this information to determines whether to accept, and proxy, or to ignore the session.

This feature is supported on SRX340, SRX345, SRX5400, SRX5600, SRX5800 and vSRX instances.

Starting with Junos OS Release 15.1X49-D80 and Junos OS Release 17.3R1, SSL proxy whitelisting feature includes URL categories supported by UTM.

Starting with Junos OS Release 17.4R1, SSL proxy whitelisting feature extends support to custom URL categories supported by UTM.

Following examples show how to configure the URL categories in SSL proxy profile:

Creating a Whitelist of Exempted URL Categories

Use the following steps to configure the predefined URL categories in an SSL proxy profile.

  1. The predefined URL categories depends on UTM. To enable URL-based whitelisting in SSL proxy, the following basic URL configurations are required:
  2. Specify the predefined URL category in SSL proxy profile. In this example, you are using the URL category Enhanced_Financial_Data_and_Services.
  3. Create the security policy by specifying the match conditions and attach the UTM policy to the security policy to use URL categories in SSL whitelist.

Creating a Whitelist of Exempted Custom URL Categories

Use the following steps to configure custom URL categories in an SSL proxy profile.

  1. Create a custom URL category.

  2. Configure a UTM policy for the Web-filtering HTTP protocol and associate the profile you created in previous step to the the UTM policy.
  3. Specify the custom URL category you created in previous step in SSL proxy profile.
  4. Create a security policy by specifying the match conditions and attach the UTM policy to the security policy to use URL categories in SSL whitelist.
Release History Table
Release
Description
Starting with Junos OS Release 17.4R1, SSL proxy whitelisting feature extends support to custom URL categories supported by UTM.
Starting in Junos OS Release 15.1X49-D80 and 17.3R1, SSL reverse proxy is supported on SRX5000 Series, SRX4100, SRX4200, SRX1500 devices
Starting in Junos OS Release 15.1X49-D80 and 17.3R1, we recommend using the SSL reverse proxy and Intrusion Detection and Prevention (IDP) instead of using the IDP SSL inspection functionality.
Starting from Junos OS 15.1X49-D80 and 17.3R1, IDP SSL Inspection is deprecated—rather than immediately removed—to provide backward compatibility and a chance to bring your configuration into compliance with the new configuration.
Starting with Junos OS Release 15.1X49-D80 and Junos OS Release 17.3R1, SSL proxy whitelisting feature includes URL categories supported by UTM.