Installed version of OpenSSL on CentOS 6.8/Apache is current:
- rpm -qa | grep openssl
openssl-1.0.1e-48.el6_8.1.x86_64
openssl-devel-1.0.1e-48.el6_8.1.x86_64
and it shows that CVE-2016-2107 & CVE-2016-2108 are patched:
- rpm -qa --changelog openssl | head -n8
* Mon May 02 2016 Tomáš Mráz <tmraz@redhat.com> 1.0.1e-48.1
- fix CVE-2016-2105 - possible overflow in base64 encoding
- fix CVE-2016-2106 - possible overflow in EVP_EncryptUpdate()
- fix CVE-2016-2107 - padding oracle in stitched AES-NI CBC-MAC
- fix CVE-2016-2108 - memory corruption in ASN.1 encoder
- fix CVE-2016-2109 - possible DoS when reading ASN.1 data from BIO
- fix CVE-2016-0799 - memory issues in BIO_printf
But the SSLlabs and the Filippo test both show the server as vulnerable. OpenSSL shows 1.0.1e as affected: "OpenSSL 1.0.1 users should upgrade to 1.0.1o".
Is the server vulnerable or not? I don't care so much about the (false positive, I hope) test results at this point.
Can you post what SSLLabs reported?
Visit me at coderinthebox.com
Both Centos 6 and 7 are using same openssl version 1.0.1e but you should know that Centos usually backport changes, upgrades, patches, bug fixes... Did you check your SSL with services like https://www.ssllabs.com/ssltest/? If you see any errors it could be bad/poor configuration on your server. I have Vmin on one of my test VPS and i got A+ rating but i did several changes with httpd and ssl conf because settings what you get by default are really bad.
- I often come to the conclusion that my brain has too many tabs open. -
Failing at desktop publishing & graphic design since 1994.
I used to get A now I get F (especifically because of CVE-2016-2107, and it links to Filippo's site). As mentioned in the original post, the tests taken were SSL labs AND Filippo (the heartbleed guy).
Both say VULNERABLE.
It could be just bad configuration in httpd and ssl. If you already did yum update then there is nothing left to download and update so probably you should check your httpd and ssl conf files.
- I often come to the conclusion that my brain has too many tabs open. -
Failing at desktop publishing & graphic design since 1994.
SSLlabs explicitly states that the F is because of CVE-2016-2107.
And i'm telling you this is probably because of bad configuration in httpd and ssl conf files. Please check https://www.virtualmin.com/node/41221 and near the end you will see few of my post with suggestion about httpd and ssl. Dont forget to restart Apache.
- I often come to the conclusion that my brain has too many tabs open. -
Failing at desktop publishing & graphic design since 1994.
The folks at ServerFault (including the site's moderator) seem to think this is because httpd is a custom version (virtualmin) with different linkages.
All documents regarding CVE-2016-2107 & CVE-2016-2108 mention that updating openSSL is the only method of patching. There is no mention that directives in the conf files can be responsible for this, even when openSSL is patched.
I know that the conf files have not changed (ossec automatically backs them up when they do change). The only thing that changed was external - the vulnerability was discovered.
You are going against experts and documented evidence, without pointing to anything else but your own opinion. I will wait for the virtualmin team to chime in.
ServerFault guys are wrong, Virtualmin was not using a custom version (to a degree that it changed the whole software).
I have found out after a few diggings that Nginx was the culprit and it is so stubborn to use the old SSL version. It is recommended to reconfigure/update or relink Nginx. Some forced reload Nginx and it's dependencies and they got their SSL fixed.
I honestly have no idea how to configure an Nginx so I can't guide you step by step. This is on assumption that you are using it.
Here are the other scenario, some people compiled their apache with an embedded openSSL, apache will keep on using the embedded one until you relink it
Don't forget to restart Apache/Nginx
Visit me at coderinthebox.com
I did not manually compile Apache, nor we have Nginx installed.
Thanks.
Both Centos 6.8 (not sure for prior versions) and 7 are already patched for this so you should already have updated your openssl. Virtualmin doesnt have anything to do with this as they (Vmin) are pulling the updates from official repo plus i made another check right now from my test server and i got A+ rating. But please go to your experts and ask them what to do i'm sure they will help you better than this forum.
/i'm out
- I often come to the conclusion that my brain has too many tabs open. -
Failing at desktop publishing & graphic design since 1994.
Anyone so sure custom apache is not to blame is welcome to visit serverfault, maybe have a chat with the 100k+ points folks in the thread and even score some points: serverfault.com/questions/788415/test-shows-vulnerable-to-cve-2016-2107-cve-2016-2108-but-system-is-patched
Some people in serverfault buys reputation by getting people to click and upvote their comments.
Webmin is not using a customized version of Apache on exception to miniserv which is their compact apache server for webmin on port 10000.
I am using a Centos 6.8 before and no vulnerability appeared and got a B, B since I failed to turn off SSL2 and SSL3 then an A for disabling them. I am using "Let's Encrypt Authority X3 " as my certificate. Perhaps you are using an invalid Certificate since they also checked the certificate and the cipher
Visit me at coderinthebox.com
It's a comodo wildcard cert. The grade is specifically set to F because of the vulnerability in question, as shown in the screenshot.
As for added info, I have my main server running on 7.0, no patching was ever done for the past 6 months with regards to Open SSL. No vulnerability warnings. My last 6.8 Centos was converted to a pure proxy server, no domain name to test.
Visit me at coderinthebox.com
Can you do a screenshot of your test results and post it here as a link, that will help things move up faster
Visit me at coderinthebox.com
Summary: http://i.imgur.com/qVaJ8Sd.png
Protocols (SSLProtocol ALL -SSLv2 -SSLv3): http://i.imgur.com/QQrxEo7.png
I am using a Centos 6.8 before and no vulnerability appeared and got a B, B since I failed to turn off SSL2 and SSL3 then an A for disabling them.Take a look at my last post in this topic https://www.virtualmin.com/node/41221, that settings are tested and if everything else is in order they should give you A+ rating.
- I often come to the conclusion that my brain has too many tabs open. -
Failing at desktop publishing & graphic design since 1994.
Thanks, good thread. I am using the Mozilla generator's config.
@eddieb: Can you post what is your current SSLCipherSuite, i want to check with my test server.
- I often come to the conclusion that my brain has too many tabs open. -
Failing at desktop publishing & graphic design since 1994.
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHAyou will prob get an A or an A+
With that SSLCipherSuite i went from A+ to A- and "The server does not support Forward Secrecy with the reference browsers. Grade reduced to A-" but is still pretty good.
- I often come to the conclusion that my brain has too many tabs open. -
Failing at desktop publishing & graphic design since 1994.
Yes, the conf is for Apache 2.2.15, which does not support Forward Secrecy.
https://blog.qualys.com/ssllabs/2013/08/05/configuring-apache-nginx-and-...
Oh yeah i forgot you are on Centos 6.8. Well then the results are good.
- I often come to the conclusion that my brain has too many tabs open. -
Failing at desktop publishing & graphic design since 1994.
I'll open this again rather start a new thread...
We are running two different cloud servers at Linode. Both are pretty much configured exactly the same Ubuntu 14.04 1; apache 2.4.7 SSL1.0.0.1
Our business office wanted me to see if I could get the SSL up to a "Grade A" with SSL labs. Apple also requires it for the mobile apps that will talk to these servers.
I read the docs, and get new ciphers from Mozilla; added them to the conf directives for port 443
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 SSLEngine on SSLCertificateFile /home/himalayan/ssl.cert SSLCertificateKeyFile /home/himalayan/ssl.key SSLCACertificateFile /home/himalayan/ssl.ca SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS SSLHonorCipherOrder on
Save; Restarted Apache... and Yay!
https://www.ssllabs.com/ssltest/analyze.html?d=www.hinduismtoday.com --> Gets a Grade A
Boo! https://www.ssllabs.com/ssltest/analyze.html?d=www.himalayanacademy.com --> Gets a Grade F
But both are configured almost exactly the same.
But at https://www.himalayanacademy.com
I'm getting this now:
OpenSSL Padding Oracle vuln. (CVE-2016-2107) Yes INSECURE (more info)
I can't for the life of me see any differences in the conf for 443 between the domain (on one server) that does not have this OpenSSL Padding Oracle Vulnerability and the site/server that does have it.
Any clues of what to look for?
The letter at the end of your OpenSSL version matters, specifically for CVE-2016-2107. You stated 1.0.0.1, and you actually mean 1.0.1.
Run this command on both machines and see if the version running on each includes a patch for this exploit:
rpm -q --changelog openssl | grep CVE-2016-2107PS: Get your ciphers from https://mozilla.github.io/server-side-tls/ssl-config-generator/ or just use an alias, like "HIGH:!aNULL". See more aliases here: http://docstore.mik.ua/orelly/weblinux2/apache/ch11_09.htm