Sorry for the slow response - bad week...
Yuck.
I agree. What is worse is that there seem to be wildly differing standards used. Three of the systems I maintain make use of card readers that connect over the internet and should therefore all need to meet PCI-DSS requirements. Only one of those systems is currently facing this problem, even though it almost certainly has the lowest levels of use.
It most likely is overkill, but they are the piper and you have no choice but to follow them over the edge of the cliff....
It seems to me that someone has found a wonderful means of making money. Security Metrics are the company doing compliance testing in this instance, and their standards don't seem to take account of other protections that limit the ability of an attacker to get the sort of access to a system that would be required to break even the weakest of the cipher suites.
But, as you say, no choice but to follow....
It wasn't as far as I am aware, because it isn't that easy.
That explains it - I didn't find any further follow-up to that bug report and my testing shows that the restriction on use of TLSv1.0 is only on HTTPS rather than on any of the other services. Which is a problem, since the Security Metrics scan has found weaknesses in all open ports on the system.
Yes, and no...
To test stuff add sslscan
yum --enablerepo=epel install sslscan
I've been using sslscan for a while. I've also found testssl.sh (
https://testssl.sh/) useful in checking what protocols and ciphers are in use on systems.
Before you start read read https://forums.contribs.org/index.php/topic,52120.msg266805.html#msg266805 because this truly is a rabbit hole.
A good description. I had found that one in my searching for answers. Not eager to start editing templates, though I guess I may have to do just that.
From https://bugs.contribs.org/show_bug.cgi?id=9154#c11
config setprop httpd-e-smith TLSv1 disabled
signal-event post-upgrade && signal-event reboot
Then run sslscan -html your.server:443
Done that on a couple of the systems. It effectively drops TLSv1.0, but still leaves a number of cipher suites that are considered weak available. Not to mention that it only covers HTTPS. If I had to, I could close the HTTPS ports (though I'd rather not, since several of the users do make use of webmail and seem resistant to changing to a real email client). Only one of the systems I look after has a local website - the rest all use remotely hosted web sites.
No idea - the requirements are stringent and you might need a server specially crafted to handle it in all honesty.
I've found a couple of systems that are supposed to meet the requirements. I keep hoping that either SME or Nethserver can cover it - I know almost nothing about the commercial options, other than the fact that they seem to be hideously expensive.
You can disable POP services, and enable some cipher stuff on qmail and qspmtpd. However, having looked, there are various settings but the info is splattered all over the place
I'm glad to say that none of the systems have POP3 enabled - all IMAP for mail. But, as you say, getting the other options set seems to involve changes all over the place.
Talking with Terry and seeing if we can't try and get all this stuff in one place
Some other links.
qmail SSL/TLS - package in updates testing but no on/off switch yet.
https://bugs.contribs.org/show_bug.cgi?id=9349
https://wiki.contribs.org/Qpsmtpd:tls
https://wiki.contribs.org/DB_Variables_Configuration
Look for qpsmtpd ciphers
db configuration setprop qpsmtpd tlsCipher XXX
Bear with us and we'll see if we can't tidy some of this up a bit. Know any decent test sites?
Great, thanks. I've been using SME for quite a long time (first installed system was 7.1) and while I quite like some of the things Nethserver is doing, I'm much more familiar with SME and have built a lot of trust in it.