Solved

Question in regards to SSL and TLS

Posted on 2016-08-11
8
112 Views
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:
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...
0
Comment
Question by:vmich
  • 3
  • 2
  • 2
  • +1
8 Comments
 
LVL 20

Expert Comment

by:Russ Suter
Comment Utility
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.
0
 
LVL 38

Expert Comment

by:Adam Brown
Comment Utility
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.
0
 
LVL 61

Accepted Solution

by:
btan earned 250 total points
Comment Utility
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
https://blogs.technet.microsoft.com/exchange/2015/07/27/exchange-tls-ssl-best-practices/
0
 
LVL 38

Expert Comment

by:Adam Brown
Comment Utility
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.
0
Are your corporate email signatures appalling?

Is it scary how unprofessional your email signatures look? Do users create their own terrible designs and give themselves stupid job titles? You can make this a lot easier for yourself by choosing an email signature management solution from Exclaimer today.

 
LVL 61

Expert Comment

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

Assisted Solution

by:Russ Suter
Russ Suter earned 250 total points
Comment Utility
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
0
 
LVL 61

Expert Comment

by:btan
Comment Utility
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
0
 

Author Closing Comment

by:vmich
Comment Utility
Keep TLS1 enabled
0

Featured Post

How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

Join & Write a Comment

Disabling the Directory Sync Service Account in Office 365 will stop directory synchronization from working.
This process describes the steps required to Import and Export data from and to .pst files using Exchange 2010. We can use these steps to export data from a user to a .pst file, import data back to the same or a different user, or even import data t…
To show how to create a transport rule in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Mail Flow >> Rules tab.:  To cr…
To add imagery to an HTML email signature, you have two options available to you. You can either add a logo/image by embedding it directly into the signature or hosting it externally and linking to it. The vast majority of email clients display l…

743 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

Need Help in Real-Time?

Connect with top rated Experts

14 Experts available now in Live!

Get 1:1 Help Now