Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

IDP SSL Inspection

Secure Sockets Layer (SSL), also called Transport Layer Security (TLS), is a protocol suite for Web security that provides authentication, confidentiality and message integrity. 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.

For more information, see the following topics:

IDP SSL Overview

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

Juniper Networks provides Intrusion Detection and Prevention (IDP) SSL inspection that uses the SSL protocol suite consisting of different SSL versions, ciphers, and key exchange methods. Combined with the Application Identification feature, the SSL Inspection feature enables SRX Series devices to inspect HTTP traffic encrypted in SSL on any port. The following SSL protocols are supported:

  • SSLv2

  • SSLv3

  • TLS

Supported IDP SSL Ciphers

An SSL cipher comprises encryption cipher, authentication method, and compression. Junos OS supports all OPENSSL supported ciphers that do not involve the use of temporary private keys. For authentication, NULL, MD5, and SHA-1 authentication methods are supported.

Note:

Compression and SSLv2 ciphers are not supported. Currently, most SSL servers automatically upgrade to a TLS cipher when an SSLv2 cipher is received in a client “hello” message. Check your browser to see how strong the ciphers can be and which ones your browser supports. (If the cipher is not in the list of supported ciphers, the session is ignored for deep packet inspection.)

Table 1 shows the encryption algorithms supported by the SRX Series devices.

Table 1: Supported Encryption Algorithms
Cipher Exportable Type Key Material Expanded Key Material Effective Key Bits IV Size

NULL

No

Stream

0

0

0

N/A

DES-CBC-SHA

No

Block

8

8

56

8

DES-CBC3-SHA

No

Block

24

24

168

8

AES128-SHA

No

Block

16

16

128

16

AES256-SHA

No

Block

32

32

256

16

For more information on encryption algorithms, see IPsec VPN Overview. Table 2 shows the supported SSL ciphers.

Table 2: Supported SSL Ciphers
Cipher Suites Value

TLS_RSA_WITH_NULL_MD5

TLS_RSA_WITH_NULL_SHA

TLS_RSA_WITH_DES_CBC_SHA

TLS_RSA_WITH_3DES_EDE_CBC_SHA

TLS_RSA_WITH_AES_128_CBC_SHA

TLS_RSA_WITH_AES_256_CBC_SHA

0x0001

0x0002

0x0009

0x000A

0x002F

0x0035

Note:

RC4 and IDEA ciphers are not supported because of license and OPENSSL library availability.

Understanding IDP Internet Key Exchange

Internet Key Exchange (IKE) establishes a premaster secret that is used to generate symmetric keys for bulk data encryption and authentication. Section F.1.1 of RFC 2246 defines Transport Layer Security (TLS) authentication and key exchange methods. The two key exchange methods are:

  • RSA—Rivest-Shamir-Adleman (RSA) is a key exchange algorithm that governs the way participants create symmetric keys or a secret that is used during an SSL session. The RSA key exchange algorithm is the most commonly used method.

  • DSA—Digital Signature Algorithm (DSA) adds an additional authentication option to the IKE Phase 1 proposals. The DSA can be configured and behaves analogously to the RSA, requiring the user to import or create DSA certificates and configure an IKE proposal to use the DSA. Digital certificates are used for RSA signatures, DSA signatures, and the RSA public key encryption based method of authentication in the IKE protocol.

  • Diffie-Hellman— Diffie-Hellman (DH) is a key exchange method that allows participants to produce a shared secret value. The strength of the technique is that it allows participants to create the secret value over an unsecured medium without passing the secret value through the wire.

The key exchange methods can use either a fixed or a temporary server key. IDP can successfully retrieve the premaster secret only if a fixed server key is used. For more information on Internet Key Exchange, see Basic Elements of PKI in Junos OS.

Note:

Juniper IDP does not decrypt SSL sessions that use Diffie-Hellman key exchange.

IDP Cryptographic Key Handling Overview

With the Intrusion Detection and Prevention (IDP) Secure Sockets Layer (SSL) decryption feature, SRX Series devices load configured RSA private keys to memory and use them to establish SSL session keys to decrypt data. IDP is required to decrypt the RSA keys and to check the integrity before performing normal encryption or decryption operations using the keys.

The primary purpose of this feature is to ensure that RSA private keys used by IDP are not stored as plain text or in an easily understandable or usable format. The keys are decrypted to perform normal encryption or decryption operations. This feature also involves error detection checks during copying of the keys from one memory location to another, as well as overwriting of intermediate storage with nonzero patterns when the keys are no longer needed.

The set security idp sensor-configuration ssl-inspection key-protection CLI configuration command is used to enable this feature.

Understanding IDP SSL Server Key Management and Policy Configuration

The device can support up to 1000 server private keys. Each key can have up to 100 servers that use it. This capacity is the same regardless of the number of SPUs available on the device because essentially each SPU needs to be able to access all the keys.

Multiple servers can share the same private key; however, one server can have only one private key. SSL decryption is disabled by default. Both plain and encrypted keys are supported.

Note:

Junos OS does not encrypt SSL keys file.

Note:

You can set the value of SSL session ID cache timeout parameter by using the set security idp sensor-configuration ssl-inspection session-id-cache-timeout command. The default value of the cache timeout parameter is 600 seconds.

Configuring an IDP SSL Inspection (CLI Procedure)

SSL decoder is enabled by default. If you need to manually enable it via CLI, use the following CLI command.

To configure an IDP SSL inspection, use the following CLI procedure:

The sensor now inspects traffic for which it has a key/server pair.

Note:

Maximum supported sessions per SPU: default value is 10,000 and range is 1 through 100,000. The session limit is per SPU, and it is the same regardless of the number of SPUs on the device.

Adding IDP SSL Keys and Associated Servers

When you are installing a key, you can password protect the key and also associate it to a server.

To install a Privacy-Enhanced Mail (PEM) key, use the following CLI command:

Note:

In a two-node SRX Series cluster, the key has to be manually copied over to both Node 0 and Node 1 at the same location for the request command to be successful.

You can also associate the key with a server at a later time by using the add server CLI command. A server can be associated with only one key. To associate a server to the installed key, use the following CLI command:

Note:

The maximum key name length is 32 bytes, including the ending “\0”.

Deleting IDP SSL Keys and Associated Servers

  • To delete all keys and servers, use the following CLI command:

    All installed keys are deleted along with any associated servers.

  • To delete a specific key and all associated servers with that key, use the following CLI command:

    Deletes the specified key and all servers associated with that key.

  • To delete a single server, use the following CLI command:

    Deletes the specified server that is bound to the specified key.

Displaying IDP SSL Keys and Associated Servers

  • To display all installed server keys and associated server, use the following CLI command:

    Displays all server keys and IP addresses bound to those keys. The following example shows CLI output when the show security idp ssl-inspection key command is used:

  • To display IP addresses bound to a specific key, use the following CLI command:

    The following is an example of the CLI output received when the show security idp ssl-inspection key <key-name> command is used:

Example: Configuring IDP When SSL Proxy Is Enabled

This example describes how IDP supports the application identification (AppID) functionality when SSL proxy is enabled.

Requirements

Before you begin:

Overview

This example shows how to configure IDP in a policy rule when SSL proxy is enabled.

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, and then copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Procedure

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.

In this example, you configure a security policy that uses IDP as the application service.

  1. Configure a policy to process the traffic with SSL proxy profile ssl-profile-1.

  2. Define IDP as the application service.

Results

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

Verification

Verify that the configuration is working properly. Verification in IDP is similar to verification in Application Firewall. See Application Firewall.