Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17

x
?
Solved

Question in regards to SSL and TLS

Posted on 2016-08-11
8
Medium Priority
?
413 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
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 2
  • 2
  • +1
8 Comments
 
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.
0
 
LVL 42

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.
0
 
LVL 65

Accepted Solution

by:
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
https://blogs.technet.microsoft.com/exchange/2015/07/27/exchange-tls-ssl-best-practices/
0
Survive A High-Traffic Event with Percona

Your application or website rely on your database to deliver information about products and services to your customers. You can’t afford to have your database lose performance, lose availability or become unresponsive – even for just a few minutes.

 
LVL 42

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.
0
 
LVL 65

Expert Comment

by:btan
ID: 41753373
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 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
0
 
LVL 65

Expert Comment

by:btan
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
0
 
LVL 1

Author Closing Comment

by:vmich
ID: 41756446
Keep TLS1 enabled
0

Featured Post

Enterprise Mobility and BYOD For Dummies

Like “For Dummies” books, you can read this in whatever order you choose and learn about mobility and BYOD; and how to put a competitive mobile infrastructure in place. Developed for SMBs and large enterprises alike, you will find helpful use cases, planning, and implementation.

Question has a verified solution.

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

Know the reasons and solutions to move/import EDB to New Exchange Server. Also, find out how to recover an Exchange .edb file and to restore the file back.
The core idea of this article is to make you acquainted with the best way in which you can export Exchange mailbox to PST format.
In this video we show how to create an email address policy 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…
There are cases when e.g. an IT administrator wants to have full access and view into selected mailboxes on Exchange server, directly from his own email account in Outlook or Outlook Web Access. This proves useful when for example administrator want…

661 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