[BlueOnyx:21836] Re: https://www.ssllabs.com/ssltest/analyze.html actual only B rating for blueonyx Server with ssl

[Michael Stauber]

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