Can't pass PCI with TLS 1.0 enabled

I am having a problem passing PCI compliance scans from Trustwave.  What is failing is having TLS 1.0 enabled on our Exchange 2010 server which is on Windows Server 2008R2.  I downloaded IIS Crypto to help with this and it helped me disable SSL 2.0, 3.0 and PCT 1.0 so I was able to at least get that far.  Now I am left with just TLS 1.0 failing me.

If I disabled TLS 1.0 I could no longer RDP to the server and the Android and iPhone phones were not able to communicate with the Exchange Server.  If I re-enable TLS again, things return to normal with RDP and phones.  I figured out how to use RDP with TLS1 disabled by changing the properties of  RDP-TCP to use RDP security layer rather than SSL (TLS 1.0).  I still can't get phones to work with Exchange with TLSv1 disabled so I have had to leave it.

What is causing Android and iPhones to quit working when TLS 1.0 is disabled?

The attachment shows what Trustwave is finding enabled with TLS 1.0.
failing evidence found
Even though I have supplied Trustwave with documentation showing that the two computers processing credit cards are isolated from the Exchange server with a dedicated firewall, they deny my dispute and I am left with a single thing holding me back from being certified.  Frustrating.

Is there a way I can tweak my system to work with phones on the Exchange Server with TLS 1.0 disabled?
LVL 1
Steve BantzIT ManagerAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Simon Butler (Sembee)ConsultantCommented:
The important question is have you enabled TLS 1.1 and 1.2? If not, then that is probably your problem. You need to have TLS enabled of some description, it is just TLS 1.0 that is the problem with these automated dumb tests.

Simon.
0
Steve BantzIT ManagerAuthor Commented:
Yes, I do have TLS 1.1 and 1.2 enabled.  If I uncheck TLS 1.0 in IIS Crypto to disable it, I leave 1.1 and 1.2 enabled.  After a reboot to finalize the changes, that's when the problem occurs.  The Android and IPhones are all less than a year old and running the latest revision on their respective OS so  I can't imagine they rely on TLS 1.0.  I feel like I am missing something somewhere else, like telling Exchange ActiveSync to use > TLS 1.0

TLS config
0
Simon Butler (Sembee)ConsultantCommented:
Are you on Exchange 2010 SP3 rollup 9?
I haven't had to do this on any of my sites, but it seems there is still some hardcoded TLS 1.0 references within Exchange. There is a lengthy thread on Spiceworks where someone has called Microsoft to verify.

If the product doesn't have a fix, then the auditors will have to accept that. You cannot fix the product.

Simon.
1
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Steve BantzIT ManagerAuthor Commented:
I am on rollup 7.  I will apply rollup 9, disable TLS 1.0 again and report back.
0
btanExec ConsultantCommented:
However, for tls1.0, the forum already flagged your similar experience
Microsoft noted in KB 3045301 https://support.microsoft.com/en-us/kb/3045301 that Simple mail transfer protocol (SMTP) uses transport layer security (TLS) 1.0 in a Microsoft Exchange Server 2013 environment, even if you have enabled TLS 1.1 or TLS 1.2 because of a hard-coded restriction that limits SMTP to use secure sockets layer (SSL) 3.0 and TLS 1.0 for transport.Exchange CU8 fixes this. HOWEVER, we still cannot get Exchange 2013 CU8 to work after disabling SSL v3 and TLS v1.0 (on Server 2012)....the production system (which has a valid CA cert) will not connect any way if I disable SSL 3.0 and/or TLS 1.0. It also shows the blank page behavior in OWA and ECP from "inside".
https://social.technet.microsoft.com/Forums/en-US/8815dada-94b5-4d89-ad80-43f03705c551/support-for-tls-12-over-exchange-2013-on-server-2012?forum=exchangesvrsecuremessaging

You will need to enabled tls 1.0 at server since it is not mentioned to have work out for many .. and I suspect it is not supported too. At least from this TLS 1.0 is not suggested to be disabled.
https://technet.microsoft.com/en-us/library/security/3009008.aspx

Sidenote - But I do know the aspect that RC4 is considered weak and should be disabled. This may be used in client
http://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4.aspx
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Steve BantzIT ManagerAuthor Commented:
Thanks for the links.  PCI compliance sure is a headache when they say you can't do this and that yet there is no workaround or fix even with Microsoft products that are still active and supported.  I can't believe Trustwave will not make an exception to this given that the two machines I have that use an Internet Explorer based payment gateway (they do NOT store any info) are behind a firewall and on their own protected network.  The Exchange server cannot access the machines.  I am seriously thinking of seeking out a different PCI compliance service that doesn't take a week to respond to scan disputes.

I did use IISCrypto to disable weak ciphers and ssl 2/3 using their built in PCI template and was able to clean things up so that TLSv1 is all that fails me.

I tried the rollup 9 and that didn't work either.  Once I disabled TLS1, OWA and ActiveSync stopped working for phones again.  I enabled it again and punted.

I guess I will have to plead my case further with Trustwave.  I really can't recommend this company to anyone since it takes several days to even get a response from them about a dispute. When you answer with proof of compensating controls it takes several more days for them to actually look at it and deny it for no specified reason.
0
btanExec ConsultantCommented:
SSLtest will not want to set lower threshold as a whole to give that false sense of security, but to business running is it not going to be friendly esp compliance is a major factor (it should not be actually ...but that is left for another debate). They will just go higher and fault more pt away to meet that passing mark for site tested - eventually owner assess risk and accept it as business cannot afford downtime and such repeating "fix-and-patch-fail" experience.

Go for the exception, TLS1.0 is not totally as bad and even TLS1.2 can be flawed if you heard on the recent LogJam and FREAK whereby DH_EXPORT and RSA-EXPORT Keys is using weak key...we just saying mitigation is to have layer defences and disable the weak cipher and unnecessary to reduce overall exposure for exploit. So far, yet to heard anyone disabling TLS1.0 and got Exchange to work smoothly - it is the crypto and not the service that is flawed per se...but if hardcoded, nothing we can do in registry can revert or override that preference...at least maybe re-order to have tls1.2 at higher which IISCrypto is capable of doing even with tls1.0 enabled. I don't think it fares so bad to be fail ..just not a good score. We shouldnt be overall compliance blind lead - risk assessed decision is more a fit for design security strategy.

SSLtest criteria (as of writing - version 2009j (20 May 2015))
Table 3. Protocol support rating guide
Protocol Score
SSL 2.0 0%
SSL 3.0 80%
TLS 1.0 90%
TLS 1.1 95%
TLS 1.2 100%

Changes in 2009h (30 October 2014)
• Don’t award A+ to servers that don’t support TLS_FALLBACK_SCSV.
• Cap to B if SSL 3 is supported.

Changes in 2009i (8 December 2014)
• Cap to B if RC4 is supported.
• Cap to B if the chain is incomplete.
• Fail servers that have SSL3 as their best protocol.

Changes in 2009j (20 May 2015)
• Cap to B if using weak DH parameters (less than 2048 bits).
• Increase CRIME penalty to C (was B).
• Cap to C if RC4 is used with TLS 1.1+.
• Cap to C if not supporting TLS 1.2.
https://www.ssllabs.com/downloads/SSL_Server_Rating_Guide.pdf

Just few cents "worth"
0
Steve BantzIT ManagerAuthor Commented:
I agree and I am not looking for a false sense of security.  :)  If the latest iterations of Microsoft products can't allow you to pass a PCI scan, what can you do?  I have a rock solid compensating control in place yet still can't pass.  I guess I am just more frustrated that my compensating control fails me.  I always assume Microsoft products will be the first roadblock in being "secure."
0
btanExec ConsultantCommented:
They supposed to be...for all their deliverable ... and stay consistent.. i do preach the reviewer to also be more open and till now SSLtest seems to be more comprehensive though (many rely on that assessment). Min confidentiality is maintained compared to nil. Otherwise has a load balancer or web proxy to front the virtual front - but then it is "false" virtual patch till someone work out a good means of code ...
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2008

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.