cPanel & WHM Version 80 has been released, and brings a slew of great updates. Take a look at what is included, and then upgrade today!
 
This object is in archive! 

Provide OpenSSL 1.0.1c or Higher as cPanel RPM, to allow TLS 1.1, TLS 1.2

AlphaWolf shared this idea 6 years ago
Completed

OpenSSL prior to version 1.0.1 only supports TLS 1.0. Every encryption scheme of TLS 1.0 is vulnerable to the BEAST attack, except RC4. Recently, RC4 was confirmed to be broken as well: https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what


This means there are no secure encryption schemes under TLS 1.0.CentOS/RHEL versions 5.x and 6.x are stuck on OpenSSL versions 0.9.8e and 1.0.0, respectively. CentOS/RHEL 5 does not reach EOL until March of 2017. CentOS/RHEL 6 doesn't reach EOL until November 2020. That means there will be cPanel servers without TLS 1.1+ support for at least another 7 years. Luckily, there is a solution: cPanel can package and supply a more recent version of OpenSSL for all supported systems, and EasyApache can build against this updated library. This has been tested to some degree by another cPanel forum member:

https://forums.cpanel.net/f185/cpanel-openssl-1-0-1c-higher-332001.html#post1355351


Other than the security concerns, there are other reasons to upgrade OpenSSL to 1.0.1c or higher.

  • RHEL/CentOS 5 servers cannot support SNI, which is becoming more important as IPv4 addresses are drying up. SNI was not supported until OpenSSL 0.9.8f, but these servers ship with OpenSSL 0.9.8e.
  • RHEL/CentOS 5 servers cannot support OCSP stapling, which decreases the latency introduced in the TLS handshake by checking certificates for revocation. OCSP stapling was not supported until OpenSSL 0.9.8g, but these servers ship with OpenSSL 0.9.8e.
  • OpenSSL 1.0.1+ adds support for the AES-NI instructions in Westmere/Sandy Bridge/Ivy Bridge or later processors, which increases performance of SSL/TLS connections and prevents timing attacks against AES.
  • ...and much much more! :)

Please supply an upgraded version of OpenSSL for supported operating systems that don't supply version 1.0.1c or greater.

Best Answer
photo

The OpenSSL update provided by Red Hat 6.5 (also CentOS 6.5) provides the sufficient functionality requested at this time. We encourage all owners of Red Hat 5 and CentOS 5 systems to upgrade to 6.5 or newer.

Comments (31)

photo
3

this is a must have feature and soon.

photo
4

I see no reason why this couldn't be implemented. With all my testings everything does seem flawless and a rpm like that could easily be maintained by cPanel.

photo
2

Hope this can be addressed soon.

photo
1

Is there a way to update it with CentOS 5 and cPanel without having to wait?

photo
4

This is CRAZY it is not supported already, do you guys not realize that this makes pretty much EVERY single cPanel/WHM server non-PCI Compliant? It fails PCI Compliance testing because of OpenSSL being outdated and ranked as a SEVRE/CRITICAL warning within PCI Policies. How long has it been now since they realized how exploitable and buggy the current is? And still no update? Really guys? MUST HAVE!

photo
1

Very important feature. Please implement.

photo
1

We personally couldn't wait more until cPanel "might" deploy such upgrades. We implemented the described solution on production servers using the provided guide on the forum thread that the OP mentioned on this feature request.

photo
1

Really Urgent feature!

photo
1

I've just read Plesk has this support...

photo
2

While I am all for this as its ultimately a must have, I think the other folks commenting need to realize that browser support for this is essentially non-existent at the moment. For example, Chrome 29 (beta), FireFox 24 (beta & disabled by default), IE (only on Win 7+, IE version 8+ & disabled by default except in IE 11 Preview). Safari does support it on v.5 but only on iOS 5.0. (source: http://en.wikipedia.org/wiki/Transport_Layer_Security)


So if you had this fix today and only used TLS 1.2, which is what would be necessary to fix this, very few people (and only those that are technically capable enough to turn it on themselves on their beta browser) would even be able to use SSL at all.


So, yes, its needed. But realistically until you can force the end-user to upgrade their browser (as if that were possible/likely) and can turn off older TLS versions, you are stuck with them for the forseeable future.

photo
1

I would love to have this feature implemented oficially.


I'm not really a fan of changing things manually, not because I'm not able to, but because manually changing stuff on the OS tends to break cPanel, and sometimes viceversa.


Also, all the users that are not aware of the BEAST attack and the real implications of using an SSL (those who just buy it for the lock and green https words) would never update OpenSSL on their own, so it would be a really good idea to make this change within the cPanel.


It shouldn't be too hard now that cPanel provides it's own RPM services (MySQL and some others).

photo
1

Look forward to seeing this officially supported!


When I run


# openssl version


it returns:


OpenSSL 1.0.0-fips 29 Mar 2010


Is it just me or does that seem pretty old? Really looking forward to 1.1 and 1.2.

photo
2

TTech wrote:

This is CRAZY it is not supported already, do you guys not realize that this makes pretty much EVERY single cPanel/WHM server non-PCI Compliant? It fails PCI Compliance testing because of OpenSSL being outdated and ranked as a SEVRE/CRITICAL warning within PCI Policies. How long has it been now since they realized how exploitable and buggy the current is? And still no update? Really guys? MUST HAVE!

I'll respond to some of the other points in this thread shortly, but this is a dangerously false statement.


cPanel leverages your package management system (rpm) to install the openssl provided by your operating system. Security fixes are backported by your OS vendor (RedHat, CentOS). They typically pick a version they want to support (0.9.8 on CentOS 5 as an example) and then backport security fixes and occasionally features as needed. As a result, openssl 0.9.8e provided by your OS vendor is very different from the original 0.9.8e source - all known CVEs are regularly fixed in your OS version. All you have to do is run a non-EOL OS and keep it up to date, and you'll receive those fixes.


This is why, when you tell a PCI compliance vendor that you're using openssl from your OS, and show them the CVEs have been patched with that version, they'll whitelist the the item as a false positive.


You could easily check to see if a given vulnerability has been patched:

  1. rpm -q --changelog openssl | grep -iE 'security|cve|vuln'

photo
3

Rick Ewart wrote:

While I am all for this as its ultimately a must have, I think the other folks commenting need to realize that browser support for this is essentially non-existent at the moment.

This is no longer true. The current version of Chrome supports TLS 1.2 out-of-the-box. Current browser market share estimates place chrome usage between 33% and over 50%. That's a considerable chunk of the internet. Since Chrome auto-updates, it's reasonable to assume most users are on a version that supports TLS 1.2.


Aside from the security aspects of this request, SNI is supported by all major browsers, but cannot be implemented in RHEL 5/CentOS 5 without a cPanel-provided upgrade to OpenSSL.


Rick Ewart wrote:

So if you had this fix today and only used TLS 1.2, which is what would be necessary to fix this, very few people (and only those that are technically capable enough to turn it on themselves on their beta browser) would even be able to use SSL at all.

This is a bit chicken and egg -- the browser folks think they don't have to support it because there is no server support, and the server folks think they don't have to support it because there is no browser support (which is no longer true). The exact same thing (with different parties) has been happening with IPv6.


Just to clarify, I realize you are in support of the idea -- I'm just engaging in some discussion and letting people know that there is in fact browser support as of now.


To add a bit of fuel to the fire -- this has become even more important now that we've become more aware of the NSA's surveillance capabilities. Nobody, including the NSA, should be able to wholesale defeat the encryption of the web. The consensus seems to be that Perfect Forward Secrecy (PFS) can thwart one of the attack vectors the NSA uses in their dragnet surveillance. Unfortunately, you can't use PFS with RC4. So your options are: 1.) Protect your clients' privacy from the NSA, while leaving them vulnerable to the BEAST attack. 2.) Protect your clients from the BEAST attack, but force them to use the weak RC4 cipher without PFS and accept that the NSA (and other government agencies) can probably read every bit that comes out of your server without any sort of warrant.


Seriously... It's time to upgrade OpenSSL, or base Apache's encryption on a different library like gnutls.

photo
2

http://forums.cpanel.net/f185/cpanel-openssl-1-0-1c-higher-332001.html <- This works, im running all my servers with this and a good SSL Cipher to pull my sites to Grade A beating the BEAST attack :) works wonders.

photo
2

You should use 1.0.1e as it includes three security fixes AND bug fixes! As for "OpenSSL 1.0.0-fips 29 Mar 2010" is trully OLD (will be 4 years soon) and shouldn't be supported anymore.

photo
1

Moderator: please send security reports to security@cpanel.net


Please leave hyperbole out of the discussion.

photo
2

Clayton Johnson wrote:

Moderator: please send security reports to security@cpanel.net


Please leave hyperbole out of the discussion.

YOUR EMPLOYEE TOOK THE SECURITY REPORT. Maybe you should actually read a post before you moderate it.

photo
1

Clayton Johnson wrote:

Wanna kill someones cPanel server? Send non-unicode characters to any login form on a SSL port. cPHulk will lock their passwords file for 15 minutes. Setup a script to run it every 14 minutes and 59 seconds and a cPanel server becomes useless.

photo
1

Clayton Johnson wrote:

...

You're completely off-topic.


Gradius wrote:

You should use 1.0.1e as it includes three security fixes AND bug fixes! As for "OpenSSL 1.0.0-fips 29 Mar 2010" is trully OLD (will be 4 years soon) and shouldn't be supported anymore.

This has been discussed already -- the OpenSSL that the OS vendor supplies has bug fixes backported to it. It may be four years old, but the library itself has been patched and is secure. This feature request isn't about bug/security fixes, it's about using a newer version of OpenSSL in order to enable features that are not available in older versions. The most important of these features is TLS v1.2 support, because TLS v1.0 is veritably insecure. In other words, the request is about security, but not security "fixes".

photo
1

With a little work i managed to also get PFS support with modern browsers. Details are posted on the forum topic described on this feature request. Just needed to make a custom rpm build of openssl with the right ciphers.

photo
1

Doesn't the latest rehdat 6 have this now ? I know Cloudlinux has updated to aversion that should have it, I'll have to check and see what version we've got now !

photo
2

monarobase wrote:

Doesn't the latest rehdat 6 have this now ? I know Cloudlinux has updated to aversion that should have it, I'll have to check and see what version we've got now !
RHEL/CentOS 6.5+ comes with OpenSSL 1.0.1e. The upgrade provides support for TLS 1.1 and TLS 1.2. There is also some support for elliptic curve in RedHat's RPM. We have confirmed both Apache and cpsrvd understand TLS 1.2 with this RPM, as well as


negotiating strong ciphers (AES256-GCM-SHA384 and


DHE-RSA-AES256-GCM-SHA384, for example)

photo
1

Kenneth Power wrote:

RHEL/CentOS 6.5+ comes with OpenSSL 1.0.1e. The upgrade provides support for TLS 1.1 and TLS 1.2.
This is great news!


When I look in cPanel now I see:


CENTOS 6.3 x86_64 virtuozzo – ip-(xxx-xxx-xxx-xxx) WHM 11.40.1 (build 3)


What steps should be taken to get CentOS 6.3 bumped up to 6.5?

photo
1

dualmonitor wrote:

This is great news!


When I look in cPanel now I see:


CENTOS 6.3 x86_64 virtuozzo – ip-(xxx-xxx-xxx-xxx) WHM 11.40.1 (build 3)


What steps should be taken to get CentOS 6.3 bumped up to 6.5?

Usually it's a matter of running yum upgrade as root via the command line.

photo
1

will yum upgrade interfere with cpanel upgrades? I thought it was best practice to let cpanel handle all os upgrades?

photo
1

dualmonitor wrote:

This is great news!


When I look in cPanel now I see:


CENTOS 6.3 x86_64 virtuozzo – ip-(xxx-xxx-xxx-xxx) WHM 11.40.1 (build 3)


What steps should be taken to get CentOS 6.3 bumped up to 6.5?

Your VPS is based on virtuozzo container technology. You should ask your provider how the centos upgrades are done. There where some providers which are not allowing individual yum upgrades but provide the upgrade via a central template.

That saved them space and it was not counted against your storage space. But most provider are going to allow invidual package management per container.


yum upgrades relating to the kernel are provided by your provider since you don't have a dedicated kernel for each vps under the virtuozzo technology.

photo
1

sonicthoughts wrote:

will yum upgrade interfere with cpanel upgrades? I thought it was best practice to let cpanel handle all os upgrades?
Cpanel will execute yum to upgrade noninteractive uppdates/upgrades. If you check /etc/yum.conf for excludes you will find certain packages excluded.

Kernel update are mostly done in a manual way.

photo
2

Should't this feature request be marked as resolved or something or is there still something to implement ?

photo
1

The OpenSSL update provided by Red Hat 6.5 (also CentOS 6.5) provides the sufficient functionality requested at this time. We encourage all owners of Red Hat 5 and CentOS 5 systems to upgrade to 6.5 or newer.

Comments have been locked on this page!