What are the possible reasons why SSL traffic is not detected and logged in SSLV Session log?

book

Article ID: 169242

calendar_today

Updated On:

Products

SSL Visibility Appliance Software

Issue/Introduction

With current design, SSLV device is looking for SSL only in TCP traffic. SSLV will check for anything that looks like SSL only within the first 32 payload packets right after the TCP 3-way handshake is completed. If SSL traffic comes after the 32 first packets, then we won't identify it. 

If a SSLV pcap was done during troubleshooting of the issue, it may also appear to have stopped mid-stream. The flow processor responsible for SSL detection just stopped sending further packets via the PCIe bus(where the actual pcap is taken), because it no longer continued in SSL traffic detection for that particular TCP session.

Common scenario:
Integration with Proxies that re-use one TCP connection for different HTTP requests (HTTP persistence enabled).
We can have a HTTP GET bigger than 32 packets followed by a HTTP CONNECT. From the SSLV’s perspective this would look to be an HTTP connection and not an SSL connection, so it stops listening and the flow proceeds as such. The SSLVA is not able to identify there is an SSL session, and there is no log entry created in the SSL Session Log as well.

 

Cause

All TCP 3-way handshake packets (SYN, SYN-ACK, ACK) were not seen by the SSLV device or SSL appeared after the 32 payload packets from the initial 3-way handshake may be a common reason why it is not detected and consequently not logged in Session log.

 

Resolution

The limit 32 payload packets was put in place because the SSLV can’t listen to a TCP stream indefinitely, it has to make a decision at some point in order to preserve resources.

Workaround

For the Proxy scenarios, you may try to disable HTTP persistency for SSL traffic.