PCI-DSS Compliance fails, after running Plesk PCI scripts.

[J.Wick]

Running Plesk 12 on Centos 7 with Apache 2.4.6 and I'm not able to disable TLS v1. I've looked everywhere reading countless pages and it seems like all the Plesk PCI documentation and scripts for hardening need to be upgraded to excluded SSLv2 SSLv3 and TLS v1. I even modified the SSLFix.sh file by removing TLSv1 and ran it again, still no go.

Can someone please tell me how to properly disable TLS v1 and just have TLS v1.1 and 1.2 enabled?

Trustwave.com is my PCI-DSS scanner that is reporting the failure.

BTW: Tried following this http://kb.odin.com/en/120083 no affect.

 

[J.Wick]

BTW: My ssl.conf

SSLHonorCipherOrder  On
SSLProtocol -all +TLSv1.1 +TLSv1.2
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS;

 

[J.Wick]

Reasons why this is important.

https://www.pcisecuritystandards.or...m_SSL_Early_TLS_Information Supplement_v1.pdf

 

[TomBoB]

Hi,

as someone on this forum suggested in another thread (don't have link at hand right now), use the structure
SSLProtocol +TLSv1.1 +TLSv1.2 -SSLv2 -SSLv3 -TLSv1
instead of
SSLProtocol -all +TLSv1.1 +TLSv1.2

haven't got the explanation of the fine but important difference at hand either [try to find other thread]; but made all the difference on our servers.
Cipher suite selection obviously also important.

Hope it's a stepping stone in the right direction.

Tom

 

[J.Wick]

Hi,

as someone on this forum suggested in another thread (don't have link at hand right now), use the structure
SSLProtocol +TLSv1.1 +TLSv1.2 -SSLv2 -SSLv3 -TLSv1
instead of
SSLProtocol -all +TLSv1.1 +TLSv1.2

haven't got the explanation of the fine but important difference at hand either [try to find other thread]; but made all the difference on our servers.
Cipher suite selection obviously also important.

Hope it's a stepping stone in the right direction.

Tom

Hi Tom,

Thanks for the suggestion. I tried it and still end up with TLSv1 somehow still enabled. I'm wondering if this is a bug.

 

[UFHH01]

Hi SpyderZ,

Cipher suite selection obviously also important.

Please consider to use a more detailed ciphers list, in order to reach your goal. And "no"... it's not a bug.

Hint: consider using "intermediate" as a keyword at the forum SEARCH, to find related threads to a more detailed ciphers list and you will find as well suggestions, how to check the ciphers and you will find explanations and informations to it here in forums.

 

[J.Wick]

Hi SpyderZ,


Please consider to use a more detailed ciphers list, in order to reach your goal. And "no"... it's not a bug.

Hint: consider using "intermediate" as a keyword at the forum SEARCH, to find related threads to a more detailed ciphers list and you will find as well suggestions, how to check the ciphers and you will find explanations and informations to it here in forums.

Oh, I have searched hard on this one, I have about 5 hours into it. Made a lot of notes, found and even installed new CLI commands to show the supported cipher for a domain, and SSLLabs.com SSL scanner is really good. I'm getting an A+ there, yet Trustwave is having a fit with TLSv1 support being available, along with RC4.

Would be nice to have a clear Odin Knowledge Base article on how to setup servers to pass Trustwave PCI-DSS, and maybe another version of the handy SSLFix.sh script.

 

[TomBoB]

just something that caught my eye: you show us the config in your ssl.conf

Excuse me if I'm wrong - still on a learning curve - but in our setup, we left the ssl.conf well alone

## SSL Engine Switch:
## Enable/Disable SSL for this virtual host.
#SSLEngine on
#
## SSL Protocol support:
## List the enable protocol levels with which clients will be able to
## connect. Disable SSLv2 access by default:
SSLProtocol All -SSLv2 -SSLv3
#
## SSL Cipher Suite:
## List the ciphers that the client is permitted to negotiate.
## See the mod_ssl documentation for a complete list.
SSLCipherSuite ECDH+AESGCMH+AESGCM:ECDH+AES256H+AES256:ECDH+AES128H+AES:ECDH+3DESH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
#
## Speed-optimized SSL Cipher configuration:
## If speed is your main concern (on busy HTTPS servers e.g.),
## you might want to force clients to specific, performance
## optimized ciphers. In this case, prepend those ciphers
## to the SSLCipherSuite list, and enable SSLHonorCipherOrder.
## Caveat: by giving precedence to RC4-SHA and AES128-SHA
## (as in the example below), most connections will no longer
## have perfect forward secrecy - if the server's key is
## compromised, captures of past or future traffic must be
## considered compromised, too.
##SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5
SSLHonorCipherOrder on
#

but configured SSL/TLS via the httpd.conf
[which might explain why you have disabled TLS1 but it's still there being offered - it might be in the httpd.conf]

our config in httpd.conf (don't go for PCI compl):

SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2 -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384HE-RSA-AES128-GCM-SHA256HE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHAHE-RSA-AES128-SHA256HE-RSA-AES128-SHAHE-DSS-AES128-SHA256HE-RSA-AES256-SHA256HE-DSS-AES256-SHAHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIAES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

fellow forum contributor UFHH01 would be the person to ask if other threads don't get you anywhere...

 

[J.Wick]

just something that caught my eye: you show us the config in your ssl.conf

Excuse me if I'm wrong - still on a learning curve - but in our setup, we left the ssl.conf well alone



but configured SSL/TLS via the httpd.conf
[which might explain why you have disabled TLS1 but it's still there being offered - it might be in the httpd.conf]

our config in httpd.conf (don't go for PCI compl):



fellow forum contributor UFHH01 would be the person to ask if other threads don't get you anywhere...

Hi Tom,

From the looks of your config, it would seem that TLSv1 is also enabled, easily found out over at https://www.ssllabs.com/ssltest/

 

[UFHH01]

Hi SpyderZ,

yes indeed, he allows "TLSv1" and there is nothing wrong about it. There are an enormous lot of old browsers and apps, which use "TLSv1" connections ( about 35-40 %, according to actual global internet statistics ). If Trustwave wants that to be cut off, just fill in the "PCI 3.1 Risk Plan" ( https://www.trustwave.com/Resources/Library/Documents/PCI-3-1-Risk-Plan-Template/ ) and describe, that your buisness is not able to give up "TLSv1" connections at the moment. They will allow such exceptions requests, if all other requirements are met.

Another reason, why using "TLSv1" should be still allowed: Windows XP, Windows Vista or Windows Server 2003 doesn't support "TLSv1.1" and "TLSv1.2". Please use Google and make a research, how many users might not be able to visit your domain, if you resist on not using "TLSv1".

You have until June 2016 to fully migrate to TLS 1.1/1.2. In the meantime, you will need to provide a remediation plan for services that are still using SSLv3 or TLSv1.0.

Edit: In addition, did you know, that GMail uses "Elliptic curve cipher SSLv3" ciphers ( ECDHE-RSA-AES128-SHA ) ? Another reason, why someone should again investigate, which ciphers list he/she forbids, when only using short restrictions like "-SSLv2 -SSLv3", without a special defined ciphers list in your configuration files. Not all "SSLv3" ciphers for example are vulnerable, so you definetely should use a more detailed ciphers list, instead of just restriction the usage completely.

 

[J.Wick]

Hi SpyderZ,

yes indeed, he allows "TLSv1" and there is nothing wrong about it. There are an enormous lot of old browsers and apps, which use "TLSv1" connections ( about 35-40 %, according to actual global internet statistics ). If Trustwave wants that to be cut off, just fill in the "PCI 3.1 Risk Plan" ( https://www.trustwave.com/Resources/Library/Documents/PCI-3-1-Risk-Plan-Template/ ) and describe, that your buisness is not able to give up "TLSv1" connections at the moment. They will allow such exceptions requests, if all other requirements are met.

Another reason, why using "TLSv1" should be still allowed: Windows XP, Windows Vista or Windows Server 2003 doesn't support "TLSv1.1" and "TLSv1.2". Please use Google and make a research, how many users might not be able to visit your domain, if you resist on not using "TLSv1".





Edit: In addition, did you know, that GMail uses "Elliptic curve cipher SSLv3" ciphers ( ECDHE-RSA-AES128-SHA ) ? Another reason, why someone should again investigate, which ciphers list he/she forbids, when only using short restrictions like "-SSLv2 -SSLv3", without a special defined ciphers list in your configuration files. Not all "SSLv3" ciphers for example are vulnerable, so you definetely should use a more detailed ciphers list, instead of just restriction the usage completely.

Hi UFHH01,

Yes, that matches much of what I've researched on the matter. Looking at web logs, those versions of Windows are such small numbers it's a non-factor if we cut them off. From my hours of investigation it seems that this area of security for a lot of administrators is a highly confused topic with no real good source of definitive information, with detailed explanations regarding the different setups and configurations.

The thing I guess that stumps me is how Plesk reads the configs and implements the ssl_protocols and ssl_ciphers in regards to an Plesk/Apache/Nginx setup. I've been running and administrating Centos & Plesk for years, but this is really causing me some grief. I wish there was a GUI in the Plesk Administrator with checkboxes to set this stuff up, like a PCI-Compliance page, instead of a command.

I'll have to probably resort to the Risk Plan Template you referred, I can't burn anymore time on this until I fully understand every aspect of this technology, which I think in todays new cyber security landscape, is absolutely crucial, especially hositng commerce sites.