This article was originally published on the Red Hat Customer Portal. The information may no longer be current.

Background

In the mid-1990s Secure Sockets Layer (SSL) was introduced for securing network communications.  The released version, version 2, contained several security holes and was quickly updated to version 3.  Transport Layer Security (TLS) became the next generation of PKI-based network encryption and was released in January of 1999.

Since the release of TLSv1, many changes have happened to both the development of TLS and the known attacks against the cryptographic protocol.  TLSv1.1 and TLSv1.2 were both released in the mid to late 2000s which fixed many problems seen in TLSv1 but, unfortunately, adoption was meager at best.  This left the door open to many attacks against the protocols in use (namely SSLv3 and TLSv1) including BEAST, CRIME, various cipher renegotiation and rollback attacks, and attacks on the RC4 encryption cipher.

Today, TLSv1.1 and TLSv1.2 are available in most products and fix many of the attack vectors we know SSL and TLSv1 are susceptible to.

BEAST

BEAST is an attack vector against TLS and, specifically, the symmetric encryption that occurs within the protocol.  While various fixes were put in place to help mitigate this attack (including turning off data compression) the one sure fix was to use a stream cipher instead of a block cipher.

RC4 Vulnerabilities

RC4 is the only stream cipher available for use in SSL and TLS and, thus, the only choice for mitigating the BEAST attack even though it has known weaknesses.  System administrators rushed to implement RC4 as their preferred cipher suite, sometimes eliminating all others in the process.  Unfortunately it was later determined that RC4 could be broken using an attack that was described as "feasible".  By this time, most Internet browsers had already implemented a fix for the BEAST  (n/n-1) vulnerability but with websites nearly forcing users to use the broken RC4 encryption cipher which puts users at risk.

Updates for RHEL 6.5

TLSv1.1 has fixed issues regarding BEAST and other attack vectors and TLSv1.2 has gone further by removing aging ciphers including MD5 and mostly removes SHA-1 algorithms implementations.  This is important since NIST has recommended that SHA-1, and prior hash functions, be discontinued after 2013.

As of the recent release of Red Hat Enterprise Linux (RHEL) 6.5 TLSv1.1 and TLSv1.2 are now available using OpenSSL 1.0.1.  That means that your Apache, and other implementations using OpenSSL, can start using TLSv1.1 and TLSv1.2 immediately!

Server

To utilize TLSv1.1 and TLSv1.2 in Apache a minor change to your SSLProtocol setting needs to be made.  By using either SSLProtocol all or SSLProtocol +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2 (for httpd version 2.2.23 and later) in your ssl.conf you'll be able to enable those new protocols.  By using the latter setting you'll be able to specify exactly which protocols you wish to use.

While we're in the ssl.conf file it's probably a good idea to take a look at the ciphers you are using.  The SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5 line should probably read something more like SSLCipherSuite HIGH:!aNULL:!MD5:!RC4.  This will remove ciphers that are more risky.

Client

TLSv1.1 and TLSv1.2 is now being tested in Mozilla's Firefox (version 25).  While not on by default, these protocols can be enabled by changing the security.tls.version.max configuration to "3" in the about:config settings.

So you can see that with a few minor modifications to your Apache configuration you too can be taking advantage of the latest encryption protocols.  This will go along way in protecting data being exchanged over your network or the Internet.


執筆者紹介

Red Hat is the world’s leading provider of enterprise open source software solutions, using a community-powered approach to deliver reliable and high-performing Linux, hybrid cloud, container, and Kubernetes technologies.

Read full bio