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.
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.
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.
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.