We ran a security report on our network and it came back with 4 servers which it said had sev 3 vulnerabilities which to fix this was to disable the following:
ssl2
ssl3
tls v1
It said to then enable TLS v1.2 only
Of these servers, one is exchange, 1 is Citirx, and the other is a web server.
My question is, what will break if we do follow this and disable all 3 that it suggested to...
Basically these methods of securing communication are vulnerable to a potential exploit. TLS 1.2 is not vulnerable.
In most cases you'll be OK disabling the lesser protocols. The issue comes in if you have a client that doesn't support TLS 1.2 security. In that case it will be looking for a lower security protocol that you've now disabled and will be unable to communicate at all.
Modern clients that connect to Exchange servers shouldn't have an issue. Web servers are also fine unless someone is trying to connect using a very old browser. I'm not certain about Citrix systems but they're probably OK also.
I've been through exactly this exercise a couple of times before. The best approach is to document your changes and make sure they're reversible in case of emergency. However I've never run into trouble disabling them.
Adam Brown
As long as you are not using Outlook 2003 or Windows XP (or possibly Vista), you should not have any issues with client connectivity on those servers. All web browsers for the past several years and all versions of windows (including Remote Desktop Client and Citrix clients) support TLS1.2.
However, you should make sure that the Certificate installed on these servers is able to support TLS 1.2 encryption. https://www.entrust.com/moving-tls-1-2/ can tell you if the certificate in use supports TLS 1.2 implementation. Generally, Public CAs have been generating certificates that support TLS 1.2 for several years, but some CAs have been slow on the uptake, so you'll want to test any certificates that are on the Internet.
Thanks for the link btan. Makes a lot of sense. I completely forgot about Opportunistic TLS issues :D Considering the number of mail servers that haven't implemented support for opportunistic TLS yet (I mindbogglingly large number), the likelihood that mailflow would be impacted by disabling tls 1.0 is high on Exchange.
For PCI-DSS or HIPPA compliance sake, TLS1.0 will need deviation and from experience, it can still be acceptable provided the mitigation measures and risk acceptance is concurred by System owner. The severity based on CVSS scored (like btw 7-10 for severe & critical) vulnerability may help to make an informed decision as user tend to go for safer means to patch rather than be exposed to such severe case for internet accessible system. As a whole, it is about risk measured approach to reduce as much as exposure on the hole to be exploited while service can still be running. For known exploits, as long as it doesnt break, the general sense is to close or disable those slew of SSL related vulnerability like Poodle, Heartbleed, BEAST, SSL renegotiation, CRIME etc
Basically these methods of securing communication are vulnerable to a potential exploit. TLS 1.2 is not vulnerable.
In most cases you'll be OK disabling the lesser protocols. The issue comes in if you have a client that doesn't support TLS 1.2 security. In that case it will be looking for a lower security protocol that you've now disabled and will be unable to communicate at all.
Modern clients that connect to Exchange servers shouldn't have an issue. Web servers are also fine unless someone is trying to connect using a very old browser. I'm not certain about Citrix systems but they're probably OK also.
I've been through exactly this exercise a couple of times before. The best approach is to document your changes and make sure they're reversible in case of emergency. However I've never run into trouble disabling them.