TLS Hardening
Emmanuel Dreyfus
This document presents TLS and how to make it secure enough, as of Spring 2014. Of course, all the information given here will become outdated with time. Protocols known to be secure will be cracked and will be replaced with better versions. Fortunately, we will see that there are ways to assess the current security of your setup, but this explains why you may have to do research beyond this document to get up-to-date knowledge on TLS security.
We will first introduce the TLS protocol and its underlying components: X.509 certificates, ciphers, and protocol versions. Next, we will have a look at TLS hardening for web servers, and how to plug various vulnerabilities: CRIME, BREACH, BEAST, session renegotiation, Heartbleed, and others. We will finally see how the know-how acquired on hardening web servers can be used for other protocols and tools such as Dovecot, Sendmail, SquirrelMail, RoundCube, and OpenVPN.
We assume you already maintain services that use TLS and have basic TCP/IP network knowledge. Some information will also be useful for the application developer.
1- An introduction to TLS
TLS stands for Transport Layer Security. It is an encryption and authentication layer that fits between the transport and application levels in the TCP/IP network stack. It was specified by IETF in 1999 as an enhancement over Netscape’s Secure Socket Layer (SSL), which is why we often see the SSL term used instead of TLS.
TLS is easy to add on top of any TCP service, and this is why it has grown so popular and become available for many protocols. For instance, HTTP can be used over TLS, using the well-known https:// URL. It works the same way for SMTP(S), IMAP(S), POP(S), LDAP(S), and so on.
1.1- X.509 certificates
The main goal of TLS is enforcing confidentiality and integrity. This cannot happen if the remote peer is not properly authenticated — who cares about having a secure channel if we do not know who we are speaking to? Attacks where an intruder slips between the two legitimate parties are known as Man in the Middle (MITM) attacks. In such a setup, a secure channel exists between one legitimate party and the intruder, and there is another secure channel between the intruder and the second legitimate party. The legitimate parties talk to each other, and the intruder sees all the traffic.
TLS attempts to authenticate the remote party using a Public Key Infrastructure (PKI). The idea is to use asymmetric cryptography, where each party has a private key capable of performing cryptographic signatures, and a public key, which can be used to verify a signature done by the associated private key. If a remote party is able to produce a public key validated signature for a nonce it was given, that proves it has the private key.
We are therefore able to authenticate a machine for which we alread know a public key. That leaves a problem to solve: how can we learn the public key for a machine we never connected to?
Enter X.509 certificates, which are also known as SSL certificates. An X.509 certificate is a public key, with data such as the machine name attached, and signed by a private key which is known as a Certificate Authority (CA). When connecting to a server using TLS, the server sends its X.509 certificate. Provided we have the public key of the CA that signed it, we can check the signature and have a hint the public key is the right one for the host we want to connect to, and nobody attempted to perform a MITM attack. Of course if the software has bugs, this check can be incomplete, and this is what happened to Apple [1] and GnuTLS [2] recently.
But this mechanism relies on the following assumption: we have the public key of the CA. How do we have it? For Unix command-line tools such as wget or curl, you need to install it first. This means it cannot work out of the box, but it guarantees a level of security, as you can choose what CA you trust. Note that some distributions provide curl and wget configured with a system-wide CA repository, hence your mileage may vary. Try downloading a well known https:// to discover the behavior of your system.
At the other end of the spectrum, we have web browsers and mail clients, which are bundled with the public keys for hundreds of commercial CA. Since any CA can sign a certificate for any machine name, this mean a web browser user trusts hundreds of CA, some of them running in oppressive jurisdictions where a government can compel the CA to sign a certificate for someone else’s machine. The CA can also be compromised by hackers [3], with the same result of having someone able to impersonate a machine during TLS authentication.
There is software to help defend against such attacks. For instance, Firefox has a Cert Patrol module that alerts you when the certificate of a web site is not the same as usual. That will let the user spot a MITM attack using a rogue certificate, except of course when connecting for the first time.
There is an even worse attack possible on X.509 certificates, when the cryptography used to build the certificate is too weak and can be cracked. For instance, a 512 bit RSA private key, which was once safe, is now vulnerable to factorization attacks [4], where the private key can be easily derived from the public key by computation. Once the private key is discovered, an attacker can just record TLS traffic and decipher it. We will see later that this can be avoided using Perfect Forward Secrecy (PFS), but even in that situation, an attacker can still decipher the traffic by running a MITM attack.
This leads us to the key length question: how long should it be? The longer it is, the longer it will take before it can be compromised. But a key too long means slower cryptographic operations, and perhaps software incompatibility. 1024 bit RSA is the next target, hence you should consider using 2048 bit RSA. 4096 bit RSA is even safer and will work most of the time, but there can be compatibility issues.
Huge key length is not always a guarantee for strong cryptography. Most cryptographic operations need a random source, and if an attacker can predict it, she may be able to decipher data or tamper with it. The private key generation step critically needs a good random generator. If your operating system warns you about low entropy for random source, make sure you fix it before generating private keys. Modern systems feed their random source from entropy gathered from various sources as they run. After a reboot, the entropy pool is low, but the system may be configured to save and restore that information across reboots. In virtualized setups, the virtual machine may be configured to grab entropy on startup from the hypervisor.
Sometimes you will learn about a random generator weakness in your Operating System. This can be the result of an implementation bug, which happened for instance to Debian [5], or a design mistake, for instance in the Dual Elliptic Curve random number generator. In the latter case, the mistake was made on purpose by the NSA, as a document leaked by former NSA contractor Edward Snowden taught us [6]. In both situations, you first need to fix the random number generation process, then regenerate keys, and finally think about what traffic may have been compromised.
While we are on the key factoring problem, it is worth mentioning the Shor algorithm, which allows quick factorization of decent sized keys. Fortunately this algorithm requires a quantum computer to operate, and as of today we are not aware of any implementation ofsuch a system. But if it appears some day, asymmetric cryptography as it is used in TLS will become almost as useless as a Caesar’s code [7] is today.
We talked about RSA keys. RSA is indeed the most used public key algorithm. It was invented by Rivest, Shamir and Adleman, hence the name. There are alternatives: DSA, and ECDSA. The latter is not yet widely supported, but it is interesting because it allows much faster operations, which is very valuable on embedded devices.
Key points
– Keep software up to date to avoid running known bugs in certificate validation and weak cryptography.
– Make sure your certificates are signed by a CA known by the client.
– Use certificate tracking software like Cert Patrol on the client.
– Make sure your system random generator is not predictable.
– Use RSA keys for compatibility; if possible, also use ECDSA keys.
– Use key length as long as possible considering performance and compatibility issues.
How-to
– create a 4096 bits RSA private key with appropriate file system permissions ( umask 077; openssl genrsa -out private.key 4096 )
– create a certificate request (to be sent to a CA for signature) openssl req -new -key private.key -out certificate.csr
– inspect a private key openssl rsa -text -in private.key
– inspect a certificate request openssl req -text -in certificate.csr
– inspect a certificate (signed from the CSR by a CA) openssl X.509 -text -in certificate.crt
1.2- Ciphers
TLS uses various algorithms known as ciphers to check data integrity and encrypt it. The specifications make many ciphers available, and implementations do not have to implement them all. The high level of cipher choice means we will have to make sure the right ones are used. This is important because, among ciphers, some are secure for today’s standards and some are trivial to crack. Ther are even null-ciphers, which perform no encryption at all. This is useful for debugging, but of course it should not be used for anything meant to be confidential.
The complete list of available ciphers for OpenSSL-based
software can be obtained by running the following command:
openssl ciphers -v
ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1
SRP-DSS-3DES-EDE-CBC-SHA SSLv3 Kx=SRP Au=DSS Enc=3DES(168) Mac=SHA1
SRP-RSA-3DES-EDE-CBC-SHA SSLv3 Kx=SRP Au=RSA Enc=3DES(168) Mac=SHA1
EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1
ECDH-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
PSK-3DES-EDE-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=3DES(168) Mac=SHA1
(…)
For the curious, each cipher has an IANA-registered number [8] used in the TLS protocol. On recent versions of OpenSSL, that number can be displayed using openssl ciphers -V
Cipher names, in the first column, contains hyphen-separated components.
We find here the encryption algorithm, with optional key length.
Here are a few examples:
DES The ancient Data Encryption Standard, with 56 bit keys
3DES Triple DES, which is equivalent to 168 bit keys
RC2 Ancient and insecure Rivest Cipher v2, with 40 bit keys
AES128 Modern Advanced Encryption Standard, with 128 bit keys
AES256 Modern Advanced Encryption Standard, with 256 bit keys
The key here is different from the private key used in an X.509 certificate. The latter uses asymmetric cryptography, which uses a lot of CPU power, while the former uses symmetric cryptography, which requires much less
processing. As the name suggests, symmetric cryptography uses a secret shared by both parties as the key, which may be renegotiated at regular intervals in time. Because cipher keys are of a different nature, their
lengths are much shorter than X.509 certificate key lengths, but that does not mean they are insecure.
Then we find the hash algorithm. Here are a few examples:
MD5 Ancient and now insecure Message Digest v5
SHA Soon to be insecure Secure Hash Algorithm v1
SHA384 Modern SHA v2 with 384 bit long hash
The cipher name can also specify the X.509 certificate private key flavor, if the cipher belongs to a specification recent enough to support something else than RSA:
RSA Well known Rivest, Shamir and Adleman
DSS Digital Signing Signature, used with DSA keys
ECDSA Elliptic Curve DSA
There are different families of ciphers and, within a family, a given cipher may have different modes of operation. This may or may not be reflected in the cipher name:
– Stream ciphers, whose last usable TLS cipher is RC4
– Block ciphers, which can operate in various modes: ECB, CBC, CTR, GCM…
The relevant modes for TLS are:
– CBC Older Cipher block chain, which is quite common with TLS
– GCM More secure Galois/Counter Mode, introduced with TLSv1.2.
Within the block ciphers, CBC mode provides encryption without integrity.
This means a CBC mode cipher always needs a helper Hash Message
Authentication Code (HMAC) function to enable integrity. GCM mode does not have this requirement since it provides both encryption and integrity.
And finally, the cipher may negotiate its private keys using a
Diffie-Hellman (DH) exchange:
EDH Diffie-Hellman (DH) Exchange
DHE Ephemeral EDH, which enables PFS (see below)
ECDH Newer and faster Elliptic Curve Diffie-Hellman
ECDHE Ephemeral ECDH, which enables PFS (see below)
DH exchange support is an optional but very valuable feature. It ensures that the symmetric cipher keys cannot be easily computed from stored TLS exchanges if the X.509 certificate private key is compromised in the future. That feature is called Perfect Forward Secrecy (PFS) or just Forward Secrecy (FS), since nothing is perfect. It is of no help for the ongoing TLS exchanges done after the X.509 certificate private key is compromised, but it protects stored communications, which is interesting since we know the NSA stores everything it can.
Some clients only implement ECDHE, hence it is desirable to support it; although, it may require quite recent versions of software, as we will see later for Sendmail. For Apache, the latest 2.2.x will support it. And while we deal with Elliptic Curve cryptography, it is important to note that the algorithm may use different constants over which the administrator has no control. Also, some values may be less safe than others [9], although we do not know practical attacks on that front yet.
Client and server negotiate a common cipher, which should obviously be known by both implementations. On both sides, the software may allow an ordered cipher suite to be configured. For instance, Apache does this through the SSLCipherSuite directive. The client setting usually prevails, unless the server requests otherwise. This is achieved on Apache using the SSLHonorCipherOrder directive.
In OpenSSL-based software the cipher suite syntax is a column-separated list of cipher names, with some additional syntax explained in the openssl_ciphers(1) man page. Here are a few examples:
– ECDH selects all ECDHE-enabled ciphers
– HIGH selects all high security ciphers (128 bit key length and beyond)
– TLSv1 selects all TLSv1 ciphers
– MD5 selects all ciphers using MD5
The openssl ciphers command can be used to see all the ciphers enabled by a particular cipher suite. Here is an example openssl ciphers ECDH:!RC4:!MD5:!NULL
A good cipher suite specification favors the high security ciphers, forbids the insecure, and allows enough ciphers so that any client can connect. Here is a cipher suite specification that favors PFS and ciphers with 128 bit keys and beyond, while remaining compatible with all modern web browsers:
ECDH@STRENGTH:DH@STRENGTH:
HIGH:!RC4:!MD5:!DES:!aNULL:!eNULL
Key points
– Make sure server cipher setting prevails over the client’s setting.
– Configure cipher suite server-side to disable insecure ciphers.
– For the sake of interoperability, do not restrict available ciphers too much.
– Favor ciphers that can do PFS, and ciphers with longer keys.
How-to
– Compare two cipher lists
openssl ciphers ALL:-NULL |tr ‘:’ ‘\n’ > /tmp/1
openssl ciphers ALL:!aNULL:!eNULL |tr ‘:’ ‘\n’ > /tmp/2
diff /tmp/1 /tmp/2|less
– Dump all ciphers supported by a service (the sslscan tool is an alternative)
for c in `openssl ciphers ALL|tr ‘:’ ‘\n’`; do
echo “”|openssl s_client -cipher $c -connect
www.example.net:443 2>/dev/null
done | awk ‘/Cipher.*:/{print $3}’
#reference page :
http://bsdmag.org/tls/
