Question in regards to SSL and TLS

Posted on 2016-08-11
Medium Priority
Last Modified: 2016-08-15
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...
Question by:vmich
  • 3
  • 2
  • 2
  • +1
LVL 20

Expert Comment

by:Russ Suter
ID: 41752738
This is in response to the POODLE vulnerability. (https://poodle.io/)

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.
LVL 44

Expert Comment

by:Adam Brown
ID: 41752783
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.
LVL 66

Accepted Solution

btan earned 1000 total points
ID: 41753227
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
Will You Be GDPR Compliant by 5/28/2018?

GDPR? That's a regulation for the European Union. But, if you collect data from customers or employees within the EU, then you need to know about GDPR and make sure your organization is compliant by May 2018. Check out our preparation checklist to make sure you're on track today!

LVL 44

Expert Comment

by:Adam Brown
ID: 41753250
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.
LVL 66

Expert Comment

ID: 41753373
Thanks for sharing - I do err on safe side not to break the user operations hence will maintain tls1.0 minimally
LVL 20

Assisted Solution

by:Russ Suter
Russ Suter earned 1000 total points
ID: 41753978
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, google.com has a bigger target on its back than momandpopflowers.com.
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
LVL 66

Expert Comment

ID: 41754038
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

Author Closing Comment

ID: 41756446
Keep TLS1 enabled

Featured Post

[Webinar] Improve your customer journey

A positive customer journey is important in attracting and retaining business. To improve this experience, you can use Google Maps APIs to increase checkout conversions, boost user engagement, and optimize order fulfillment. Learn how in this webinar presented by Dito.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This article describes Top 9 Exchange troubleshooting utilities that every Exchange Administrator should know. Most of the utilities are available free of cost. List of tools that I am going to explain in this article are:   Microsoft Remote Con…
In this article, I will demonstrate that how to do a PST migration from Exchange Server to Office 365. This method allows importing one single PST, or multiple PST's at once.
In this Micro Video tutorial you will learn the basics about Database Availability Groups and How to configure one using a live Exchange Server Environment. The video tutorial explains the basics of the Exchange server Database Availability grou…
This video shows how to quickly and easily deploy an email signature for all users in Office 365 and prevent it from being added to replies and forwards. (the resulting signature is applied on the server level in Exchange Online) The email signat…
Suggested Courses

600 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question