Enhance security, TLS policy, harden apache

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.

https://cryptcheck.fr
https://observatory.mozilla.org/

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.

Example of a good configuration:
https://cryptcheck.fr/https/searx.tiekoetter.com
https://observatory.mozilla.org/analyze/searx.tiekoetter.com

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:
image

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:

…and as you scroll down the page, they’ll tell you, line by line, what they were looking at.

The Mozilla Observatory is all about the headers, and those are something for your application to implement.

3 Likes

same response from mine E with cryptcheck and a with ssllabs

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.

2 Likes

It seems cryptcheck is really strict, to get an A you need HPKP, for a B HSTS, see cryptcheck help.

Even after removing the “bad” ciphers I just got an E.

2 Likes

OK, sounds like a pretty good reason to disregard them. HPKP has been deprecated for years.

2 Likes

What does https://observatory.mozilla.org/ say?

Modilla also gives you an “F”: Mozilla Observatory

Which is you site and “A” is good enough, but NS default is “F” on cryptcheck and Mozilla.

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.

4 Likes

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.

1 Like

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

The change could be to remove CBC cipher

SSLCipherSuite ALL:!RSA:!CAMELLIA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SHA1:!SHA256:!SHA384

a dirty hack in /etc/httpd/conf.d/nethserver.conf

then you just have

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp256r1 (eq. 3072 bits RSA) FS 256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 2048 bits FS 256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 2048 bits FS 128

but you still have a E and many old clients (mostly old phone) are quicked

2 Likes

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.

1 Like

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.

Well and good–but what should change in this suggested new policy?