SSL Proxy

 

SSL proxy acts as an intermediary, performing SSL encryption and decryption between the client and the server. Better visibility into application usage can be made available when SSL forward proxy is enabled. For more information, see the following topics:

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

Table 1: Maximum Key Sizes Supported on SRX Series Devices

SRX Series Devices

Supported RSA Key Size

SRX340, SRX345, SRX550, SRX1500, SRX4100, SRX4200, SRX4600, SRX5400, SRX5600, SRX5800

512 bits, 1024 bits, 2048 bits, 4096 bits

SRX300, SRX320

512 bits, 1024 bits, 2048 bits

Note
  • Starting with Junos OS Release 15.1X49-D30 and Junos OS Release 17.3R1, server certificates of key size 4096 bits are supported. Prior to Junos OS Release 15.1X49-D30, server certificates with key size greater than 2048 bits were not supported because of cryptography hardware limitations.

  • Starting in Junos OS Release 18.1R1, SSL proxy support is available on SRX300 and SRX320 devices. On SRX300 and SRX320 devices, server certificates with key size 4096 bits are not supported.

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.

Table 2: Supported SSL Cipher List

SSL CipherKey Exchange AlgorithmData EncryptionMessage Integrity

Preferred Ciphers Category

Earliest Supported Release

ECDHE-ECDSA-AES-256-GCM- SHA384

ECDHE/DSA key exchange

256-bit AES/GCM

SHA384 hash

Strong

Junos OS Release 18.3R1

ECDHE-ECDSA-AES-128-GCM-SHA256

ECDHE/DSA key exchange

128-bit AES/GCM

SHA256 hash

Strong

Junos OS Release 18.3R1

ECDHE-ECDSA-AES-256-CBC- SHA384

ECDHE/DSA key exchange

256-bit AES/CBC

SHA384 hash

Strong

Junos OS Release 18.3R1

ECDHE-ECDSA-AES-128-CBC-SHA256

ECDHE/DSA key exchange

128-bit AES/CBC

SHA256 hash

Strong

Junos OS Release 18.3R1

ECDHE-ECDSA-AES-256-CBC-SHA

ECDHE/DSA key exchange

256-bit AES/CBC

SHA hash

Strong

Junos OS Release 18.3R1

ECDHE-ECDSA-AES-128-CBC-SHA

ECDHE/DSA key exchange

128-bit AES/CBC

SHA hash

Strong

Junos OS Release 18.3R1

ECDHE-ECDSA-3DES-EDE-CBC-SHA

ECDHE/DSA key exchange

3DES EDE/CBC

SHA hash

Strong

Junos OS Release 18.3R1

ECDHE-RSA-AES256-GCM-SHA384

ECDHE/RSA key exchange

256-bit AES/GCM

SHA384 hash

Strong

Junos OS Release 15.1X49-D10

ECDHE-RSA-AES256-CBC-SHA384

ECDHE/RSA key exchange

256-bit AES/CBC

SHA384 hash

Strong

Junos OS Release 15.1X49-D10

ECDHE-RSA-AES256-CBC-SHA

ECDHE/RSA key exchange

256-bit AES/CBC

SHA hash

Strong

Junos OS Release 15.1X49-D10

ECDHE-RSA-DES-CBC3-SHA

ECDHE/RSA key exchange

DES CBC

SHA hash

Medium

Junos OS Release 15.1X49-D10

ECDHE-RSA-AES128-GCM-SHA256

ECDHE/RSA key exchange

128-bit AES/GCM

SHA256 hash

Strong

Junos OS Release 15.1X49-D10

ECDHE-RSA-AES128-CBC-SHA256

ECDHE/RSA key exchange

128-bit AES/CBC

SHA256 hash

Strong

Junos OS Release 15.1X49-D10

ECDHE-RSA-AES128-CBC-SHA

ECDHE/RSA key exchange

128-bit AES/CBC

SHA hash

Strong

Junos OS Release 15.1X49-D10

RSA-AES256-GCM-SHA384

ECDHE/RSA key exchange

256-bit AES/GCM

SHA384 hash

Strong

Junos OS Release 15.1X49-D10

RSA-AES256-CBC-SHA256

ECDHE/RSA key exchange

256-bit AES/CBC

SHA256 hash

Strong

Junos OS Release 15.1X49-D10

RSA-AES128-GCM-SHA256

ECDHE/RSA key exchange

128-bit AES/GCM

SHA256 hash

Strong

Junos OS Release 15.1X49-D10

RSA-AES128-CBC-SHA256

ECDHE/RSA key exchange

128-bit AES/CBC

SHA256 hash

Medium

Junos OS Release 15.1X49-D10

RSA-RC4-128-MD5

RSA key exchange

128-bit RC4

Message Digest 5 (MD5) hash

Medium

Junos OS Release 12.1

RSA-RC4-128-SHA

RSA key exchange

128-bit RC4

Secure Hash Algorithm (SHA) hash

Medium

Junos OS Release 12.1

RSA-DES-CBC-SHA

RSA key exchange

DES CBC

SHA hash

Week

Junos OS Release 12.1

RSA-3DES-EDE-CBC-SHA

RSA key exchange

3DES EDE/CBC

SHA hash

Week

Junos OS Release 12.1

RSA-AES128-CBC-SHA

RSA key exchange

128-bit AES/CBC

SHA hash

Week

Junos OS Release 12.1

RSA-AES256-CBC-SHA

RSA key exchange

256-bit AES/CBC

SHA hash

Week

Junos OS Release 12.1

RSA-EXPORT-RC4-40-MD5

RSA-export

40-bit RC4

MD5 hash

Week

Junos OS Release 12.1

RSA-EXPORT-DES40-CBC-SHA

RSA-export

40-bit DES/CBC

SHA hash

Week

Junos OS Release 12.1

RSA-EXPORT-1024-DES-CBC-SHA

RSA 1024 bit export

DES/CBC

SHA hash

Week

Junos OS Release 12.1

RSA-EXPORT-1024-RC4-56-MD5

RSA 1024 bit export

56-bit RC4

MD5 hash

Week

Junos OS Release 12.1

RSA-EXPORT-1024-RC4-56-SHA

RSA 1024 bit export

56-bit RC4

SHA hash

Week

Junos OS Release 12.1

Note

Cipher suites that have “export” in the title are intended for use outside of the United States and might have encryption algorithms with limited key sizes.

Export ciphers are not enabled by default. You need to either configure the export ciphers to enable or install a domestic package.

Note

Supported SSL ciphers for HTTPS firewall authentication are RSA-3DES-EDE-CBC-SHA , RSA-AES-128-CBC-SHA, and RSA-AES-256-CBC-SHA.

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.

Note
  • All ECDSA-based cipher suites provide Perfect Forward Secrecy (PFS) support.

  • SSL forward proxy supports the Elliptic Curve Cryptography (ECC) certificate only with the Elliptic Prime Curve 256 bit (P-256).

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

You can configure the following ciphers for an SSL proxy profile:

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

Note

To configure and use ECDSA ciphers, you must include the certificates containing ECC-capable public keys on the device.

Configure 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

The following SSL protocols are supported on SRX Series devices for SSL initiation and termination service:

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

Junos OS provides the following options for trusted CA certificates:

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

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.

Table 3: SSL Proxy Logs

Syslog TypeDescription

SSL_PROXY_SSL_SESSION_DROP

Logs generated when a session is dropped by SSL proxy.

SSL_PROXY_SSL_SESSION_ALLOW

Logs generated when a session is processed by SSL proxy even after encountering some minor errors.

SSL_PROXY_SESSION_IGNORE

Logs generated if non-SSL sessions are initially mistaken as SSL sessions.

SSL_PROXY_SESSION_WHITELIST

Logs generated when a session is whitelisted.

SSL_PROXY_ERROR

Logs used for reporting errors.

SSL_PROXY_WARNING

Logs used for reporting warnings.

SSL_PROXY_INFO

Logs used for reporting general information.

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.

Table 4: SSL Proxy Log Prefixes

PrefixDescription

system

Logs generated due to errors related to the device or an action taken as part of the SSL proxy profile. Most logs fall into this category.

openssl error

Logs generated during the handshaking process if an error is detected by the openssl library.

certificate error

Logs generated during the handshaking process if an error is detected in the certificate (x509 related errors).

Sample logs:

Note

These logs capture sessions that are dropped by SSL proxy, not sessions that are marked by other modules that also use SSL proxy services.

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

Note

On SRX Series devices, for a particular session, the SSL proxy is only enabled if a relevant feature related to SSL traffic is also enabled. Features that are related to SSL traffic are IDP, application identification, application firewall, application tracking, advanced policy-based routing, UTM, SkyATP, and ICAP redirect service. If none of these features are active on a session, the SSL proxy bypasses the session and logs are not generated in this scenario.

Note

On all SRX Series devices, the current SSL proxy implementation has the following connectivity limitations:

  • The SSLv3.0 protocol support is deprecated.

  • The SSLv2 protocol is not supported. SSL sessions using SSLv2 are dropped.

  • Only X.509v3 certificate is supported.

  • Client authentication of SSL handshake is not supported.

  • SSL sessions where client certificate authentication is mandatory are dropped.

  • SSL sessions where renegotiation is requested are dropped.

Configuring SSL Forward Proxy

SSL proxy works transparently between the client and the server. All requests from a client first go to the proxy server; the proxy server evaluates the request, and if the request is valid, forwards the request to the outbound side. Similarly, inbound requests are also evaluated by the proxy server. Both client and server interpret that they are communicating with each other; however, it is the SSL proxy that functions between the two. For release-specific support, see Feature Explorer

SSL proxies provide encryption and decryption by residing between the server and the client. Because SSL proxies are hidden from both the server and the client, secret keys are shared between the two to decrypt the SSL traffic. Proxies are known as forward proxies because proxy servers are used to hide any detailed information from the servers.

Integrity, confidentiality, and authenticity of traffic are validated through PKI, which includes digital certificates issued by the CA, certificate validity and expiration dates, details about the certificate owner and issuer, and security policies.

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

To generate a root CA certificate using the Junos OS CLI, follow these steps on an SRX Series 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.

To generate a root CA certificate using OpenSSL, follow these steps on a UNIX device:

  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.

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

Typically, you import a list of trusted CA certificates by creating a group of CA profiles. However, you can also configure a single CA profile (containing one or multiple certificates) and import it using PKI commands. This section shows you how to import a trusted CA certificate from your browser’s certificate store into your SRX Series device. The certificate that is configured under the trusted CA is loaded using the PKI commands and is used for validating the server certificate chain.

  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.

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 3 displays a graphical view of SSL proxy profile and security policy configuration.

Figure 3: 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:

  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.

Whitelists include addresses that you want to exempt from undergoing SSL proxy processing. For example, if you want to exempt all sessions to www.mycompany.com, then you would include it in the whitelist. To configure the whiltelist, you specify the domain that you want to exempt in an 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.

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

Example:

Note

The predefined url categories depends on UTM. To enable URL- based whitelisting in SSL proxy, the following basic URL configurations are required:

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:

SSL Reverse Proxy

SSL proxy is a transparent proxy that performs SSL encryption and decryption between the client and the server as follows:

  • Reverse proxy—Proxying inbound session, that is, externally initiated SSL sessions from the Internet to the local server

  • Forward proxy—Proxying outbound session, that is, locally initiated SSL session to the Internet.

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.

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

On SRX Series devices, client protection (forward proxy) and server protection (reverse proxy) are supported using same echo system SSL-T-SSL [terminator on the client side] and SSL-I-SSL [initiator on the server side]).

Note

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, 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, 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 5 provides the changes applicable on SRX Series devices post 15.1X48-D80 releases.

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

Feature

Prior to 15.1X49-D80

15.1X49-D80 and 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.

Like forward proxy, reverse proxy requires 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.

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

Table 6: 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
  3. Attach the trusted CA to the SSL proxy profile. In this example, you attach all trusted CA at a time:
  4. Use the show services ssl CLI command to verify your configuration. For example:

Configuring the SSL Reverse Proxy

This example shows how to configure reverse proxy to enable server protection. It shows how to configure an SSL proxy profile and apply it at the security policy rule level. For server protection, additionally, server certificate(s) with private key(s) must be configured.

Requirements

No special configuration beyond device initialization is required before configuring this feature.

Overview

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

Similar to SSL forward proxy (client protection), server protection also needs an SSL proxy profile to be configured at the security policy rule level. For server protection, additionally, server certificate(s) with private key(s) must be configured. Note that, for server protection enabled session, SSL proxy do not interdicts server certificate, that is—it forwards the actual server certificate/chain as it is to the client without modifying it. Interdicting the server certificate happens on client protection enabled sessions only.

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.

Configuration

Configuring SSL Reverse Proxy

Step-by-Step Procedure

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. Attach the trusted CA to the SSL proxy profile. In this example, you attach all trusted CA at a time:
  4. 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.
  5. Apply the SSL proxy profile to the security policy.

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.

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 7 shows the supported levels for trace options.

Table 7: Trace Levels

Cause Type

Description

Brief

Only error traces on both the Routing Engine and the Packet Forwarding Engine.

Detail

Packet Forwarding Engine–Only event details up to the handshake should be traced.

Routing Engine–Traces related to commit. No periodic traces on the Routing Engine will be available

Extensive

Packet Forwarding Engine–Data transfer summary available.

Routing Engine–Traces related to commit (more extensive). No periodic traces on the Routing Engine will be available.

Verbose

All traces are available.

Table 8 shows the flags that are supported.

Table 8: Supported Flags in Trace

Cause Type

Description

cli-configuration

Configuration-related traces only.

initiation

Enable tracing on the SSL-I plug-in.

proxy

Enable tracing on the SSL-Proxy-Policy plug-in.

termination

Enable tracing on the SSL-T plug-in.

selected-profile

Enable tracing only for profiles that have enable-flow-tracing set.

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.

SSL Proxy Support for Unified Policies

Starting from Junos OS Release 18.2R1, unified policies are supported on SRX Series devices, allowing granular control and enforcement of dynamic Layer 7 applications, within the traditional security policy.

Unified policies are the security policies that enable you to use dynamic applications as match conditions as part of the existing 5-tuple or 6-tuple (5-tuple with user firewall) match conditions to detect application changes over time.

SSL proxy functionality is supported when the device is configured with unified policies. As a part of this enhancement, you can configure a default SSL proxy profile.

During the initial policy lookup phase, which occurs prior to a dynamic application being identified, if there are multiple policies present in the potential policy list which contains different SSL proxy profiles, the SRX Series device applies the default SSL proxy profile until a more explicit match has occurred.

We recommend that you create a default SSL proxy profile. The sessions are dropped in case of policy conflicts, if there is no default SSL proxy profile available.

You can configure an SSL proxy profile under the [edit services ssl proxy] hierarchy level, and then apply it as a default SSL proxy profile under the [edit security ngfw] hierarchy level. This configuration does not impact the existing SSL service configuration.

Configuring a default SSL proxy profile is supported for both SSL forward and reverse proxy.

Understanding How SSL Proxy Default Profile Works

Table 9 summarizes the default SSL proxy profile behavior in unified policies.

Table 9: SSL Proxy Profile Usage in Unified Policies

Application Identification Status

SSL Proxy Profile Usage

Action

No security policy conflict

SSL proxy profile is applied when traffic matches the security policy.

SSL proxy profile is applied.

Security policy conflict (conflicting polices have distinct SSL proxy profiles)

Default SSL proxy profile is not configured or not found.

Session is terminated, because the default SSL proxy profile is not configured.

Default SSL proxy profile is configured.

Default SSL proxy profile is applied.

Final application is identified

Matching security policy has a SSL proxy profile that is same as default SSL proxy profile.

Default SSL proxy profile is applied.

Matching security policy does not have a SSL proxy profile.

Default SSL proxy profile is applied.

Matching security policy has a SSL proxy profile that is different from the default SSL proxy profile that is already applied.

Default SSL proxy profile that is already applied, continues remain as applied.

Note

A security policy can have either an SSL reverse proxy profile or an SSL forward proxy profile configured at a time.

If a security policy has an SSL forward proxy profile and another security policy has an SSL reverse proxy profile, in such case, a default profile—either from SSL reverse proxy profile or from SSL forward proxy profile is considered.

Caution

We recommend creating default SSL proxy profile because sessions are dropped in case of policy conflicts, when there is no default SSL proxy profile available. A system log message is generated to log the event.

Tip

Example of the system log message:

Default SSL Proxy Profiles in Different Scenarios

Following examples discuss in detail about the default SSL proxy profile in different scenarios:

No Policy Conflict—All Policies Have Same SSL Proxy Profile

All matching policies have same SSL proxy profile as shown in Table 10.

Table 10: No Policy Conflict—All Policies Have Same SSL Proxy Profile

Security Policy

Source Zone

Source IP Address

Destination Zone

Destination IP Address

Port Number

Protocol

Dynamic Application

Service

Default SSL Proxy Profile

Policy-P1

S1

Any

D1

Any

Any

Any

Facebook

SSL Proxy

SSL-1

Policy-P2

S1

Any

D1

Any

Any

Any

Google

SSL Proxy

SSL-1

In this case, both Policy-P1 and Policy-P2 have the same SSL proxy profile (SSL-1). Because there is no conflict, the profile SSL-1 is applied.

If you have configured a default SSL proxy profile (SSL-2), it is not applied. Because there is no conflict in the policies (Policy-P1 and Policy-P2).

No Policy Conflict—All Policies Have Same SSL Proxy Profile and Final Policy Has No SSL Profile

Policy-P1 and Policy-P2 have same SSL proxy profile and the Policy-3 has no SSL profile as shown in Table 11.

Table 11: No Policy Conflict—All Policies Have Same SSL Proxy Profile and Final Policy Has No SSL Profile Configured

Security Policy

Source Zone

Source IP Address

Destination Zone

Destination IP Address

Port Number

Protocol

Dynamic Application

Service

Default SSL Proxy Profile

Policy-P1

S1

Any

D1

Any

Any

Any

Facebook

SSL Proxy

SSL-1

Policy-P3

S1

50.1.1.1

D1

Any

Any

Any

YouTube

SSL Proxy

SSL-1

Policy-P2

S1

Any

D1

Any

Any

Any

Google

Other

None

In this scenario, both Policy-P1 and Policy-P2 have the same SSL proxy profile (SSL-1). Because there is no conflict, the profile SSL-1 is applied before the final policy match.

When the final application is identified, the security policy matching with the final application, that is, Policy-P3 is applied. Because the Policy-P3 has no SSL proxy profile, the already applied profile SSL-1 remains applied. This is because, the SSL proxy profile is already applied on the traffic.

Policy Conflict—No SSL Profile Configured for Final Policy

The default SSL proxy profile is applied during potential match as shown in Table 12. The final policy, Policy-P3 does not have any SSL proxy profile.

Table 12: Policy Conflict—No SSL Profile Configured for Final Policy

Security Policy

Source Zone

Source IP Address

Destination Zone

Destination IP Address

Port Number

Protocol

Dynamic Application

Service

Default SSL Proxy Profile

Policy-P1

S1

50.1.1.1

D1

Any

Any

Any

Facebook

SSL Proxy

SSL-1

Policy-P2

S1

50.1.1.1

D1

Any

Any

Any

Google

SSL Proxy

SSL-2

Policy-P3

S1

50.1.1.1

D1

Any

Any

Any

YouTube

Other

NA

In this example, SSL proxy profile SSL-1 is configured as default SSL proxy profile. During the policy conflict for Policy-P1 and Policy-P2, the default profile SSL-1 is applied.

When the final application is identified, the security policy matching with the final application, that is, Policy-P3 is applied. Because the Policy-P3 has no SSL proxy profile, the already applied profile SSL-1 continues to remain as applied. This is because, the SSL proxy profile is applied on the traffic.

Policy Conflict–Default SSL Proxy Profile and Different SSL Proxy Profile for Final Policy

The SSL proxy profile SSL-1 is configured as a default SSL proxy profile and is already applied before the final policy is matched. Refer Table 13.

Table 13: Policy Conflict—Default SSL Proxy Profile and Different SSL Proxy Profile for Final Policy

Security Policy

Source Zone

Source IP Address

Destination Zone

Destination IP Address

Port Number

Protocol

Dynamic Application

Service

Default SSL Proxy Profile

Policy-P1

S1

50.1.1.1

D1

Any

Any

Any

Facebook

SSL Proxy

SSL-1

Policy-P2

S1

50.1.1.1

D1

Any

Any

Any

Google

SSL Proxy

SSL-2

Policy-P3

S1

50.1.1.1

D1

Any

Any

Any

YouTube

SSL Proxy

SSL-3

When the final application is identified, the security policy matching with the final application, that is, Policy-P3 is applied. The SSL profile for the Policy-P3, that is, SSL-3 is not applied. Instead, the SSL proxy profile SSL-2 configured and applied as default profile, continues to remain as applied.

Switching from the default SSL proxy profile that is already applied to the traffic, to another SSL proxy profile is not supported.

Limitations of SSL Proxy with Unified Policies

  • When a default SSL proxy profile is enabled, it cannot be disabled even if the final security policy does not have SSL proxy configured.

  • When a default SSL proxy profile is enabled and applied on the traffic and the final security policy has a different SSL proxy profile configured other than default profile, switching from the default SSL proxy profile to the SSL proxy profile in the security policy is not supported.

Configuring Default SSL Proxy Profiles

SSL proxy is enabled as an application service within a security policy. In a security policy, specify the match criteria for the traffic that must be SSL proxy enabled. Next, specify the SSL proxy profile to be applied to the traffic. When configuring unified policies, the steps include defining the SSL profile, then adding the SSL profile as default profile under the [edit security ngfw] hierarchy level, and then including to it in the desired security policy.

Configuring Default Profile for SSL Forward Proxy

In this procedure, you configure an SSL forward proxy profile, and specify the profile as the default profile.

  1. Create an SSL profile and attach the CA profile group to the SSL proxy profile.
  2. Apply the signing certificate as root-ca in the SSL proxy profile.
  3. Define the SSL proxy profile as the default profile.

Configuring Default Profile for SSL Reverse Proxy

In this procedure, you configure an SSL reverse proxy profile and specify the profile as the default profile.

  1. Create an SSL profile and attach the CA profile group to the SSL proxy profile.
  2. Define the SSL reverse proxy profile as the default profile.

Configuring Default SSL Profiles for Logical System

In this procedure, you assign the SSL forward proxy profile or the SSL reverse proxy profile as the default profile in logical system configurations. In this case, one profile can be a default profile either from the SSL forward proxy or from the SSL reverse proxy.

  • Define the SSL forward proxy profile as the default profile.
  • Define the SSL reverse proxy profile as the default profile.

Example: Configuring Default SSL Proxy Profile for Unified Policy

This example shows how to configure a default SSL proxy profile and apply it in a unified policy.

Requirements

This example uses the following hardware and software components:

  • SRX Series device with Junos OS Release 18.2R1 or later. This configuration example is tested for Junos OS Release 18.2R1.

No special configuration beyond device initialization is required before configuring this feature.

Overview

In this example, you configure an SSL forward proxy profile by specifying the root CA certificate. Next, configure the profile as default SSL proxy profile. Now, you create a unified policy and invoke the SSL proxy as application services on the permitted traffic.

Configuration

To configure a default SSL proxy profile and apply it in a unified policy:

  1. Create an SSL profile and attach the CA profile group to the SSL proxy profile.
  2. Apply the signing certificate as root-ca in the SSL proxy profile.
  3. Define the SSL proxy profile as the default profile.
  4. Create a unified policy and specify the dynamic application as the match criteria.
  5. Apply the SSL proxy profile to the permitted traffic in the security policy.

Verification

Verify SSL Proxy Configuration

Purpose

Confirm that the configuration is working properly by displaying the SSL proxy statistics.

Action

From operational mode, enter the show services ssl proxy statistics command.

user@host> show services ssl proxy statistics

Meaning

The command output displays the following information:

  • Details about the sessions matched for the SSL proxy.

  • Details about the default SSL proxy profile such as the sessions where the default profile is applied and the sessions that are dropped due to the absence of the default profile.

See also

Configuring SSL Forward Proxy Certificate Chain

Understanding SSL Certificate Chain

This topic includes the following sections:

SSL Proxy Overview

SSL proxy acts as an intermediary, performing SSL encryption and decryption between the client and the server, but neither the server nor the client can detect its presence. SSL relies on digital certificates and private-public key exchange pairs for client and server authentication to ensure secure communication.

An SSL certificate (digital certificate) is provided by trusted companies to authenticate the identity of website owners and ensure secure communication between those websites and their customers by ensuring legitimacy of the identification information. However, many certificate authorities (CAs) use a complex certificate chain that includes a number of intermediate certificates.

In order to validate (and trust) an SSL certificate, the CA that issued the certificate must be included in the trusted CA list of the device that is connecting.

For example, when a connection is initiated, the connecting device (such as a Web browser) checks whether the certificate is issued by a trusted CA. If not, , the device checks whether the certificate of the issuing CA was issued by a trusted CA. This check continues until either a trusted CA is found (at which point a trusted, secure connection will be established), or no trusted CA can be found (at which point the device will usually display an error).

If the intermediate certificates are not included in the trusted CA list, then the Web browser of the clients might display a warning message stating that the certificate presented by the device they are accessing is not trusted.

You can resolve this issue by using an SSL certificate chain. The list of SSL certificates, from the root certificate to the end-user certificate, represents the SSL certificate chain.

SSL Certificate Chain Overview

Starting in Junos OS Release 15.1X49-D30, SSL forward proxy supports the certificate chain and sends it to facilitate the certification chain validation by the client (that is, the connecting device).

The certificate chain is a file that contains an ordered list of certificates, including an SSL certificate and a chain of intermediate CA certificates, in Privacy-Enhanced Mail (PEM) format. This enables the receiver to verify that the sender and all CAs are trustworthy.

A root CA certificate is a certificate issued by a trusted certificate authority. A certificate authority issues certificates in the form of a tree structure. A root certificate is the topmost certificate of the tree. All certificates below the root certificate inherit the trustworthiness of the root certificate; these certificates are called intermediate certificates.

Any certificate placed between the root CA certificate and the SSL certificate (used by end-users) is considered an intermediate certificate. These must be installed to the webserver with the end-user certificate for your website to link your certificate to a trusted authority.

Any certificate signed by a trusted root CA certificate is also trusted. The root CA certificate is always signed by the CA itself. The root CA certificate is the signer/issuer of the intermediate certificate. In turn, the signed intermediate certificate can sign another intermediate certificate and it will also be trusted. The chain terminates at the end-user certificate.

SSL forward proxy sends the entire certificate chain, excluding or including the root CA certificate, to facilitate certificate validation at the client side.

Figure 4 illustrates certificate chaining.

Figure 4: Certificate Chaining
Certificate Chaining

Root-CA is the common trusted CA for all devices in the network. Root-CA issues CA certificates to the engineering and sales CAs, which are identified as Eng-CA and Sales-CA, respectively. Eng-CA issues CA certificates to the development and quality assurance CAs, which are identified as Dev-CA and Qa-CA, respectively. Host-A receives its certificate from Dev-CA while Host-B receives its certificate from Sales-CA.

The end-user device needs to be loaded with the entire certificate chain. In this example, Host-A must have Root-CA, Eng-CA, and Dev-CA certificates; and Host-B must have Root-CA and Sales-CA certificates.

Advantage of Certificate Chains

SSL certificate chains eliminate the need to deploy all intermediate certificates separately on all clients.

Understanding Certificate Chain Processing

The following components are involved in certificate chain processing:

  • Administrator loads the certificate chain and the local certificate (signing certificate) into the PKI daemon certificate cache.

  • The Network Security Daemon (nsd) sends a request to the PKI daemon to provide the certificate chain information for a signing certificate configured in the SSL proxy profile.

  • SSL forward proxy stores this certificate chain information (CA certificate profile name) in therespective SSL profile. As a part of security policy implementation, SSL profiles having the certificate chain information and CA certificates are used.

Configuring the SSL Certificate Chain

This example shows how to install the certificate chain to enable browsers to trust your certificate. It shows how to install the root CA certificate and enable the certificate chain in order to ensure secure communications over the Web when using the service.

Requirements

No special configuration beyond device initialization is required before configuring this feature.

Overview

Some certificate authorities (CAs) do not sign with their root certificate, but instead use an intermediate certificate. An intermediate CA can sign certificates on behalf of the root CA certificate. The root CA signs the intermediate certificate, forming a chain of trust.

In order to trust a server's certificate, the client must be configured to trust the CA that signed the server certificate. However, clients are configured to trust only the root CA certificate. Therefore the server must present the chain of intermediate CA certificates to ensure that the trust is properly established when clients connect to a server.

Figure 5 depicts a full certificate chain, from the root CA certificate to the end-user certificate. The chain terminates at the end-user certificate.

Figure 5: Certification Path from the Certificate Owner to the Root CA
Certification
Path from the Certificate Owner to the Root CA

In this example, you have a domain, example.domain-1, and you want to purchase a certificate from XYZ-Authority for your domain. However, XYZ -Authority is not a Root-CA and the visiting Web browser trusts only Root-CA certificate. In other words, its certificate is not directly embedded in your Web browser and therefore it is not explicitly trusted. In this case, trust is established in the following manner using the certificate chain (of intermediate certificates):

  • End User Certificate is issued to example.domain-1; issued by XYZ-Authority.

  • XYZ-Authority utilizes a certificate (Certificate-1) issued by Intermediate CA-1.

  • Intermediate CA-1 utilizes a certificate (Certificate-2) issued by Intermediate CA-2.

  • Intermediate CA-2 utilizes a certificate (Certificate-3) issued by Intermediate CA-3.

  • Intermediate CA-3 utilizes a certificate (Certificate-4) issued by root-example-authority. The root-example-authority is a root CA.

    Its certificate is directly embedded in your Web browser; therefore it can be explicitly trusted. The certificate chain includes all the certificates starting from Certificate-1 to Root-CA certificate. Because the web browser trusts the root CA, it also implicitly trusts all the intermediate certificates.

Certificate-1 is your end-user certificate, the one you purchase from the CA. The certificates from 2 to 3 are called intermediate certificates. Certificate-4, at the end, is called the root CA certificate.

When you install your end-user certificate for the server example.domain-1, you must bundle all the intermediate certificates and install them along with your end-user certificate. If the SSL certificate chain is invalid or broken, your certificate will not be trusted by some devices.

Note
  • All certificates must be in Privacy-Enhanced Mail (PEM) format.

  • When you import the concatenated certificate file into the device, the CA provides a bundle of chained certificates that must be added to the signed server certificate. The server certificate must appear before the chained certificates in the combined file.

Configuration

Configuring the SSL certificate chain includes the following tasks:

  • Purchase an SSL certificate from a CA that includes a signing certificate and a respective key.

  • Configure a trusted CA profile group.

  • Load the intermediate and root CA in public key infrastructure (PKI) memory. This certificate file contains all the required CA certificates, one after each other, in PEM format.

  • Set up your device to use the signing certificate received from the CA by configuring and applying the SSL proxy profile to a security policy.

To configure the SSL certificate chain, you must:

  1. Load the signing certificate and the key on your device.
  2. Create a trusted CA profile for the intermediate or root CA certificate.
  3. Attach the signing certificate profile as created in Step 1 to the SSL proxy profile.
  4. Attach the trusted CA profiles created in Step 2 to the SSL proxy profile.

This example assumes that you have already purchased an SSL certificate from a CA.

Loading the Signing Certificate

Step-by-Step Procedure

To load the local certificate into the PKI memory:

  1. Load the signing certificate and the respective key for the SSL proxy profile in PKI memory.

    The following message is displayed:

    Note that the certificate ID will be used under the root-ca section in the SSL proxy profile.

Configuring Trusted CA Profiles for Intermediate or Root CA Certificates

Step-by-Step Procedure

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.

  • Load the intermediate or root CA certificate in the PKI memory.

    The CA profile includes the certificate information used for authentication. It includes the public key that SSL proxy uses when generating a new certificate.

    This certificate will be attached as a certificate chain.

Configuring the SSL Proxy Profile

Step-by-Step Procedure

SSL forward proxy stores this certificate chain information (CA certificate profile name) into respective the SSL profile. As a part of security policy implementation, SSL profiles having the certificate chain information and CA certificates are used.

  1. Attach the CA profile group to the SSL proxy profile. You can attach trusted CA one at a time or load all in one action.
  2. Apply the signing certificate as root-ca in 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.
  5. 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.
  6. Apply the SSL proxy profile to the security policy.
Verifying the Certificate Chain on the Device

Purpose

Viewing the certificate chain on the SRX Series device.

Action

You can view the certificate chain on the connecting Web browser (that is, the client).

Working with the Certificate Revocation Lists for SSL Proxy

A certificate issued by a certificate authority (CA) is supposed to be valid until the expiration of the validity period. In the normal course of business, a CA can revoke an issued certificate. A certificate is revoked if it is suspected that the certificate has been compromised. Some of the examples are:

  • Unspecified (no particular reason is given).

  • Private key associated with the certificate was compromised.

  • Private key associated with the CA that issued the certificate was compromised.

  • The owner of the certificate is no longer affiliated with the issuer of the certificate and does not have rights to access the certificate or does not require it any longer.

  • Another certificate replaces the original certificate.

  • The CA that issued the certificate has ceased to operate.

  • The certificate is on hold pending further action. It is treated as revoked but might be accepted in the future.

Once the CA determines to revoke a certificate, it publishes the information by some means so that the enduser certificate can use the information to validate a certificate. The CA can publish this information using certificate revocation list (CRL).

The CRL contains the list of digital certificates that have been canceled before their expiration date. When a participating device uses a digital certificate, it checks the certificate signature and validity. It also acquires the most recently issued CRL and checks that the certificate serial number is not on that CRL. By default, CRL verification is enabled on SSL proxy profile.

CRL validation on SRX Series device involves checking for revoked certificates from servers. You can enable or disable the CRL validation to meet your specific security requirements.

Starting with Junos OS Release 15.1X49-D30 and Junos OS Release 17.3R1, certificate revocation list (CRL) checks are supported.

Disabling CRL Verification

In order to enhance security, the certificate revocation checking feature has been enabled by default on SRX Series devices on any SSL proxy profile. You can enable or disable the CRL validation to meet your specific security requirements.

  • To disable CRL verification:

You can reenable CRL validation by using the delete services ssl proxy profile profile-name actions crl disable command.

Allowing Sessions When CRL Information Is Not Available

Sometimes CRL information might not be available because of various reasons. For example:

  • CRL download failed and the PKI daemon did not or could not fetch the CRL from the CA.

  • The CRL path was not available from the configuration and it is not present in the root or intermediate certificate, or no URL was configured.

You can allow or drop the sessions when a CRL information is not available.

  • To ensure that the sessions are not dropped for any reason when CRL information is not available:
  • To drop the sessions when CRL information is not available:

Allowing Sessions When CRL Status Is Unknown

You can configure how an SRX Series device will respond when updated CRL information is not available, and the server certificate that is currently offered is not known to be revoked from a previous query. Certificates are presumed not to be revoked, by default, which means they are valid, and a temporary failure to obtain a CRL does not automatically result in an SSL handshake failure. By default, sessions are allowed if CRL status is unknown.

You can configure an SRX Series device to accept a certificate without a reliable confirmation available on the revocation status.

  • To allow the sessions when a certificate is revoked and the revocation reason is on hold:

Application Security Services with SSL Proxy Overview

With the implementation of SSL proxy, AppID can identify applications encrypted in SSL. SSL proxy can be enabled as an application service in a regular firewall policy rule. Intrusion Detection and Prevention (IDP), application firewall (AppFW), application tracking (AppTrack), advanced policy-based routing (APBR) services, UTM, SKY ATP, and Security Intelligence (SecIntel) can use the decrypted content from SSL proxy.

To determine if a feature is supported by a specific platform or Junos OS release, refer Feature Explorer

On the SSL payload, IDP can inspect attacks and anomalies; for example, HTTP chunk length overflow on HTTPS. On encrypted applications, such as Facebook, AppFW can enforce policies and AppTrack (when configured in the from and to zones) can report logging issues based on dynamic applications.

Note

If none of the services (AppFW, IDP, or AppTrack) are configured, then SSL proxy services are bypassed even if an SSL proxy is attached to a firewall policy.

Note

The IDP module will not perform an SSL inspection on a session if an SSL proxy is enabled for that session. That is, if both SSL inspection and SSL proxy are enabled on a session, SSL proxy will always take precedence.

SSL Performance Enhancements

SSL proxy is fundamental building block for deciphering all encrypted HTTPS flows. All security services such as anti-virus, anti-spam, content security, SKY ATP rely on SSL proxy to handle clear text traffic for further processing.

The SSL/TLS handshake used for providing secure connections involves number of communications passed back and forth between the user’s browser (client) and web application (server) to verify if the connection is trusted. It 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, when using SSL/TLS for connections between clients and servers, the following new options are available for optimizing the SSL performance:

  • Using optimized RSA key exchanges

  • Using 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. This operation also does not involve RSA involvement. The default timeout period of the certificate cache entry is 600 seconds and it can be changed using the appropriate configuration. For example:

    To set the certificate cache timeout to 300 seconds, that is, the time in seconds that certificate details are stored in the cache, use the following command:

    To disable the certificate cache and allow the SSL full handshake to occur for a new connection, use the following command:

    To invalidate the existing certificate cache, use the following command:

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

Data Loss Prevention (DLP) Using ICAP Service Redirect

Data loss prevention (DLP) is a method of inspecting and keeping sensitive data from leaving the allowed perimeter. DLP systems are concerned with the data passing over some kind of perimeter gateway device. It relies on several core technologies that enable its engine to accurately identify the sensitive data that enterprise need to secure and take action to prevent incidents. It ensures that it is only accessed by authorized users and are safeguarded against data leak.

Junos OS ICAP Support for SRX Series Device

You can prevent data loss from your network by employing Internet Content Adaptation Protocol (ICAP) redirect services. ICAP is a lightweight HTTP-based remote procedure call protocol. ICAP allows its clients to pass HTTP-based content (HTML) to the ICAP servers for performing services such as virus scanning, content translation, or content filtering and so on for the associated client requests.

SRX Series devices support DLP to redirect HTTP or HTTPS traffic to any third-party server through ICAP. The SRX Series device acts as an SSL proxy server and decrypts the pass-through traffic with the proper SSL profile under a security policy. SRX Series device decrypts HTTPS traffic and redirects HTTP message to a third-party, on-premise server using an ICAP channel. After DLP processing, the traffic is redirected back to the SRX Series device and action is taken according to the results from the ICAP server. If any sensitive data is detected per the policies, the SRX Series device logs, redirects, or blocks the data traffic as configured in the profile.

The following sequences are involved in a typical ICAP redirect scenario:

  1. The user opens a connection to a Website on the internet.

  2. The request goes through the SRX Series device that is acting as a proxy server.

  3. The SRX Series device receives information from the end-host, encapsulates the message and forwards the encapsulated ICAP message to the third-party on-premise ICAP server.

  4. The ICAP server receives the ICAP request and analyzes it.

  5. If the request does not contain any confidential information, the ICAP server sends it back to the proxy server, and directs the proxy server to send the HTTP to the internet.

  6. If the request contains confidential information, you can choose to take action (block, permit, log) as per your requirement.

Note

The HTTP throughput depends on the connections between the SRX Series device and the ICAP channel.

ICAP Profile

When you configure ICAP redirect service on SRX Series devices, you must configure the ICAP server information. This profile is applied to a security policy as application services for the permitted traffic. The ICAP profile defines the settings that allow the ICAP server to process request messages, response messages, fallback options (in case of a timeout), connectivity issues, too many requests, or any other conditions.

Service Redirect for Layer 7 Dynamic Applications with Unified Policies

Starting from Junos OS Release 18.2R1, SRX Series devices support ICAP service redirect feature when the device is configured with unified policies.

Unified policies are the security policies that enable you to use dynamic applications as match conditions as part of the existing 5-tuple or 6-tuple (5-tuple with user firewall) match conditions to detect application changes over time.

In a unified policy with dynamic applications as a match condition, you configure an ICAP redirect profile and SSL proxy profile and apply these profiles as application services in the security policy for the permitted traffic. When the traffic matches the policy, the ICAP redirect service profile that is configured as application services is applied. The ICAP server profile defines the behavior of redirection and server specifications. The ICAP server performs the policy scan and the traffic is redirected to the SRX Series device, and the specified action is taken as per the ICAP redirect profile.

Note the following behavior while using ICAP redirect service with unified policy:

  • When ICAP redirect is configured in a unified policy and the data that needs to be redirected has arrived and the final policy is not determined, the request is ignored by the ICAP redirect service.

  • Because ICAP redirect is one of services located in the service chain, the data received by the ICAP redirect service might be different from the original data. The data sent by the ICAP redirect might affect downstream services.

Benefits of ICAP Redirect Service Support

  • Keeps the sensitive data from leaving the network.

  • Supports common on-premise server pool for redirection thereby improving management, security, and control of the content.

Note

The HTTP throughput depends on the connections between the SRX Series device and SRX ICAP .

Example: Configuring ICAP Redirect Service on SRX Devices

This example shows how to define an ICAP redirect profile for an SRX Series device.

Requirements

This example uses the following hardware and software components:

  • SRX Series device with Junos OS Release 18.1R1 or later. This configuration example is tested for Junos OS Release 18.1R1.

    ICAP redirect profile for an SRX Series device with unified policies example is tested for Junos OS Release 18.2R1.

No special configuration beyond device initialization is required before configuring this feature.

Overview

In this example, you configure an ICAP redirect profile and an SSL proxy profile and apply these profiles as application services in the security policy for the permitted traffic.

To enable the service redirect using ICAP, you must configure an SSL profile to secure the connection to the ICAP server. Next, you configure a security policy to process the traffic, and specify the action for the permitted traffic.

Table 14 lists the details of the parameters used in this example.

Table 14: ICAP Redirect Configuration Parameters

Parameters

Names

Description

Profile

icap-pf1

The ICAP server profile allows the ICAP server to process request messages, response messages, fallback options and so on, for the permitted traffic. This profile is applied as an application service in the security policy.

Server name

icap-svr1

icap-svr2

The machine name of the remote ICAP host. Client’s request is redirected to this ICAP server.

Server IP address

5.0.0.2

5.0.0.179

The IP address of the remote ICAP host. Client’s request is redirected to this ICAP server.

SSL proxy profile

ssl-inspect-profile

An SSL proxy profile defines SSL behavior for the SRX Series device. The SSL proxy profile is applied to the security policy as an application service.

SSL profile

dlp_ssl

The SRX Series device that is acting as an SSL proxy client, initiates and maintains SSL sessions with an SSL server. This configuration enables you to secure the connection to the ICAP server.

Security policy

sp1

In a security policy, apply the SSL proxy profile and ICAP redirect profile. to the permitted traffic.

Configuration

CLI Quick Configuration

To quickly configure this 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

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure the ICAP redirect service:

  1. Configure the SSL proxy profile.
  2. Configure the SSL profile for a secured connection with the ICAP server.
  3. Configure the ICAP redirect profile for the first server (icap-svr1).
  4. Configure the ICAP redirect profile for the second server (icap-svr2).
  5. Configure the redirect request and the redirect response for the HTTP traffic.
  6. Configure a security policy to apply application services for the ICAP redirect to the permitted traffic.
  7. Configure interfaces and zones.

Results

From configuration mode, confirm your configuration by entering the show services icap-redirect, show security policies, show security zones, and show interfaces commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

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

Configuring ICAP Service Redirect for Unified Policy

Step-by-Step Procedure

You can follow the procedure below if you have configured a unified policy (supported from Junos OS Release 18.2R1).

The following example requires you to navigate to various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure the ICAP redirect service:

  1. Configure the SSL proxy profile.
  2. Configure the SSL profile for secured connection with the ICAP server.
  3. Configure the ICAP redirect profile for the first server (icap-svr1).
  4. Configure the ICAP redirect profile for the second server (icap-svr2).
  5. Configure the redirect request for HTTP traffic.
  6. Configure a security policy to apply application services for the ICAP redirect to the permitted traffic.

Verification

Verifying ICAP Redirect Configuration

Purpose

Verify that the ICAP redirect service is configured on the device.

Action

From operational mode, enter the show services icap-redirect status and show services icap-redirect statistic commands.



Meaning

The status Up indicates that the ICAP redirect service is enabled. The Message Redirected and the Message Received fields show the number of HTTP requests that have passed through the ICAP channel.

Release History Table
Release
Description
Starting from Junos OS Release 18.2R1, SRX Series devices support ICAP service redirect feature when the device is configured with unified policies
Starting in Junos OS Release 18.1R1, SSL proxy support is available on SRX300 and SRX320 devices
Starting with Junos OS Release 17.4R1, the whitelisting feature is extended to support custom URL categories supported by UTM.
Starting in Junos OS Release 15.1X49-D80, SSL reverse proxy is supported on SRX5000 Series, SRX4100, SRX4200, SRX1500 devices
Starting in Junos OS Release 15.1X49-D80, 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, 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-D30 and Junos OS Release 17.3R1, server certificates of key size 4096 bits are supported.
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-D30 and Junos OS Release 17.3R1, certificate revocation list (CRL) checks are supported.
Starting with Junos OS Release 15.1X49-D20 and Junos OS Release 17.3R1, the SSL protocol 3.0 (SSLv3) support is deprecated.