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.
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?
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.
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?
ASKER
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
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I am on rollup 7. I will apply rollup 9, disable TLS 1.0 again and report back.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
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.
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))
Just few cents "worth"
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 guidehttps://www.ssllabs.com/downloads/SSL_Server_Rating_Guide.pdf
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.
Just few cents "worth"
ASKER
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."
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 ...
Simon.