TLS Versions 1.1 & 1.0 Protocol Deprecated
Article ID: 248030
Updated On:
Products
Issue/Introduction
In spite of TLS 1.0 and 1.1 been deprecated by the Internet Engineering Task Force (IETF) since March 25, 2021, some legacy clients, PCs, applications and origin content servers may still be using them.
While ProxySG SSL proxy does support newer platform that use TLS versions 1.2 and 1.3, it also maintains supporting said legacy platforms. This means, SSL proxy services are set to listen to SSLv3, TLSv1.0, TLSv1.1, TLSv1.2, and TLSv1.3 by default.
Environment
Edge SWG (ProxySG) SSL proxy that performs SSL decryption/encryption between the client and origin content servers.
Cause
Businesses or Administrators that already verified their environment's clients and servers support for TLSv1.2 or later could harden their proxySGs to reject (i.e., force silent deny) said legacy SSLv or TLS versions via policy. A granular configuration can also be done, depends on the actual business requirement.
Resolution
To disallow a potential legacy ssl or tls session between the client device and/or server via ProxySG, the following CPL can be implemented on your policy.
; deny client and server connections that negotiated TLSv1.1 and below
<ssl>
client.connection.negotiated_ssl_version=(SSLV3,TLSv1,TLSv1.1) force_exception(silent_denied)
<ssl>
server.connection.negotiated_ssl_version=(SSLV3,TLSv1,TLSv1.1) force_exception(silent_denied)
Use CPL such as the following examples to harden the list of cipher suites:
; deny client and server connections that negotiated a low- or medium-strength cipher
<ssl>
client.connection.negotiated_cipher.strength=(low,medium) force_exception(silent_denied)
server.connection.negotiated_cipher.strength=(low,medium) force_exception(silent_denied)
The "SSL Proxy Best Practices" documentation for further information, examples and options
Additional Information
Note: Even with the recommended CPL gestures in policy, scanners scanning the SSL proxy port might identify weak ciphers and/or vulnerable protocol versions. These false positives arise due to how the appliance handles SSL negotiations. When scanning the port, the scanner targets the appliance as if it were an origin content server (OCS). The appliance responds with a successful negotiation of the (potentially weak) cipher suite and (potentially old) SSL/TLS version—even when it intends to reject the request—in order to return the reason for the rejection to the client. In this case, no request information is ever sent to the actual OCS using a weak cipher.
The following could be helpful in evaluating supported version and/or ciphers origin content server supports when going direct or via proxy.
To test site going direct
curl -v -k --tlsv1.0 --tls-max 1.0 https://sitename.com/
curl -v -k --tlsv1.1 --tls-max 1.2 https://sitename.com/
curl -v -k --tlsv1.2 --tls-max 1.2 https://sitename.com/ --ciphers ECDHE-RSA-AES128-GCM-SHA256
or via (explicit) proxy :
curl -v -k -x http://proxy-ip:port --tlsv1.0 --tls-max 1.0 https://sitename.com/
curl -v -k -x http://proxy-ip:port --tlsv1.1 --tls-max 1.2 https://sitename.com/
curl -v -k -x http://proxy-ip:port --tlsv1.2 --tls-max 1.2 https://sitename.com/ --ciphers ECDHE-RSA-AES128-GCM-SHA256
Feedback
