Timeouts when using secure ICAP in SPE engine

Products

• Protection Engine for Cloud Services

Issue/Introduction

SPE for cloud services operates in encrypted TLS mode. Some customers have transitioned from Plain TLS to Secure TLS, enabling Secure ICAP communication between SPE and the application that sends scan requests to SPE. However, after these changes, they are experiencing unacceptable behavior. While the application generally runs fine, it occasionally "hangs."

Note: IP addresses mentioned in this article are changed randomly for clarification purpose.

When it hangs, it writes request "OPTIONS icap://192.0.2.1:11344/SYMCScanResp-AV ICAP/1.0" to the socket and after that it waits for response for unacceptable time (it varies, but it is often more than 3 minutes).

When you run the test on the application on (IP address 192.0.2.1) against testing server 10.28.166.12. We can observe, it wrote request to the socket (at 2022-07-04 09:20:42.992) and it waits till 2022-07-04 09:25:39.750 when it got response from server.

During the test, and after running tcpdump on the server to capture network traffic ("tcpdump -i any -n port not 22 -s 0 -w tls_icap.dmp"). In the capture, we can also see the "gap" in the communication:

No. Time Source Destination Protocol Length Info
325 2022-07-04 07:20:46,426250 192.0.2.1 10.28.166.12 TLSv1.2 147 Application Data
326 2022-07-04 07:20:46,467091 10.28.166.12 192.0.2.1 TCP 56 11344 → 17042 [ACK] Seq=3842205098 Ack=256320745 Win=30336 Len=0
327 2022-07-04 07:20:53,215483 14:a9:d0:00:2c:92  ARP 62 Who has *****
328 2022-07-04 07:20:53,215497 00:50:56:a2:c4:8b  ARP 44 *****
329 2022-07-04 07:21:28,671099 00:50:56:a2:c4:8b  ARP 44 Who has *****
330 2022-07-04 07:21:28,671635 14:a9:d0:00:2c:92  ARP 62 *****
331 2022-07-04 07:22:21,919103 00:50:56:a2:c4:8b  ARP 44 Who has *****
332 2022-07-04 07:22:21,919536 14:a9:d0:00:2c:92  ARP 62 *****
333 2022-07-04 07:25:43,219423 10.28.166.12 192.0.2.1 TLSv1.2 87 Encrypted Alert
334 2022-07-04 07:25:43,219500 10.28.166.12 192.0.2.1 TCP 56 11344 → 17025 [FIN, ACK] Seq=212934677 Ack=1687148871 Win=31360 Len=0

From the tcpdump capture and the application log, It seems that the application is waiting for the server.

Useful commands:

[root@]# uname -a
Linux *hostname* 4.18.0-240.el8.x86_64 #1 SMP Wed Sep 23 05:13:10 EDT 2020 x86_64 x86_64 x86_64 GNU/Linux
[root@]# cat /etc/redhat-release
Red Hat Enterprise Linux release 8.3 (Ootpa)
[root@]# rpm -qa | grep SYMCScan
SYMCScan-8.2.2.7-1.x86_64
[root@# free
              total        used        free      shared  buff/cache   available
Mem:       16211476      570572    14890696       24536      750208    15342984
Swap:       3358716           0     3358716

Server itself does not report any performance or capacity issues (no high CPU utilization, no OOM killer or any "suspicious" records in /var/log/messages)

Environment

Release : SPE 8.2.2

The SPECS server is running Red Hat Enterprise Linux (RHEL) with the following specifications:

• Operating System: RHEL 8
• Kernel Version: 4.18.0-240
• Hardware Architecture: 64-bit (x86_64)

 

Resolution

The persistent connection was implemented to utilize the ICAP (keep-alive) setting.

Note: keep alive mechanism, is meant to reuse the existing TLS connections and reduce the need of repeating handshake

This setting can reduce resource utilization on the server. It is mostly for performance consideration. 

The keep-alive connection reduces frequent opening and closing connections, resulting in
lesser CPU/memory usage, lesser network congestion and reduced latency in subsequent
requests when compared to the legacy method.

The client application provides the maximum required persistent connection pool size to the
server during initialization. Depending on the scan request load, the number of persistent
connections will dynamically increase to the specified maximum number. If all connections
are busy and no more connections can be created (more than the specified keep-alive
connection), and the client tries to send a scan request, the API will return an error
(SCSCANFILE_CONNPOOLSIZE_EXCEEDED or SC_CONNPOOLSIZE_EXCEEDED). In
case the client does not send scanning requests or persistent connections remain idle for more
than 5 minutes, Symantec Protection Engine will close the connection and free up the server
resources

 

To check for SSL certificate, you can use this external link: https://www.digicert.com/help/

 

 

Additional Information

Please also see the following:

Protection Engine Secure ICAP TLS Handshake Error: ssl3_get_record:wrong version number