TLS policy vs PCI compliance

[pike (Michael Kicks)]

My two cents on your list…

• Windows Phone 8.1 has been discontinued as support from Microsoft
• Windows XP has been killed from Microsoft five years ago, enough?
• Firefox 31.3 ESR is obsolete, current ESR is 56.2. Firefox 47 is far more than superseeded, 67 is currently out.
• I am personally concerned from Android 6 error about handshaking, but i think that Chrome or Firefox could connect flawlessly… for web services. And email clients.

I think that closing doors to issues (vulnerabilities of cypher protocols) is far more important of the sensation of being protected (used faulty cypher protocols).

Providing an optional TLS policy PCI (willingly compliant) seems a great idea for me. If this will be available as optional (with a list of known-supported OSes) list should be great for help people test and feed with direct tests this list.

[paul_marwick]

@davidep

As suggested by @giacomo, we must care the Postfix SMTP client config too. It talks to other MTAs, and they could support only TLS 1.0… what does PCI say here?

So far as I can see, the PCI-DSS standard forbids TLSv1 on any open port.

[paul_marwick]

@stephdl

https://www.linuxquestions.org/questions/linux-server-73/disabling-tlsv1-0-on-postfix-%3D-~25-of-mails-not-received-4175572056/

in 2016, 25% of email not received when tls1.0 removed

I found a db command for SME 9.2 which allowed me to disable TLSv1 on all services (seems to work from the sslscans I’ve done on some of the SME machines). I’ve put it in place on all the servers I look after. Checking the logs just after I put the policy in didn’t show a big increase in failed mail connections.

In fact, looking at the logs for the one production Nethserver I’m running at the moment, it seems to refuse more mail, either due to the rspamd milter being more effective than anything SME is running or due to failed mta logins.

[stephdl (Stéphane de Labrusse)]

@paul_marwick

it seems to refuse more mail, either due to the rspamd milter being more effective than anything SME is running or due to failed mta logins.

yep, I implemented a quarantine rpm only to check what rspamd rejects as spam, I now deactivated it because I am really confident what rspamd refuses, you cannot read that kind of emails in front of our children, too much instructive
So in clear we refuse spam, we store to junk probable spam, and we soft reject possible spam, before to accept them after two or three attempts. I really love rspamd, spamassassin is mostly dead now

@paul_marwick

I found a db command for SME 9.2 which allowed me to disable TLSv1 on all services (seems to work from the sslscans I’ve done on some of the SME machines). I’ve put it in place on all the servers I look after. Checking the logs just after I put the policy in didn’t show a big increase in failed mail connections.

please could you point to the documentation please.

My mind is splitted here, we know that we cannot trust what MTA do with our emails, for example GMAIL is known to read what you send, for giving you back ads. So restrict a protocol for postfix, except for a commercial point of view, I do no understand really. If you care to protect your conversation, please use PGP like I do.

This is not true of course when you are in a direct link between your server and the clients, I mean dovecot, apache, ejabberd (because at the xmpp protocol they get rid of tls1.0) and other services using TLS.

As ever I never owned the truth, so please help me to change my mind

For those who care to change, hardening security of protocol communication, you have a good redhat book also : Securing Applications with TLS in RHEL - Red Hat Customer Portal

EDIT: at NS we are concerned to receive the email, so we use the TLS protocol with the may option. If the remote smtp cannot use TLS we accept the transaction

# With this, the Postfix SMTP server announces STARTTLS support to
# remote SMTP clients, but does not require that clients use TLS
# encryption:
smtpd_tls_security_level = may

[davidep (Davide Principi)]

@paul_marwick

So far as I can see, the PCI-DSS standard forbids TLSv1 on any open port

As such it does not apply to smtp client and other outbound connections (?)

[paul_marwick]

@davidep

@paul_marwick

So far as I can see, the PCI-DSS standard forbids TLSv1 on any open port

As such it does not apply to smtp client and other outbound connections (?)

Sorry - somehow I missed this, so the reply is very late coming…

In answer to the question, it doesn’t seem to. The scan report was purely concerned with ports open in the firewall. Thought it would seem to me that it should cover outbound connections of that sort as well.

The other thing that the scan fails to take any account of is other mitigating factors. So yes, some of cipher suites may be weak. But even if they are weak, it will take a great deal of time to break through. In an environment running something like fail2ban, it is difficult to see how anyone could get anything like the time needed to crack the encryption. But no-one at the scanning agency wants to answer that question…

I’ve also searched to see if there are any straight commercial products that I could offer as a stop-gap until such time as Nethserver can implement dropping TLSv1.0 on all services and block the encryption suites deemed to be weak. I’ve found a number of places offering PCI-DSS compliant servers, but all of them are hosted systems, not server software, which would be of no use at all in this situation.

At the moment, I’m waiting for further information from Scan Metrics, the firm that seems to do a lot of the compliance testing. Hoping that Nethserver will give me some options soon

[danb35 (Dan)]

@davidep

I’d like to see this new TLS policy as the default of NethServer 7.7

So would I. But not only is it not the default, it isn’t even available.