Provide OpenSSL 1.0.1c or Higher as cPanel RPM, to allow TLS 1.1, TLS 1.2
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.
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.
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.
this is a must have feature and soon.
this is a must have feature and soon.
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.
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.
Hope this can be addressed soon.
Hope this can be addressed soon.
Is there a way to update it with CentOS 5 and cPanel without having to wait?
Is there a way to update it with CentOS 5 and cPanel without having to wait?
There are MANY known problems with this. See https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what
There are MANY known problems with this. See https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what
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!
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!
Very important feature. Please implement.
Very important feature. Please implement.
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.
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.
Really Urgent feature!
Really Urgent feature!
I've just read Plesk has this support...
I've just read Plesk has this support...
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.
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.
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).
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).
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.
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.
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:
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:
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.
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.
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.
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.
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.
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.
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.
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.
Moderator: please send security reports to security@cpanel.net
Please leave hyperbole out of the discussion.
Moderator: please send security reports to security@cpanel.net
Please leave hyperbole out of the discussion.
You're completely off-topic.
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".
You're completely off-topic.
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".
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.
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.
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 !
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 !
negotiating strong ciphers (AES256-GCM-SHA384 and
DHE-RSA-AES256-GCM-SHA384, for example)
negotiating strong ciphers (AES256-GCM-SHA384 and
DHE-RSA-AES256-GCM-SHA384, for example)
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?
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?
will yum upgrade interfere with cpanel upgrades? I thought it was best practice to let cpanel handle all os upgrades?
will yum upgrade interfere with cpanel upgrades? I thought it was best practice to let cpanel handle all os upgrades?
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.
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.
Kernel update are mostly done in a manual way.
Kernel update are mostly done in a manual way.
Should't this feature request be marked as resolved or something or is there still something to implement ?
Should't this feature request be marked as resolved or something or is there still something to implement ?
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.
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.
Replies have been locked on this page!