Seven Common SSL Pitfallsby John Viega, Matt Messier, Pravir Chandra, coauthors of Network Security with OpenSSL
SSL is an excellent protocol. Like many tools, it is effective if you know how to use it well, but it is also easy to misuse. If you are deploying SSL, there are many pitfalls to be aware of, but with a little work, most can be avoided. In this article, we discuss the seven most common pitfalls when deploying SSL-enabled applications with OpenSSL.
1. Efficiency versus Security
A common complaint about SSL (and its successor, TLS) is that it's slow. Yes, it's a lot slower than a traditional, unsecured TCP/IP connection. However, any inefficiencies that exist with SSL are a direct result of it providing adequate security. Nonetheless, this problem leads many people to avoid using SSL altogether.
Most of the inefficiencies in SSL occur at connection establishment. The actual encrypted data exchange isn't noticeably slow. Therefore, if your applications don't need to make more than a few dozen new connections per second, you shouldn't be worried about efficiency with SSL.
There are ways to boost the speed of SSL. One way is to use session caching, which removes the most expensive part of the connection process for those clients who have previously connected. Another way is to purchase cryptographic-acceleration hardware. OpenSSL supports most such hardware. Finally, it's possible to offload SSL connections to multiple machines using load balancing.
2. Keys in the Clear.
In a typical SSL installation, the server maintains credentials so that clients can authenticate the server. In addition to presenting a certificate at connection time, the server also maintains a private key, which is necessary for establishing that the server presenting a certificate is actually presenting its own certificate.
That private key needs to live somewhere on the server, and needs to be protected from prying eyes. If an attacker breaks into a machine, stealing the key could allow them to impersonate the server, so regular file permissions may not be enough. Cryptographic-acceleration cards will generally store the key in hardware, making it unavailable to the actual computer.
If such an option isn't feasible, then you can either leave the key unencrypted on disk, or encrypt it using a passphrase, which needs to be typed in at program startup. The former solution makes an attacker's job easier, but at least the program can start up unattended.
3. Recovering Recorded Sessions.
If a server's private key does manage to get stolen, it can often be used to decrypt all past communication with the server, assuming the previous communication was recorded. The solution to this problem is to use SSL's facility for ephemeral keying. With ephemeral keying, a temporary key pair is generated when you create a new SSL session. This is then used for key exchange, and is subsequently destroyed. By using ephemeral keying, it is possible to achieve forward secrecy, meaning that, if a session-specific key is compromised, messages encrypted with previous session keys will not also be compromised.
4. Bad Server Credentials.
A server's private key can be stolen. Additionally, certificates sometimes go into circulation that are fraudulent. For example, in early 2001, there were two certificates floating around that were purported to belong to Microsoft, when in reality, they did not.
SSL has a mechanism for thwarting these problems: Certificate Revocation Lists (CRL). Once the Certification Authority (such as VeriSign) learns that a certificate has been stolen or is otherwise invalid, the Certification Authority adds the certificate's serial number to a CRL. The client can access CRLs and validate them using the Certificate Authority's certificate.
Not using CRLs leaves an application open to serious vulnerability. However, CRLs don't completely solve the problem. The biggest problem with CRLs is that it can take time for an organization to realize that a key is stolen and to notify the Certification Authority. Then the CRL needs to be published, and it needs to make its way to the client. All of this can take a long time, and until it's all completed, exploitation is possible. There are other issues with deploying CRLs. See our book Network Security with OpenSSL for more information on CRLs.
Pages: 1, 2