01-13-2017 01:14 AM
SSL/TLS Compression Algorithm Information Leakage Vulnerability
SSL/TLS use of weak RC4 cipher
SSL/TLS Server supports TLSv1.0
SSLv3.0/TLSv1.0 Protocol Weak CBC Mode Server Side Vulnerability (BEAST)
SSL/TLS Compression Algorithm Information Leakage Vulnerability
SSL/TLS use of weak RC4 cipher
What version we need to upgrade to our ESA?
Solved! Go to Solution.
01-13-2017 05:37 AM
Hi John,
Below is some information I found on the mentioned vulnerabilities.
***************************************************************************************************************
# Qualys Scan: SSLv3.0/TLSv1.0 Protocol Weak CBC Mode Server Side Vulnerability (BEAST) .
CVE-2011-3389
Solution:
This attack was identified in 2004 and later revisions of TLS protocol which contain a fix for this. If possible, upgrade to TLSv1.1 or TLSv1.2. If upgrading to TLSv1.1 or TLSv1.2 is not possible, then disabling CBC mode ciphers will remove the vulnerability.
Setting your SSL server to prioritize RC4 ciphers mitigates this vulnerability. Microsoft has posted information including workarounds for IIS at <a href="http://technet.microsoft.com/en-us/security/advisory/2588513" target="_blank" rel="nofollow">KB2588513</a>.
Using the following SSL configuration in Apache mitigates this vulnerability:
SSLHonorCipherOrder On
SSLCipherSuite RC4-SHA:HIGH:!ADH
***************************************************************************************************************
# Qualys Scan: SSL/TLS use of weak RC4 cipher
CVE-2013-2566,CVE-2015-2808
Solution:
RC4 should not be used where possible. One reason that RC4 was still being used was BEAST and Lucky13 attacks against CBC mode ciphers in SSL and TLS. However, TLSv 1.2 or later address these issues.
***************************************************************************************************************
# SSL/TLS Compression Algorithm Information Leakage Vulnerability
[ESA] CRIME Vulnerability (CVE-2012-4929)
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCum72269
Workaround:
The CRIME vulnerability can only be exploited if both the server and web browser both support TLS compression.
All version of Internet Explorer, Safari, Opera are not vulnerable because TLS compression is not supported on any version. All versions of Chrome and Firefox released after 2012 have been patched for this exploit.
All major updated web browsers disable compression for TLS connections. To avoid any potential exposure to this vulnerability, please ensure that your browser does not support TLS compression.
I just looked more into this and this defect is not being worked on because the development evaluation states that this does not affect ESA because we're not using TLS compression or SPDY/HTTP2 protocols.
So if this a concern for the customer please have them open a TAC Support cases and have them provide the corresponding information from the scanning system.
***************************************************************************************************************
# SSL/TLS Server supports TLSv1.0
If there is a certain vulnerability with ciphers used by TLS 1.0 then you could disable usage of that cipher as explained in the below article.
http://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118518-technote-esa-00.html
However do note, I expect you will see a significant drop off in TLS connectivity as not everything supports TLS 1.2 only. Lots of MTA on the peer side may only speak TLS1.0 or even lower cipher suites. This will cause TLS handshake failure.
If the TLS negotiation has started and then failed due to cipher, then the SMTP transaction does not fall back to clear text.
Preferred - When this option is chosen, TLS can negotiate from the remote MTA to the ESA. However, if the remote MTA does not negotiate (prior to the reception of a 220 response), the SMTP transaction continues in the clear (not encrypted). If an error occurs after the 220 response is received, then the SMTP transaction does not fall back to clear text.
As you are looking to prevent usage of TLS v1.0 disabling SSLv3 ciphers used by TLS 1.0 should be enough, TLS v1.2 has its own set of ciphers which would then be used.
SSLv3 ciphers can be removed by adding -SSLv3 or !SSLv3 to the existing cipher string.
Also with TLSv1 and TLSv1.2 both active the device would always try TLSv1.2 first. TLSv1 is not listed separately and disabled completely as it is still in use globally
***************************************************************************************************************
TLS v1.2 is available in Async OS 9.5 and higher.
TLS v1.1 was recently introduced as a configurable option in Async OS 10.0.1 (Maintenance Deployment)
Please review all release notes below:
http://www.cisco.com/c/en/us/support/security/email-security-appliance/products-release-notes-list.html
I would certainly recommend upgrade to 9.5 or above.
Thanks!
Libin Varghese
01-13-2017 08:09 AM
John,
After you upgrade you'll want to go look at the SSL/TLS cipher settings to make sure you don't still have weak ciphers enabled. Upgrades don't always change the cipher strings.
I'd go all the way to 10.0.1.-087, now you can enable/disable each TLS version separately, but at least to 9.6...
In newer builds, the config is under System Administration/SSL configuration... I don't remember where it is in older builds, but even there you can set your string to turn off weak stuff, and close some holes.
Here's what I'm currently using:
MEDIUM:HIGH:!RC4:!aNULL:!MD5:!DSS:!EXPORT:@STRENGTH
based on this document: http://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/117855-technote-esa-00.html
Ken
01-13-2017 05:37 AM
Hi John,
Below is some information I found on the mentioned vulnerabilities.
***************************************************************************************************************
# Qualys Scan: SSLv3.0/TLSv1.0 Protocol Weak CBC Mode Server Side Vulnerability (BEAST) .
CVE-2011-3389
Solution:
This attack was identified in 2004 and later revisions of TLS protocol which contain a fix for this. If possible, upgrade to TLSv1.1 or TLSv1.2. If upgrading to TLSv1.1 or TLSv1.2 is not possible, then disabling CBC mode ciphers will remove the vulnerability.
Setting your SSL server to prioritize RC4 ciphers mitigates this vulnerability. Microsoft has posted information including workarounds for IIS at <a href="http://technet.microsoft.com/en-us/security/advisory/2588513" target="_blank" rel="nofollow">KB2588513</a>.
Using the following SSL configuration in Apache mitigates this vulnerability:
SSLHonorCipherOrder On
SSLCipherSuite RC4-SHA:HIGH:!ADH
***************************************************************************************************************
# Qualys Scan: SSL/TLS use of weak RC4 cipher
CVE-2013-2566,CVE-2015-2808
Solution:
RC4 should not be used where possible. One reason that RC4 was still being used was BEAST and Lucky13 attacks against CBC mode ciphers in SSL and TLS. However, TLSv 1.2 or later address these issues.
***************************************************************************************************************
# SSL/TLS Compression Algorithm Information Leakage Vulnerability
[ESA] CRIME Vulnerability (CVE-2012-4929)
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCum72269
Workaround:
The CRIME vulnerability can only be exploited if both the server and web browser both support TLS compression.
All version of Internet Explorer, Safari, Opera are not vulnerable because TLS compression is not supported on any version. All versions of Chrome and Firefox released after 2012 have been patched for this exploit.
All major updated web browsers disable compression for TLS connections. To avoid any potential exposure to this vulnerability, please ensure that your browser does not support TLS compression.
I just looked more into this and this defect is not being worked on because the development evaluation states that this does not affect ESA because we're not using TLS compression or SPDY/HTTP2 protocols.
So if this a concern for the customer please have them open a TAC Support cases and have them provide the corresponding information from the scanning system.
***************************************************************************************************************
# SSL/TLS Server supports TLSv1.0
If there is a certain vulnerability with ciphers used by TLS 1.0 then you could disable usage of that cipher as explained in the below article.
http://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118518-technote-esa-00.html
However do note, I expect you will see a significant drop off in TLS connectivity as not everything supports TLS 1.2 only. Lots of MTA on the peer side may only speak TLS1.0 or even lower cipher suites. This will cause TLS handshake failure.
If the TLS negotiation has started and then failed due to cipher, then the SMTP transaction does not fall back to clear text.
Preferred - When this option is chosen, TLS can negotiate from the remote MTA to the ESA. However, if the remote MTA does not negotiate (prior to the reception of a 220 response), the SMTP transaction continues in the clear (not encrypted). If an error occurs after the 220 response is received, then the SMTP transaction does not fall back to clear text.
As you are looking to prevent usage of TLS v1.0 disabling SSLv3 ciphers used by TLS 1.0 should be enough, TLS v1.2 has its own set of ciphers which would then be used.
SSLv3 ciphers can be removed by adding -SSLv3 or !SSLv3 to the existing cipher string.
Also with TLSv1 and TLSv1.2 both active the device would always try TLSv1.2 first. TLSv1 is not listed separately and disabled completely as it is still in use globally
***************************************************************************************************************
TLS v1.2 is available in Async OS 9.5 and higher.
TLS v1.1 was recently introduced as a configurable option in Async OS 10.0.1 (Maintenance Deployment)
Please review all release notes below:
http://www.cisco.com/c/en/us/support/security/email-security-appliance/products-release-notes-list.html
I would certainly recommend upgrade to 9.5 or above.
Thanks!
Libin Varghese
01-13-2017 08:09 AM
John,
After you upgrade you'll want to go look at the SSL/TLS cipher settings to make sure you don't still have weak ciphers enabled. Upgrades don't always change the cipher strings.
I'd go all the way to 10.0.1.-087, now you can enable/disable each TLS version separately, but at least to 9.6...
In newer builds, the config is under System Administration/SSL configuration... I don't remember where it is in older builds, but even there you can set your string to turn off weak stuff, and close some holes.
Here's what I'm currently using:
MEDIUM:HIGH:!RC4:!aNULL:!MD5:!DSS:!EXPORT:@STRENGTH
based on this document: http://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/117855-technote-esa-00.html
Ken
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide