Hello Michael, the servers are fully updated. I did explicit a "yum clean all" and "yum update" I did an additional test with a site where I did enable SSL today. However my result is aways B with missing PFS.
> > here is a new suggestion for only accepting strong ciphers and with PFS > > enabled: > > > > SSLCipherSuite > > ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 > This doesn't work on EL7 or EL6. If this exact SSLCipherSuite is used, > Apache fails to restart: No this is not correct. I did replace the original SSLCipherSuite within a site<nr> with the SSLCipherSuite I posted and it is working with an A rating a no WEAK Ciphers (I can send you a private mail with the URL if you want to have a look). +1 for your nginx idea and not only as proxy for 443 also for 80. Best regards, Dirk --- blackpoint GmbH - Friedberger Straße 106b - 61118 Bad Vilbel -----Ursprüngliche Nachricht----- Von: Blueonyx [mailto:blueonyx-boun...@mail.blueonyx.it] Im Auftrag von Michael Stauber Gesendet: Dienstag, 13. März 2018 16:45 An: email@example.com Betreff: [BlueOnyx:21836] Re: https://www.ssllabs.com/ssltest/analyze.html actual only B rating for blueonyx Server with ssl Hi Dirk, Before we go any further: Please do a "yum clean all" and "yum update" and restart Apache. Then check if you have an intermediate cert (if you need one) for the GUI and for the Vsite in question. Then check again with SSLlab. Test once against the FQDN of the server, then once against the same Vsite you used last time around. *If* you get a different result for the Vsite, disable SSL there, save and enable SSL again and then see if the result is now better. > here is a new suggestion for only accepting strong ciphers and with PFS > enabled: > > SSLCipherSuite > ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 This doesn't work on EL7 or EL6. If this exact SSLCipherSuite is used, Apache fails to restart: $s->add_config() has failed: SSLCipherSuite takes one argument, Colon-delimited list of permitted SSL Ciphers ('XXX:...:XXX' - see manual) at /etc/httpd/conf.perl/00-default-vsite.pl line 226, <GEN0> line 87.\nCompilation failed That's because RedHat's crippled OpenSSL (openssl-1.0.2k on EL7 and openssl-1.0.1e on EL6) doesn't have "Chacha" or "Poly". Even if I remove ECDHE-ECDSA-CHACHA20-POLY1305 and ECDHE-RSA-CHACHA20-POLY1305 from your suggestion it still fails, as one or more of the other ECDHE/ECDSA aren't supported either for "patent reasons". About a week ago I tried to get rid of the "weak" ciphers and couldn't find a way that wouldn't blow us out of the water in other regards. There is no OpenSSL macro (such as "aNULL" which groups certain ciphers or methods) that matches them. These "weak" ciphers are (still) in fact within the group "HIGH" which matches ciphers with high security. Which means you need to block them one by one if you use the "HIGH" macro. Eventually I had a pretty darn long SSLCipherSuite string that threw them all out (and just them). The result was a "B-" because we no longer provided forwarding secrecy with some reference browsers. The fun part is: When you look at the "Handshake Silulation" at the SSLlabs result page: None of the browsers listed there uses *any* of the weak ciphers. FWIW: I'm currently contemplating a somewhat different approach for SSL. So far this is just that: An idea. And it might not be the greatest idea, so it is something that I'll be playing with for evaluation and *possible* integration into BlueOnyx. The way Apache does SSL isn't the greatest. The OpenSSL we have on CentOS is both older than it ought to be and it RedHat also reduced the cipher-suite for arbitrary reasons, removing some of the really modern and strong ciphers. I've blogged on this in detail on the BlueOnyx Developer News on www.blueonyx.it over the years. Just search for OpenSSL and pick the article with the least complimentary wording. :p How do we get around that? One doable and potentially beneficiary way would be to no longer let Apache handle SSL and take it away from port 443 entirely. Just let it serve HTTP on port 80. Then we use Nginx as SSL proxy. Nginx would bind only on port 443 and would have the VirtualHost containers for SSL, internally forwarding the external HTTPS connections to Apache via HTTP and serving the results back via HTTPS. The whole external communication between client and browser (in that case Nginx) would run over HTTPS and Nginx just gets the pages via a localhost proxy query. As it's proxying, we wouldn't have to worry that Nginx doesn't do PHP as DSO and can't do mod_ruid2 either. Because Apache would still be doing that and Nginx just passes the results along. The main benefit here would be that we could compile our Nginx against the most modern OpenSSL release that we install into a separate directory. That way we get *all* the ciphers, including those really strong ones that RedHat denied to us. The kicker is: We'd also get HTTP/2, but in that case only for the HTTPS connections that Nginx serves. It won't be as good as natively served HTTP/2 as we're still having Apache "hustling the goods" in the background, but it'll be as good as it gets until we get a RedHat/CentOS with OpenSSL-1.1.0 or better and an Apache that understands HTTPS/2. Like said: So far this is just an idea. It might not fly. Even if it does: It'll be another "invasive" update and adds a layer of complication that might not find the appreciation of the general user base. But it is something that's at least worth exploring for *possible* integration in the future. -- With best regards Michael Stauber _______________________________________________ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx _______________________________________________ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx