Important Changes to the SSLVA's Session Cache Lookup

Products

• SSL Visibility Appliance Software

Issue/Introduction

SSLVA version 3.8.5-16 is now GA. This release contains important changes that will affect rule positioning for some deployments. 

1. The session cache lookup algorithm has been redesigned and no longer uses the Source IP as a match condition. This was required to resolve errors that were seen when the Source IP of an SSL flow changed and then attempted to re-use the same SSL session details. One example of this would be a client that switches from the LAN to WiFi network. Another example would be a "Proxy on a stick" topology where the SSL flow traverses the SSLV more than once and the Proxy changes the Source IP address (Client > SSLV > Proxy > SSLV > Internet).

2. The addition of Layer3/Layer4 rules. These rules were added to resolve issues seen in the "Proxy on a stick" topology. Since the SSLV no longer matches on Source IP it would attempt to decrypt the flow twice, which causes errors. The Layer3/Layer4 rules are now applied at the Client Hello record instead of the Server Hello/Server Certificate records. These rules must be applied before any non-Layer3/Layer4 rules.

A Layer3/Layer4 rule must have an action of Cut Through, Drop or Reject and may contain the following match conditions.

• Source IP address (or list of addresses)
• Destination IP address (or list of addresses)
• Destination Port
• Traffic Class

 

Resolution

An example of a topology and changes required to support Layer3/Layer4 rules are attached.


Since the Layer3/Layer4 rules are now applied at the Client Hello, any SSL flows matching these rules will show "Unknown" for Domain Name and Cipher Suite in the Session logs. This is normal since the SSLV is no longer looking at the Server Hello/Server Certificate where this information is normally found.


As an added benefit Layer3/Layer4 rules can also be used to cut through specific SSL sites where the complete Server Hello/Server Certificate records are not making it to the SSLV. Previously these flows could not be cut through and the session would fail since the policy decision was made after receiving the Server Hello/Server Certificate records. Now that these rules are applied at the Client Hello any SSL sites that are having issues can be cut through and debugged on an individual basis instead of bypassing the entire SSLV.