TLS policy vs PCI compliance

NethServer Version: 7.6.1810
Module: TLS Policy

One of the SME server systems I need to migrate to Nethserver will need to be PCI compliant due to use of card payment data transferred through the server. As a result, I need to implement a tighter TLS policy than the current one. At the least, I need to be able to disable all the TLS V1 protocols, and any TLS 1.1 + policies that use less than 256 bits.

I know how to turn off TLS 1.0 in SME, but I have no idea how to go about doing that, or any further hardening in Nethserver.

Can anyone tell me how to go about implementing tigher TLS security?

1 Like

http://docs.nethserver.org/en/v7/tlspolicy.html

1 Like

Thanks. I was aware of that policy, and have submitted it in my (current) production Nethserver machine. However, running sslscan on the system gives me this:

      Accepted  TLSv1  256 bits  ECDHE-RSA-AES256-SHA
    Accepted  TLSv1  256 bits  DHE-RSA-AES256-SHA
    Accepted  TLSv1  256 bits  DHE-RSA-CAMELLIA256-SHA
    Accepted  TLSv1  128 bits  ECDHE-RSA-AES128-SHA
    Accepted  TLSv1  128 bits  DHE-RSA-AES128-SHA
    Accepted  TLSv1  128 bits  DHE-RSA-CAMELLIA128-SHA
    Accepted  TLSv1  128 bits  AES128-SHA
    Accepted  TLSv1  128 bits  CAMELLIA128-SHA
    Accepted  TLS11  256 bits  ECDHE-RSA-AES256-SHA
    Accepted  TLS11  256 bits  DHE-RSA-AES256-SHA
    Accepted  TLS11  256 bits  DHE-RSA-CAMELLIA256-SHA
    Accepted  TLS11  128 bits  ECDHE-RSA-AES128-SHA
    Accepted  TLS11  128 bits  DHE-RSA-AES128-SHA
    Accepted  TLS11  128 bits  DHE-RSA-CAMELLIA128-SHA
    Accepted  TLS11  128 bits  AES128-SHA
    Accepted  TLS11  128 bits  CAMELLIA128-SHA
    Accepted  TLS12  256 bits  ECDHE-RSA-AES256-GCM-SHA384
    Accepted  TLS12  256 bits  ECDHE-RSA-AES256-SHA384
    Accepted  TLS12  256 bits  ECDHE-RSA-AES256-SHA
    Accepted  TLS12  256 bits  DHE-RSA-AES256-GCM-SHA384
    Accepted  TLS12  256 bits  DHE-RSA-AES256-SHA256
    Accepted  TLS12  256 bits  DHE-RSA-AES256-SHA
    Accepted  TLS12  256 bits  DHE-RSA-CAMELLIA256-SHA
    Accepted  TLS12  128 bits  ECDHE-RSA-AES128-GCM-SHA256
    Accepted  TLS12  128 bits  ECDHE-RSA-AES128-SHA256
    Accepted  TLS12  128 bits  ECDHE-RSA-AES128-SHA
    Accepted  TLS12  128 bits  DHE-RSA-AES128-GCM-SHA256
    Accepted  TLS12  128 bits  DHE-RSA-AES128-SHA256
    Accepted  TLS12  128 bits  DHE-RSA-AES128-SHA
    Accepted  TLS12  128 bits  DHE-RSA-CAMELLIA128-SHA
    Accepted  TLS12  128 bits  AES128-SHA
    Accepted  TLS12  128 bits  CAMELLIA128-SHA

There are a number of TLS V1 protocols in the accepted list, and a number of 128 bit protocols. From what I know about the PCI compliance, that will fail it.

So I was looking at ways in which it might be further hardened.

What are the requirements of PCI compliance?

Limited to httpd, you could override and make a template-custom of

/etc/e-smith/templates/etc/httpd/conf.d/nethserver.conf/10tls_policy_20180621

As long as 2018-06-21 is the last httpd-implemented policy your template custom will be future-proof.

Why do the two most recent policies disable TLS 1.0 only for certain services? That really doesn’t seem like the expected behavior, and neither do the varying cipher suite settings across services.

I think because the goal is not “disabling TLS 1.0”. Instead they address the improvement of specific services (namely slapd and ejabberd) which were left behind by previous policies.

Do you think TLS 1.0 is not secure enough? It could be the goal of the next policy…

PCI rules state that you’re not allowed to use TLS 1.0 anymore and the best way to ensure and enforce the non-usage of TLS 1.0 is to disable it completely.

2 Likes

Well, it’s definitely old–20 years old, to be specific. There are known vulnerabilities (even if they can be mitigated), and it supports a number of insecure cipher suites (which can be configured out). TLS 1.2, the current real standard (TLS 1.3 isn’t official yet, but there seems to be a widely-agreed pseudo-standard at this point) is itself over 10 years old. But my confusion was more that a given “TLS policy” (1) does things that don’t have anything to do with TLS (like the SSH configuration), and (2) configures different services to do different things.

On the latter point, my expectation would be that “TLS policy X” configures all services that use TLS at all, to use the same set of protocols and cipher suites. Maybe there are technical reasons this isn’t practical, but that’s what I’d expect a “TLS policy” to do.

Now, as to the question on TLS 1.0, yes, I think we should create a policy to deprecate that (and TLS 1.1) entirely, allowing only TLS 1.2 and 1.3. That should pretty well address the cipher suite issue as well. It will break compatibility with IE < 11 and Android < 5, so I’d think it should be an option rather than the only setting, but I do think it should be there (and probably be the default for a new install).

1 Like

Add and mantain a security policy for PCI compliance?

I’m still working my way through the PCI-DSS standards. The system I mentioned is currently running SME 9.2, and failed the vulnerability scan. Looking at the scan report, it covers all open ports, so in this case, 993, 465, 443 80,25, 22. TLSv1 is not accepted at all, and any protocols that use 64-bit block ciphers. Other ciphers that are not liked are any using 112-bits or less or the 3DES encryption suite. For this they suggest that all ciphers should be TLSv1.1 or higher.

In SME, I was able to disable all TLSv1 protocols, but due to the age of the system could not take it much further than that. I’m hoping that with Nethserver it may be possible to implement a suite that satisfies the full PCI-DSS standard.

Just to make things even more complicated, the standard is enforced differently by different payment processors. In the SME systems I look after, there are two others who also process card payments, both of which are still on SME 9.2 and operating without problems!

I also expected the TLS pollicy to cover all services, which is why I was surprised that a number of TLSv1 protocols were accepted. If nothing else, it would make auditing security much easier.

I would also like to see a default policy which disabled both TLSv1 and TLSv1.1 just for tighter security on all services. One of the things that makes me eager to get the rest of the SME systems I look after migrated to Nethserver is the drop in incoming rubbish that I’m seeing on the one system I have so far migrated. That improved security makes my job of looking after the systems much easier.

Hope this could help…
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf?agreement=false
Updated on 2018

1 Like

We could add a very strict policy compliant with PCI DSS, maybe named exactly like that. :slight_smile:

I have two concerns with that:

  • If we call a policy PCI-DSS compliant, we need to be very sure that it is
  • Since the PCI-DSS standards change, we need to keep up with them to ensure the first bullet continues to be true
1 Like

If disabiling tls 1.0 and tls 1.1 is enough for Paul and current PCI requirements we can add a new policy with that goal.

Apart from being compliant with this or that, it drops compatibility with older clients on one hand and improves security on the other, just like existing policies, so I don’t see the need of a dedicated label. We can document that policy X gives (some degree of) compliance with Y.

Dan, you’re right here: SSH does not relate to TLS. We could fix this in future policies, by reverting it to the original settings that should be safe enough. What do you think?


Sorry Paul for hijacking the support request: I changed it to Feature :innocent:

I think that’s the way to do it. Create “Policy 2019-06-10”, and state in the documentation something like:

On SSH, if there was a reason to change its configuration, change its configuration–just don’t tie it to a “TLS policy”.

1 Like

That definitely sounds like a good feature.

A cautionary not on it though for the pedantic legal and auditing geeks - it would need a disclaimer added to it which would say something to the effect of:
This policy template is to assist with the PCI Compliancy as defined by Document x dated y and which is located at y. This does not imply or guarantee that this installation is 100% PCI DSS Compliant and the system administrators do still need to do their due diligency with the configuration and testing in order to ensure that this installation is PCI DSS Compliant.

1 Like

I don’t know if this blog post is reliable enough, but seems a nice summary:

IIUC, the PCI DSS requires to disable SSL and TLS 1.0. TLS 1.1 has some vulnerabilities but is still allowed (?)

According to Wikipedia the last standardization document was released on May 2018.

That’s my understanding as well, but TLS 1.1 isn’t used much at all. The preferred route seems to be to go directly to 1.2+.