Starting with Junos OS Release 15.1X49-D80 and Junos OS Release 17.3R1, the SRX Series device acts as a proxy, so it can downgrade SSL negotiation to RSA. Other changes are shown in Table 20.
Table 20: Comparing Reverse Proxy Before and After Junos OS Release 15.1X49-D80 and 17.3R1
Feature | Prior to 15.1X49-D80 | After 15.1X49-D80 and 17.3R1 |
|---|---|---|
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. | Supports RSA. |
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. |
The remainder of this topic uses the term SSL proxy to denote both forward proxy and reverse proxy.
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 terminates 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.
# show services ssl
...
proxy {
profile ssl-inspect-profile-dut { # For forward proxy. No server cert/key is needed.
root-ca ssl-inspect-ca;
actions {
ignore-server-auth-failure;
log {
all;
}
}
}
profile ssl-1 {
root-ca ssl-inspect-ca;
actions {
ignore-server-auth-failure;
log {
all;
}
}
}
profile ssl-2 {
root-ca ssl-inspect-ca;
actions {
ignore-server-auth-failure;
log {
all;
}
}
}
profile ssl-server-protection { # For reverse proxy. No root-ca is needed.
server-certificate ssl-server-protection;
actions {
log {
all;
}
}
}
}
...
You must configure either root-ca or server-certificate in an SSL proxy profile. Otherwise the commit check fails. See Table 21.
Table 21: 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:
user@host> request security pki local-certificate load filename /cf0/cert1.pem key /cf0/key1.pem certificate-id server1_cert_id passphrase example@1234
user@host# set services ssl proxy profile server-protection-profile server-certificate server2_cert_id passphrase example@1234
user@host# show services ssl
profile server-protection-profile {
server-certificate [server1_cert_id , server2_cert_id];
actions {
logs {
all;
}
}
}