4

For PCI compliance I was required to protect our server against BEAST attacks. While I have correctly configured the apache / openssl settings to pass a scan, these settings have effectively limited the client browsers that can securely transact on the sites https side.

We are using Centos 6.5 Final, OpenSSL 1.0.1e-fips 11 Feb 2013

I cannot find any information on how to update or add either specific or all ciphers to OpenSSL.

Question 1: Are cipher suites distributed within the OpenSSL program OR are ciphers suites add-ons?, if they are add-ons how do you update them?

Question 2: How do you manually update to the latest OpenSSL version? Currently openssl-1.0.1i ? (CentOS states it is already the latest - which it is not.)

sr_1436048
  • 187

2 Answers2

2

Question 1: Are cipher suites distributed within the OpenSSL program OR are ciphers suites add-ons?, if they are add-ons how do you update them?

The cipher suites are distributed as part of OpenSSL, so you'll have to upgrade that package to gain access to new ones.

Question 2: How do you manually update to the latest OpenSSL version? Currently openssl-1.0.1i ? (CentOS states it is already the latest - which it is not.)

You can either grab the source RPM from a Fedora repository and build it on CentOS 6.5 or make use of one of the pre-built RPMs that are floating around on the internet for CentOS 6.5.

I'd do the latter since CentOS 6.5 is a fairly large install base, there has to be others dealing with the issue that have made that package already available.

Also you might want to familiarize yourself with the backporting of fixes that Red Hat has done with OpenSSL. Given CentOS' lineage, these are included.

excerpt from this answer

The fix for the heartbleed vulnerability has been backported to 1.0.1e-16 by Red Hat for Enterprise Linux see, and this is therefore the official fix that CentOS ships.

Community
  • 1
slm
  • 369,824
  • Thanks for the quick reply, my system is protected against the heartbleed; I'm more concerned about getting stronger ciphers since I've essentially limited the amount of browsers that can access the secure side of the site. Also thanks for confirming that its part of a the package and not an add-on. – sr_1436048 Sep 05 '14 at 11:10
  • FYI - Assuming you have applications that are using OpenSSL (Apache, Nginx, Jetty, etc.). In those cases you can further restrict which cipher suites are used within those applications, – slm Sep 05 '14 at 11:17
  • Can you confirm that if the system is completely up to date (yum update) and no packages are marked for upgrades that the BEAST vulnerability would be addressed through the backporting and thus I'm just going about all this for nothing? – sr_1436048 Sep 05 '14 at 15:06
  • http://lxer.com/module/newswire/view/195716/. You can confirm this too looking at the changelog for openssl: rpm -q --changelog openssl | less. – slm Sep 05 '14 at 16:19
  • 1
    Thanks for that; CVE-2011-3389 isn't listed so I guess I'll have to do some digging. – sr_1436048 Sep 05 '14 at 17:52
1

OpenSSL is a set of tools and libraries. The applications that offer TLS encrypted services use those libraries (unless they use gnutls or Java libraries, which are also not uncommon).

The ciphersuites are implemented in those libraries. If you need newer ciphersuites, you have to update the library. If your OS' repository doesn't have anything newer, maybe changing your repository URLs to an alternative site or higher OS version might also do the trick (I've done that successfully with Debian) but I don't know whether that can be done with CentOS. Of course, you might also be able to find precompiled packages or compile for yourself.

If you want to restrict the ciphers for the apache webserver, Apache's ssl.conf is the place to go. If on the other hand you want to change ciphers for postfix, the tls_high_cipherlist setting (in conjunction with smtp(d)_tls_mandatory_ciphers=high) is where you set the ciphers.

It does make sense to have this configuration application (=service) specific, since what is deemed insecure for one service might be still acceptable for another.

Alexander Stumpf
  • 83