Question in regards to SSL and TLS

vmich used Ask the Experts™
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:
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...
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Russ SuterSenior Software Developer

This is in response to the POODLE vulnerability. (

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 BrownSenior Systems Admin
Top Expert 2010

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. 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.
Exec Consultant
Distinguished Expert 2018
Suggest keeping TLS 1.0 and disable sslv3.0 and below. Ms advices states so as as it may affect exchange
One piece of guidance we are aware of suggests taking steps to prepare to disable TLS 1.0 in summer of 2016. Another piece of guidance suggests that TLS 1.0 should not be used with internal-only applications (we do not believe that Exchange is typically used in this manner, as it connects to the outside world via SMTP). While we believe the intentions of both proposals are good and will promote adoption of TLS 1.1 & 1.2, at this time, we do not yet recommend disabling TLS 1.0 on your Exchange Server(s).

Additionally, while TLS 1.1 & 1.2 are superior to TLS 1.0, the real world risks may be somewhat overstated at this point due to mitigations that have been taken across the industry. Of course, security is rarely a binary decision: disabling TLS 1.0 doesn’t suddenly turn something insecure into something secure. That said, we will continue to work towards the goal of making TLS 1.1 & 1.2 work fully with Exchange and a broad array of clients.
Though enabling support for TLS v1.1 and v1.2 are highly recommended. But leaving TLS 1.0 enabled is a good thing for now but do test it out in your staging environment. Note that clients and applications should always prefer the most secure option, provided that Windows, the application, and the client all support it.  
The current recommendations, which will continue evolving, are as follows:

Deploy supported operating systems, clients, browsers, and Exchange versions
Test everything by disabling SSL 3.0 on Internet Explorer
Disable support for SSL 3.0 on the client
Disable support for SSL 3.0 on the server
Prioritize TLS 1.2 ciphers, and AES/3DES above others
Strongly consider disabling RC4 ciphers
Do NOT use MD5/MD2 certificate hashing anywhere in the chain
Use RSA-2048 when creating new certificate keys
When renewing or creating new requests, request SHA 256-bit or better
Know what your version of Exchange supports
Use tools to test and verify
Do NOT get confused by explicit TLS vs. implicit TLS
(For now) Wait to disable TLS 1.0 on the Exchange server
Adam BrownSenior Systems Admin
Top Expert 2010

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.
btanExec Consultant
Distinguished Expert 2018

Thanks for sharing - I do err on safe side not to break the user operations hence will maintain tls1.0 minimally
Russ SuterSenior Software Developer
If the security audit is merely an exercise to shore up defenses then I would agree that leaving tls 1.0 enabled is probably OK and may be prudent. However, in certain industries such as the credit card industry and healthcare industry these vulnerabilities cannot be tolerated. A healthcare provider or credit card processor would fail an audit if they left these protocols open.

As with any security measure it's a balance between security and convenience. As we aren't privy to the full details it's ultimately up to you to make the determination as to whether the risk of leaving vulnerable protocols makes good business sense.

Disclaimer: That previous sentence sounds a bit doomsday. The reality is that the Poodle vulnerability is not as easy to exploit as something like Heartbleed. It requires a bit of work.

OK, so having said all that. I'd suggest you conduct an informal risk assessment. (Although if this is for a PCI audit it will need to be a formal one). Consider all of the following questions:

1. Is patching this vulnerability vital to the continued operation of our business? (i.e. does a successful audit depend on patching this?)
2. What is the likelihood that our business is a target? Let's face it, has a bigger target on its back than
3. What is the probability of a successful attack? (This one is hard to answer quantitatively)
4. If not fully patched, does a method exist of detecting an attack so services can be shut down rapidly if needed?
5. If we are attacked, what is our exposure? Consider:
    A. Service downtime
    B. Data compromise
    C. Data loss
    D. Loss of consumer confidence or reputation
btanExec Consultant
Distinguished Expert 2018

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


Keep TLS1 enabled

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial