Vulnerability scanners flag RC4 ciphers during bare-IP scans on EdgeSWG
search cancel

Vulnerability scanners flag RC4 ciphers during bare-IP scans on EdgeSWG

book

Article ID: 449742

calendar_today

Updated On:

Products

ISG Proxy

Issue/Introduction

Vulnerability scanners may incorrectly report that RC4 ciphers are available on an EdgeSWG (ProxySG) appliance even after SSL Device Profiles have been configured to disable them. This behavior typically occurs during bare-IP scans.

Environment

 

  • EdgeSWG (ProxySG)

  • SGOS 7.x

  • Vulnerability Scanners probing via bare-IP (no SNI)

 

Cause

This is a false positive occurring during bare-IP TLS negotiation. When a scanner probes the proxy's IP address without providing a Server Name Indication (SNI), the EdgeSWG handles the connection via a highly compatible baseline listener to establish the initial tunnel. Because legacy ciphers remain in the underlying SGOS OpenSSL layer for historical backend compatibility, the baseline listener acknowledges the handshake before policy evaluation can occur.

Resolution

The mitigation policies are active and functioning for all actual client traffic. Administrators can verify this behavior using these sequential steps:

  1. Simulate scanner traffic (no SNI) to confirm the baseline listener response: docker run -it --rm alpine:3.8 sh -c "apk add --no-cache openssl && echo 'Q' | openssl s_client -connect <Proxy_IP>:443 -cipher RC4-MD5"
  2. Simulate real web traffic (with SNI) to confirm the mitigation policy blocks the connection: docker run -it --rm alpine:3.8 sh -c "apk add --no-cache openssl && echo 'Q' | openssl s_client -connect <Proxy_IP>:443 -servername example.com -cipher RC4-MD5"
  3. Observe that the second command fails, confirming that the hardened SSL profiles are correctly protecting actual web traffic.

Additional Information

To speak with a customer representative or a Support Engineer see Contact Support. Scroll to the bottom of the page and click on your respective region.