Secure SSL Against Today's Threats

Monday Sep 30th 2013 by Paul Rubens

A variety of threats—including NSA surveillance—endanger SSL security today. Learn how to mitigate the risks and protect your sessions' privacy, now and for the foreseeable future.

Beast, Crime, Breach, Lucky 13: In the last two years, we've seen a seemingly endless stream of attacks against the security provided by Secure Sockets Layer (SSL)/Transport Layer Security (TLS).

Although these attacks pose fairly limited risk in most cases, they do make life uncomfortable for anyone responsible for a server offering SSL or TLS, the protocol that replaced it.

Here's an example of one of the dilemmas administrators face. The Beast attack exposed a weakness in cypher block chaining (CBC), allowing a determined attacker to compromise the security of TLS 1.0.

To mitigate the risk, administrators were recommended to reconfigure their servers so that the first-choice cipher suite used during a TLS session would be RC4. That's because RC4 doesn't use CBC. About 50% of TLS sessions now use RC4, according to SSL Labs.

To date, most browsers—apart from Safari–have been updated to mitigate the Beast attack, although older browsers are still in use.

But here's the problem: Back in March of this year, a group of researchers revealed a weakness in RC4 and a theoretical way to exploit it.

So should servers be reconfigured again, favoring cipher suites that use CBC over RC4?

"We have finally declared that Beast is mitigated on the client side, so server side mitigation is no longer required," says Ivan Ristic, an SSL expert and director of engineering at security company Qualys. Since no mitigation currently exists for the RC4 vulnerability, administrators should start using CBC suites again rather that RC4, he concludes.

In fact, however, there's a better solution than that, and that is to favor Galois/CounterMode (GCM) ciphers, for which no vulnerabilities have yet been discovered. But, once again, there's a problem. GCM ciphers are only realistically available in the latest version of TLS, TLS 1.2. "It's simply not practical to add GCM ciphers to older versions of SSL or TLS," Ristic explains.

Why don't server administrators just upgrade to the latest version? The answer is that this is no trivial task, evidenced by the fact that although the TLS 1.2 specification was released in 2008, less than 18 percent of servers currently run it, according to SSL Labs. Upgrading to it often means upgrading the underlying server operating system, and that's something that most organizations do on a schedule, not in response to a mainly theoretical risk to the security of its network transactions.

How urgent is it to move away from RC4? "If you can't use GCM, then it doesn't really matter, as RC4 and Beast are equally unlikely to be exploited," says Ristic. "Any CBC suite will probably be just fine for the moment," he adds.

What about the Crime and Breach attacks? Crime has largely been mitigated in updated browsers, and you can actually prevent it by turning off compression during the protocol negotiations at the start of an SSL/TLS session. Breach is more difficult. Check out Ristic's recommendations here.

Perfect Forward Secrecy

Once they've dealt with these issues, administrators should focus on offering Perfect Forward Secrecy for their TLS sessions, Ristic believes.

Here's the issue: TLS sessions are usually encrypted using symmetric keys created and exchanged using asymmetric (PKI) encryption. Essentially, the server gives the client its TLS certificate, which has its public key, and the client uses the public key to encrypt and return the symmetric key for use during the session. This symmetric key is decrypted by the server using its private key. The whole setup is known as an RSA key exchange.

Because the server's private key protects the symmetric key, this means that the private key has to remain secret forever. If it ever comes to light, the entire TLS session could be decrypted by anyone who has intercepted and stored the encrypted traffic.

Why does this matter? Because of the NSA's PRISM project. The NSA could be archiving the traffic generated by an entire session, and even if it doesn't have access to the server's SSL/TLS certificate today, it's not beyond the realms of possibility that the NSA could get hold of it in the future. The NSA may, in the future, even be able to demand that organizations hand over their server certificates once they have expired.

If the NSA gets access to expired certificates, it could go through archived traffic and decrypt the sessions. And even if you are not worried about the NSA accessing your traffic, what about foreign government agencies, which may be doing the same thing?

Fortunately, you can prevent this. Use a key exchange mechanism called the Diffie-Hellman exchange (DHE) algorithm, or the version developed for use with Elliptic Curve cryptography, called the ECDHE algorithm. DHE is slower than ECDHE, and both are slower than RSA.

These Diffie-Hellman exchange mechanisms result in sessions keys only obtainable by the two parties involved in the exchange. At the end of the session, the keys are destroyed. They can't be recreated even if the NSA or anyone else ever gets access to the server's private key.

Ristic says that most major modern browsers support ECDHE. To implement Forward Secrecy on your server, you need to configure it to prioritize cipher suites such as:


But before you go and configure your server for Forward Secrecy, understand the drawbacks. "Many network security devices, for example, can be configured to decrypt communication and inspect traffic when given servers' private keys," Ristic points out. But "without this capability, passive IDS/IPS and WAF devices have no visibility into the traffic and thus provide no protection," he adds.

Strict Transport Security

SSL/TLS administrators should also consider two other things. The first of these is Strict Transport Security. Enabling it involves an https response header configuration change that ensures that clients only connect using SSL/TLS and that automatically converts attempts to connect by http to https, preventing connections if the server certificate has expired.

Strict Transport Security also defeats attacks such as the SSL stripping attack that pushes secure https connections back to insecure http ones. "Many administrators don't know about it, but Strict Transport Security is easy to deploy," says Ristic. The only circumstance when it may not be appropriate is when traffic is delivered through content delivery networks, he says, because of the cost of using SSL/TLS over these networks.

OWASP provides links to instructions for configuring Strict Transport Security for servers including Apache, NGINX, Lighttpd, HTTPd and IIS on its Strict Transport Security pages.

Public key pinning

The second thing to consider is public key pinning, an idea that's in its infancy but has the potential to become important in the future. Put simply, public key pinning enables an SSL/TLS server to tell browsers to only trust certificates issued by a particular Certificate Authority. That means that if you buy your certificates from Verisign, browsers should only trust certificates issued by that company, and not by any of the other authorities that may be trusted by your browser. That means that if a certificate authority becomes compromised, as Diginotar famously was, then browsers would not be fooled, even if that authority issued a certificate in your organization's name.

For more advice about securing SSL/TLS connections, Qualys/SSL Labs publishes a regularly updated list of best practices.

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved