There are multiple complaints of these security check sites about the the NS configuration even with the most recent TLS policy 2020-05-10. I only get an “F” and “I” rating with my NS instance on both sites, but I it should be an “A+” rating and “M” rating possible.
I suggest that NS gets a newer TLS policy which implements the “modern” recommandations of apache and a better configuration (at least as an option) of apache to get “A+” and “M” ratings.
What are the complaints raised by those sites, and why should we care what cryptcheck.fr (whoever they are) says? Here’s what they say about my domain:
I have no idea what that means (other than that those four crypto suites are used by my server), and can’t find anything on their site that tells me. By contrast, here’s what ssllabs.com says about the same site:
I strongly disagree with the principle of chasing grades for their own sake–particularly when they’re grades with no obvious meaning (what does E mean, anyway?), given by a site I haven’t heard of, with no context explaining how they grade. I don’t much care if I get an E there, or an M, or Q, or a ∑–because nothing I can find there tells me what any of those things mean.
SSLLabs, by contrast, publishes their rating guide:
And their report tells you what they like and don’t like. But even there, where I know (or can readily find out) their criteria, I’m not concerned with the grade as such. For example, the reason I have an A rather than an A+ is that I don’t have HSTS on my main site–and that’s deliberate.
I know. I don’t care. Like I said, Mozilla Observatory is all about the headers, and those are controlled by the application. Learn what these testers are telling you before telling us that we need to change the system for the sake of a score.
If you test an actual web application running on Nethserver, like Nextcloud, you get this instead:
My site is running on Nethserver, and I’m pretty sure I haven’t made any changes to its TLS handling. Cryptcheck can set whatever idiotic criteria they want for their scores, and I can give them whatever credence (namely, zero) I believe is appropriate. Is there a reason we should care what cryptcheck.fr says? Because I don’t see one.
Again, I’m not going to chase scores for the sake of scores. If there’s a problem, bring up the problem. But if it’s only a bad score from some website run by somebody who thinks a feature that’s been deprecated for FOUR YEARS still ought to be used, nope, no f*cks to give about that.
Edit:
Assuming you’re talking about the configuration from Mozilla’s generator, this isn’t possible. The installed versions of Apache and OpenSSL don’t support the “modern” configuration.
There are several versions of cipher sites with DHE, which are considered weak, the cryptcheck markes them orange. The same is done by SSL Server Test (Powered by Qualys SSL Labs). Here an example of a check of an NS installation. It (still) gives “A”, but markes WEAK DH ciphers.
ssllabs.com also marks the same ciphers as weak as cryptcheck, but it does not lower the grade currently (but is likely to do it in the future). Here the screenshot of db-cloud.org.
…but it gives you an “E” with or without those suites, as shown above. And their site tells you f-all about what “E” means other than “Take security into account. A little. Or not.” Cute, but hardly helpful. There’s no mention anywhere on the help page of what the E rating means (i.e., what triggers it), or how to get rid of it.
So what is your actual suggestion/request? If it’s, “change Neth’s configuration so cryptcheck returns an A,” I’d oppose it, because Cryptcheck is manifestly run by a moron, and the requirement for an A rating is that Neth implement a feature that’s been deprecated from all major browsers for years. If it’s “stop using the DH cipher suites”, I guess that’s straightforward enough, though there’s an open question about client compatibility.
We try to keep a good balance between security/hardening and compatibility. If we restrict to all really strict ciphers then you could have some old clients that could refuse to connect.
It won’t have probably a new centos minor version, traditionally we use it to change default settings, so I am not sure we will go to that way
I notice the same behavior for the webapplications I have installed. Nextcloud is giving an A+ on mozilla observatory. I think it is ‘safe’ to conclude that score is 100% depending on application settings and not so much on NethServer.
My suggestion was to introduce a new, harder TLS policy. The policy can be already selected in the NS Cockpit, so everyone can choose, if he would like the harder policy at the cost of some client incompatibilities.
