For inbound SSL traffic, when a client tries to access the secure server using SSL, the Sensor acts as a proxy between the client and the server. The Sensor intercepts the client request and forwards the request to the server as the client. Based on the rule configured the Sensor decrypts and scans the traffic.
Note
Proxy based inbound SSL decryption can be configured only on NS7500 and NS9500 standalone Sensors. You cannot configure proxy based inbound SSL decryption on a stack of NS9500 Sensors.
Note
Proxy based SSL decryption is not supported on G0/1-G0/2 ports.
Note
Decryption of VLAN tagged packets on Inbound SSL traffic in proxy based method is supported in NS9500 Standalone Sensor software version 10.1.5.41 or later and NS7500 Sensor software version 10.1.5.64 or later.
Note
Decryption of double VLAN tagged packets on Inbound SSL traffic in proxy based method is not supported.
The steps to decrypt inbound SSL traffic by the Sensor are given below:
- The client sends a secure request to the web server.
- The Sensor intercepts the request and responds with the server certificate configured as part of the proxy rule.
- Sensor decrypts and inspects the client request. If any malicious activity is found, the Sensor raises an alert in the Attack Log.
- The Sensor sends the response from the server to the client.
Port clustering for proxy-based SSL decryption in NS9500 standalone Sensor
Multiple monitoring port pairs in inline mode can be grouped together to create a port cluster. The same IPS policy will apply for traffic arriving on any of the inline pairs in the port cluster.
The following are the considerations for using port clusters with proxy based SSL decryption:
- Port Cluster for proxy based SSL decryption is supported only for inline port pairs.
- All paths in the network formed by the inline port pairs must be active paths (should not be blocked by any link layer protocols) on which packets can be forwarded.
- Packets on the egress path (from the Sensor towards the client or server) may not follow the same path on which they arrived. For example, consider ports G1/1-G1/2, G1/3-G1/4 are grouped in a port cluster. A packet arriving on port G1/1 may exit from port G1/4.
- SSL sessions will always be reported against the least index port of the port cluster even when the traffic is received on the other ports in the port cluster.
For example, if G1/1, G1/2, G2/1, and G2/2 are in a port cluster with proxy based SSL enabled, even if the client and server packets are received over the physical G2/1 and G2/2 links, the show ssl stats outbound proxy sessions command displays that sessions are formed on G1/1 and G1/2. This behavior holds good even if ports G1/1 and G1/2 are not operational.