Published: Thursday, August 3rd, 2017
Last Update: Thursday, October 24th, 2019
Vulnerability scans of the ACOS management interface indicate that the HTTPS service support TLS sessions using TLS 1.0 protocol which is no longer considered capable of providing a sufficient level of security TLS sessions or complying with contemporary PCI (Payment Card Industry) security standards . CVE-2011-3389 (aka BEAST attack) is a commonly referenced CVEs for this issue as the commonplace mitigation for this vulnerability is to disable TLS 1.0 support. Accordingly, the following vulnerabilities are addressed in this document.
||TLS Server Supports TLS version 1.0 
||SSL/TLS Server supports TLSv1.0 
||HTTPS: block-wise chosen-plaintext attack against SSL/TLS (BEAST) 
||TLS/SSL Server is enabling the BEAST attack 
||SSL/TLS Protocol Init Vector Implem Infor Disclosure Vuln (BEAST) 
The table below indicates releases of ACOS exposed to these vulnerabilities and ACOS releases that address these issues or are otherwise unaffected by them.
Customers using affected ACOS releases can overcome vulnerability exposures by updating to the indicated resolved release. If the table does not list a corresponding resolved or unaffected release, then no ACOS release update is currently available.
With the 2.7.2 and 2.8.2 resolved releases, the ACOS HTTPS management service additionally supports TLS 1.1 and 1.2 protocols. These releases continue to support the TLS 1.0 protocol to avoid impacting existing deployment environments with management applications dependent on this cipher.
To fully overcome vulnerability exposures associated with the TLS 1.0 protocol, the ACOS 4.1 resolved or unaffected releases are available for upgrade.
Workarounds and Mitigations
Common security best practices in the industry for network appliance management and control planes can enhance protection against remote malicious attacks. Limit the exploitable attack surface for critical, infrastructure, networking equipment through the use of access lists or firewall filters to and from only trusted, administrative networks or hosts.
The following table shares brief descriptions for the vulnerabilities addressed in this document.
The PCI (Payment Card Industry) Data Security Standard requires a minimum of TLS v1.1 and recommends TLS v1.2. In addition, FIPS 140-2 standard requires a minimum of TLS v1.1 and recommends TLS v1.2.
TLS is capable of using a multitude of ciphers (algorithms) to create the public and private key pairs.
For example if TLSv1.0 uses either the RC4 stream cipher, or a block cipher in CBC mode.
RC4 is known to have biases and the block cipher in CBC mode is vulnerable to the POODLE attack.
TLSv1.0, if configured to use the same cipher suites as SSLv3, includes a means by which a TLS implementation can downgrade the connection to SSL v3.0, thus weakening security.
A POODLE-type (https://blog.qualys.com/ssllabs/2014/12/08/poodle-bites-tls) attack could also be launched directly at TLS without negotiating a downgrade.
This QID will be marked as a Fail for PCI as of November 1st, 2016 in accordance with the new standards. For existing implementations, Merchants will be able to submit a PCI False Positive / Exception Request and provide proof of their Risk Mitigation and Migration Plan, which will result in a pass for PCI up until June 30th, 2018. Further details can be found at: NEW PCI DSS v3.2 and Migrating from SSL and Early TLS v1.1 (https://community.qualys.com/message/34120).
A vulnerability exists in SSL 3.0 and TLS 1.0 that could allow information disclosure if an attacker intercepts encrypted traffic served from an affected system.
TLS 1.1, TLS 1.2, and all cipher suites that do not use CBC mode are not affected.
This plugin tries to establish an SSL/TLS remote connection using an affected SSL version and cipher suite and then solicits return data. If returned application data is not fragmented with an empty or one-byte record, it is likely vulnerable.
OpenSSL uses empty fragments as a countermeasure unless the 'SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS' option is specified when OpenSSL is initialized.
© Copyright 2019 A10 Networks, Inc. All Rights Reserved.
This document is provided on an "AS IS" basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability, non-infringement or fitness for a particular use. Your use of the information in this document or materials linked from this document is at your own risk. A10 Networks, Inc. reserves the right to change or update the information in this document at any time.