11-24-2016 05:02 AM
Hello,
For security reason one of our client want to disable TLS 1.0 on ironport and force only TLS 1.1 or 1.2
Our Async Version : 9.7.0
Is it possible ?
Kr,
Vincent.
Solved! Go to Solution.
11-24-2016 05:33 AM
Hi Vincent,
With the vulnerabilities in SSL, TLS is commonly used for communication by a lot of MTA’s. TLS 1.2 is available after upgrade to Async OS 9.6 and above. 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.
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.
Thanks
Libin Varghese
11-24-2016 05:33 AM
Hi Vincent,
With the vulnerabilities in SSL, TLS is commonly used for communication by a lot of MTA’s. TLS 1.2 is available after upgrade to Async OS 9.6 and above. 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.
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.
Thanks
Libin Varghese
08-22-2017 09:09 PM
08-23-2017 12:45 AM
I would recommend posting this query under support forums available for NAC so that someone with knowledge on that can answer your query.
I do not suppose they would have an eye on the email security support forums.
- Libin V
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