Encrypt Traffic Using SSL Proxy and TLS

SSL Proxy Overview

SSL proxy is supported on SRX Series devices only.

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.

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

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.

Logical Systems Support

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

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

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

Limitations

Configuring SSL Forward Proxy

• SSL Proxy Configuration Overview

• Configuring a Root CA Certificate

• Generate a Root CA Certificate with CLI

• Generate a Root CA Certificate with OpenSSL

• Configuring a CA Profile Group

• Importing a Root CA Certificate into a Browser

• Applying an SSL Proxy Profile to a Security Policy

• Configuring SSL Proxy Logging

• Configuring Certificate Authority Profiles

• Exporting Certificates to a Specified Location

• Ignoring Server Authentication

SSL Proxy Configuration Overview

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

• Configuring the root CA certificate

• Loading a CA profile group

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

• Create a security policy by defining input traffic match criteria

• Applying an SSL proxy profile to a security policy

• Optional steps such as creating whitelists and SSL proxy logging

Figure 2: SSL Proxy Configuration Overview

Configuring a Root CA Certificate

Generate a Root CA Certificate with CLI

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

• Certificate identifier (generated in the previous step)

• Fully qualified domain name (FQDN) for the certificate

• e-mail address of the entity owning the certificate

• Common name and the organization involved

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

   Example:
2. Define a self-signed certificate.

   Example:

   By configuring the add-ca-constraint option, you make sure that the certificate can be used for signing other certificates.

3. From configuration mode, apply the loaded certificate as root-ca in the SSL proxy profile.

   Example:
4. Import the root CA as a trusted CA into client browsers. This is required for the client browsers to trust the certificates signed by the SRX Series device. See Importing a Root CA Certificate into a Browser.

Generate a Root CA Certificate with OpenSSL

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

   This step creates an RSA key using the 3DES encryption named ca.key that is 2048 in length. You also need to enter a password that is used to encrypt the private key. This is critical to security if the key is lost because it will still be encrypted.

4. Create a CA certificate based on the CA private key (created in the previous step).

   The expiration date for this certificate is 3 years or 1095 days. However, you can set it to a different value. When creating the certificate, you need to enter the password and the certificate information that includes distinguished name (DN), country name, and so forth.

5. Import the CA private and public keys into the SRX Series device. Copy the ca.key and ca.cer keys to the /var/tmp directory on the SRX Series device. You can copy using SCP, or open the files and copy them into “vi” on the SRX Series device to create new files.
6. From configuration mode, apply the loaded certificate as root-ca in the SSL proxy profile.
7. Import the root CA as a trusted CA into client browsers. This is required for the client browsers to trust the certificates signed by the SRX Series device. See Importing a Root CA Certificate into a Browser.

Configuring a CA Profile Group

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

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

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

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

     Example:

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

     From operational mode, load the trusted list to the device (the group name identifies the CA profile group):

     Example:
2. Attach the trusted CA or trusted CA group to the SSL proxy profile. You can attach all trusted CA or one trusted CA at a time:

   • Attach all CA profile groups:

     Example

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

     Example

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

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

Importing a Root CA Certificate into a Browser

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

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

   From Internet Explorer (version 8.0):

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

   From Firefox (version 39.0):

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

   From Google Chrome (45.0):

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

Applying an SSL Proxy Profile to a Security Policy

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

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

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

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

Configuring SSL Proxy Logging

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

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

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

Configuring Certificate Authority Profiles

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

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

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

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

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

   Example:

   Note

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

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

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

Exporting Certificates to a Specified Location

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

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

Ignoring Server Authentication

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

We do not recommend using this option for authentication because configuring it results in websites not being authenticated at all. However, you can use this option to effectively identify the root cause of dropped SSL sessions.

From configuration mode, specify to ignore server authentication:

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

Table 2 shows the flags that are supported.

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

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

• System failures such as memory allocation failures.

• Ciphers do not match.

• SSL versions do not match.

• SSL options are not supported.

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

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

Transport Layer Security (TLS) Overview

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

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

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

• Benefits of TLS

• TLS Versions

• Three Essential Services of TLS

• TLS Handshake

• Encrypting Syslog Traffic with TLS

Benefits of TLS

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

TLS Versions

Following are the versions of TLS:

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

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

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

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

Three Essential Services of TLS

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

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

• Authentication—As part of the TLS handshake, the protocol allows both server and the client to authenticate their identity. Implicit trust between the client and the server (because the client accepts the certificate generated by the server) is an important aspect of TLS. It is extremely important that server authentication is not compromised; however, in reality, self- signed certificates and certificates with anomalies are in abundance. Anomalies can include expired certificates, instances of common name not matching a domain name, and so forth.

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

TLS Handshake

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

Encrypting Syslog Traffic with TLS

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

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

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

Configuring the TLS Syslog Protocol on SRX Series device

• Requirements

• Overview

• Configuration

• Verification

Requirements

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

Overview

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

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

Configuration

CLI Quick Configuration

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

Step-by-Step Procedure

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

Results

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

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

Verification