In our previous post, we discussed the different protocols for SSL and TLS, and how we can improve security by disabling older, less secure protocols and enabling newer, more secure ones. Today, we will talk about ciphers, which is one of the key pieces to making these protocols work.
Here’s a quick refresher: In daily conversation, SSL is often used as a catchall phrase for both SSL and TLS protocols. However, TLS is a more secure option for data transmission. When Secret Server connects with a user’s browser, a “handshake” or negotiation happens between the server and browser to decide whether to use SSL or TLS and which version of the protocol will be used.
The negotiation phase includes a step to decide which ciphers, or what cipher suite, will be used. TLS sessions use multiple ciphers, and each performs a different type of operation, such as hashing, signing, or encrypting.
The security of ciphers can vary and some ciphers are supported only on a particular version of TLS. Also, Microsoft’s implementation of TLS in their SChannel library complicates the matter slightly because Microsoft only allows certain ciphers to be used with certain types of certificates. For simplicity, we’ll assume our web server’s HTTPS certificate is a standard RSA 2048 certificate with SHA1 as the signature hash algorithm and with TLS 1.0, 1.1, and 1.2 enabled.
One side effect of configuring protocols and ciphers on Windows is that it makes the changes for all software that relies on SChannel, not just Internet Information Services (IIS). This can make it tricky to enforce strong cipher suites for clients connecting to IIS without also impacting other software on the server, such as Microsoft SQL Server.
Therefore, we recommend making all cipher configuration changes in a staging environment to determine the impact on all software. The cipher suites you choose to support will depend on the clients. If you can control which clients are connecting to the server, then it can be assumed which ciphers are safe to turn off. If you have little or no control over the clients, then some older cipher suites must still be supported for compatibility reasons.
A typical TLS handshake goes something like this:
During the handshake, the server and client are agreeing upon a master Secret.
Here are the details for how this happens: First, the client generates a pre-master Secret, which it encrypts with the server’s RSA public key during the Client Key Exchange step. Next, the server uses the RSA private key to decrypt this pre-master Secret. Finally, the client and server use the pre-master Secret, along with other information that was transmitted during the Client Hello and Server Hello steps, to derive the master key.
Once the master key is created, it is used to generate a session key for all communications during that session. This session key is a symmetric algorithm such as AES. This poses one potentially big problem. If an attacker (or in this case, we can all him a man-in-the-middle) were recording all of the encrypted traffic sent between the client and server, the attacker would be able to decrypt the TLS session if the server’s private key was ever leaked.
The secrecy problem above can be avoided by using what is called perfect forward secrecy. This is done by using an ephemeral Diffie-Hellman key exchange instead of using an RSA key exchange. The ephemeral key is only good for the duration of the TLS session, which means that once the session is over, the session key is no longer usable. Now, even if the session was recorded via a man-in-the-middle, there is no key that could later be found and used to decrypt the session.
While Ephemeral Diffie-Hellman (or DHE) provides strong security, it has a big impact on performance. Because the server is now generating these ephemeral keys for each session, the handshake takes significantly longer.
To improve the speed of the Diffie-Hellman process, you can use Elliptic Curve (together, this is called ECDHE). Although ECDHE doesn’t perform as well as a static RSA key, it is comparable when used on modestly powered servers. The downside is ECDHE is relatively new. While supported by new versions of desktop browsers, it is not supported by some older smartphones and browsers.
In the case of Microsoft Windows, ECDHE requires TLS 1.2 and Windows Server 2012.
The symmetric cipher is the algorithm used to encrypt data in the TLS session. There have been many advances with the symmetric cipher over the past few years, including authenticated ciphers such as AES in GCM mode. The strength of the symmetric cipher is important when considering which cipher suites to support.
RC4
The RC4 cipher is one of the oldest ciphers still used in TLS today. Being a stream cipher, RC4 provides good performance, which is crucial in small computing devices, but more secure methods of encryption, such as AES, are recommended.
Although RC4 saw an increase in popularity because it was not affected by the recent BEAST vulnerability, it should still be phased out. RC4 does not provide the same level of strength as ciphers that were affected by BEAST, and BEAST has since been fixed in most clients.
There are still many clients that don’t support anything stronger than RC4, so before phasing it out, manually audit its use. This can be done by disabling RC4 in an isolated environment and determining what no longer works.
AES
The AES algorithm is the next most popular and offers superior strength over RC4 and others. Its most common mode of operation is Cipher-Block-Chaining (CBC), and a fairly new mode of operation is Galois/Counter Mode (GCM). AES-GCM is recommended over AES-CBC because it is an authenticated cipher. An authenticated cipher provides message integrity in the symmetric algorithm itself, whereas non-authenticated ciphers need to rely on signed hashes for message integrity. GCM is fairly new, but all modern clients should support it. However, keep in mind that for Windows Server, GCM can only be used in Windows Server 2012.
AES comes with three different key sizes: 128, 192, and 256 bit. All of these are safe for use in production, with 128 being the most common. The current belief is that 128-bit provides adequate security, and the additional overhead required for 256-bit may not be worth it. However, 256-bit is used in the wild.
It’s recommended to support AES-CBC and GCM cipher suites, and both 128 and 256 key variants. The order you prefer depends. It is common to set a preference in this order: AES-GCM-128, AES-GCM-256, AES-CBC-128, and AES-CBC-256.
TripleDES
TripleDES, or 3DES, is an older cipher that has support back to Internet Explorer 6 on Windows XP. Because it is not as strong as AES, it’s recommended that 3DES be placed behind AES in symmetric cipher preference. 3DES does not commonly operate in any mode other than CBC.
AES-GCM is an authenticated algorithm and can both encrypt and protect the integrity of the message. However, AES-CBC and many other encryption methods cannot protect integrity. For this reason, signed hashes are used in addition to the encryption method.
The two most common types of hashes are MD5 and SHA, with SHA having several variants. The hash computes a digest of the message, which is then signed by the server or client to verify its integrity.
MD5, while quite popular, is in the process of being phased out. MD5 is often still supported with other older ciphers in cipher suites, such as RC4. Notably, MD5 is not FIPS compliant, which may be a deciding factor for supporting it, for some.
SHA1 is the most common hashing algorithm and is currently considered safe for production use. However, the newer SHA256 is actively replacing SHA1. Supporting both is recommended, with SHA256 coming before SHA1 in preference. SHA256 does impact performance, but this is considered negligible compared with its security improvements.
Given everything above, it is now possible to determine the preferred cipher suite order. This order can be set in Windows Server with Group Policy under:
Computer Configuration > Administrative Templates > Network > SSL Configuration Settings > SSL Cipher Suite Order setting.
Cipher suite configurations look like this:
TLS_RSA_WITH_AES_128_CBC_SHA256
This means that an RSA key exchange is used in conjunction with AES-128-CBC (the symmetric cipher) and SHA256 hashing is used for message authentication.
The cipher order decides, starting from the top, which ciphers will be preferred by the server. During the negotiation, the server will select a cipher that meets the client and the server requirements by offering them in this order. Here is an example cipher order that places newer, more secure ciphers, at the top:
While the above sets the order of preferred cipher suites, excluding a cipher from the list does not prevent it from being used. For example, RC4 is not included in the approved list above, but if it is not disabled, it could be used if the client insists on using it. To permanently disable older ciphers, a registry change is required. You can do this by adding subkeys to the registry key:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphers
Adding a subkey with the name “RC4 128/128” and putting a DWORD named “Enabled” in the new subkey with a value of 0x0 causes RC4 128/128 to become disabled. A nice advantage to these registry changes is they take effect immediately without restarting anything.
While the above disables RC4 128/128, there are other variants of RC4 to disable such as RC4 64/128 and RC4 56/128. All of these values and more are documented in a Microsoft Knowledge Base article here: http://support.microsoft.com/kb/245030
Next, we will focus on the SSL certificate itself. While most SSL certificates have not changed lately, there is a need to improve their security, such as moving to SHA2 algorithms for the signature algorithm and moving from RSA to ECDSA.
Read All Parts:
SSL: Beyond the Basics
SSL: Beyond the Basics Part 2: Ciphers
SSL: Beyond the Basics Part 3: Certificates
SSL: Beyond the Basics Part 4: Strict Transport Security