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 Firewalls to inspect HTTP traffic encrypted in SSL on any port. The following SSL protocols are supported:
SSLv2
SSLv3
TLS
See Also
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.
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 Firewalls.
| 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 /documentation/us/en/software/junos/vpn-ipsec/topics/topic-map/security-ipsec-vpn-overview.html. Table 2 shows the 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 |
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 three 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.
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 Firewalls 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.
Junos OS does not encrypt SSL keys file.
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.
set security idp sensor-configuration detector protocol-name SSL tunable-name sc_ssl_flags tuneable-value 1
To configure an IDP SSL inspection, use the following CLI procedure:
[edit security]
idp {
sensor-configuration {
ssl-inspection {
sessions <number>;
}
}
The sensor now inspects traffic for which it has a key/server pair.
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:
request security idp ssl-inspection key add key-name file file-path server server-ip password password-string
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:
request security idp ssl-inspection key add key-name server server-ip
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:
user@host> request security idp ssl-inspection key deleteAll 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:
user@host> request security idp ssl-inspection key delete <key-name>Deletes the specified key and all servers associated with that key.
To delete a single server, use the following CLI command:
user@host> request security idp ssl-inspection key delete <key-name> server <server-ip>
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:
user@host> show security idp ssl-inspection key
Displays all server keys and IP addresses bound to those keys. The following example shows CLI output when the
show security idp ssl-inspection keycommand is used:Total SSL keys : 2 SSL server key and ip address : Key : key1, server : 10.1.1.1 Key : key2, server : 10.2.2.2 Key : key2, server : 10.2.2.3 -
To display IP addresses bound to a specific key, use the following CLI command:
user@host> show security idp ssl-inspection key <key-name>
The following is an example of the CLI output received when the
show security idp ssl-inspection key <key-name>command is used:Key : key1, server : 10.1.1.1
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:
Create zones. See Example: Creating Security Zones.
Configure an address book with addresses for the policy. See Example: Configuring Address Books and Address Sets.
Create an application (or application set) that indicates that the policy applies to traffic of that type. See Example: Configuring Security Policy Applications and Application Sets.
Create an SSL proxy profile that enables SSL proxy by means of a policy. See Configuring SSL Forward Proxy.
Configure an IDP policy as an active policy.
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.
set security policies from-zone Z_1 to-zone Z_2 policy policy1 match source-address any set security policies from-zone Z_1 to-zone Z_2 policy policy1 match destination-address any set security policies from-zone Z_1 to-zone Z_2 policy policy1 match application junos-https set security policies from-zone Z_1 to-zone Z_2 policy policy1 then permit application-services ssl-proxy profile-name ssl-profile-1 set security policies from-zone Z_1 to-zone Z_2 policy policy1 then permit application-services idp
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.
Configure a policy to process the traffic with SSL proxy profile ssl-profile-1.
[edit security policies from-zone Z_1 to-zone Z_2 policy policy1 user@host# set match source-address any user@host# set match destination-address any user@host# set match application junos-https user@host# set then permit application-services ssl-proxy profile-name ssl-profile-1
Define IDP as the application service.
[edit security policies from-zone Z_1 to-zone Z_2 policy policy1 user@host# set then permit application-services idp
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.