How to Set Up Strong SSL Security on Servers that Require Encryption

This page does not intent to educate the visitor on the inner workings of SSL. If you are reading this page, it is assumed that you have some knowledge of how SSL works. The terms, Secure Socket Layer (SSL) and Transport Layer Security (TLS) are often used interchangeably. In fact, SSL v3.1 is equivalent to TLS v1.0. However, different versions of SSL and TLS are supported by modern web browsers and by most modern web frameworks and platforms. For the purposes of this document we will refer to the technology generically as SSL/TLS.

Only Support Strong Protocols

SSL/TLS is a collection of protocols. Historically, several weaknesses have been identified with earlier SSL protocols (specifically SSLv2 and SSLv3), hence SSL versions 1, 2, and 3 should not longer be used. The best practice for transport layer protection is to only provide support for the TLS protocols – TLS 1.0, TLS 1.1 and TLS 1.2. This configuration will provide maximum protection against skilled and determined attackers and is appropriate for applications handling sensitive data or performing critical operations. Nearly all modern browsers support at least TLS 1.0. As of February 2014, contemporary browsers (Chrome v20+, Firefox v27+, IE v8+, Opera v10+, and Safari v5+) support TLS 1.1 and TLS 1.2. You should provide support for TLS 1.1 and TLS 1.2 to accommodate clients that support these protocols. The client and server (usually) negotiate the best protocol that is supported on both sides. TLS 1.0 is still widely used as the ‘best’ protocol by a lot of browsers that are not patched to the very latest version. However, TLS 1.0 suffers from CBC Chaining attacks and Padding Oracle attacks and should only be used after risk analysis and acceptance. PCI DSS 3.2 prohibits the use of TLS 1.0 after June 30, 2018 (earlier requirements to do so by June 30, 2016 were postponed).
Support the extension ‘TLS_FALLBACK_SCSV’ to prevent all unnecessary fallbacks from a higher to a lower protocol version, for more details about this see RFC7507. Keep in mind that, under no circumstances either SSLv2 or SSLv3 should be enabled as a protocol selection. From the risk and security standpoint, the SSLv2 protocol is broken and does not provide adequate transport layer protection. SSLv3 had been known for weaknesses which severely compromise the channel’s security long before the ‘POODLE’ Bug finally stopped to tolerate this protocol by October 2014. Switching off SSLv3 terminates the support of legacy browsers like IE6/XP and elder (in their default configuration).

Do Not Use Wildcard Certificates

You should refrain from using wildcard certificates. Though they are expedient at circumventing annoying user prompts, they also violate the principle of least privilege and asks the user to trust all machines, including developer’s machines, the secretary’s machine in the lobby and the sign-in kiosk. Obtaining access to the private key is left as an exercise for the attacker, but its made much easier when stored on the file system unprotected.
Statistics indicate wildcard certificates have a 4.4% share, so the practice is not standard for public facing hosts. Keep in mind that wildcard certificates violate EV Certificate Guidelines.

Use an Appropriate CA

A web application visitor must never be presented with a warning that the certificate was signed by an unknown or untrusted authority. Visitors must have access to the public certificate of the certification authority which issued the server’s certificate. For Internet accessible websites, the most effective method of achieving this goal is to purchase the TLS certificate from a recognized certification authority. Popular Internet browsers already contain the public certificates of these recognized certification authorities. Utilize controls to protect the private key and ensure that only authorized individuals have the ability to sign certificates. The use of self signed certificates is never acceptable. Self signed certificates negate the benefit of end-point authentication and also significantly decrease the ability for an individual to detect a man-in-the-middle attack.

Use a Certificate That Supports Required Domain Names

A user should never be presented with a certificate error, including prompts to reconcile domain or hostname mismatches, or expired certificates. If the application is available at both https://www.example.com and https://example.com then an appropriate certificate, or certificates, must be presented to accommodate the situation. The presence of certificate errors desensitizes users to TLS error messages and increases the possibility that an attacker could launch a convincing phishing or man-in-the-middle attack.
For example, consider a web application accessible at https://abc.example.com and https://xyz.example.com. One certificate should be acquired for the host or server abc.example.com; and a second certificate for host or server xyz.example.com. In both cases, the hostname would be present in the Subject’s Common Name (CN). Alternatively, the Subject Alternate Names (SANs) can be used to provide a specific listing of multiple names where the certificate is valid. In the example above, the certificate could list the Subject’s CN as example.com, and list two SANs: abc.example.com and xyz.example.com. These certificates are sometimes referred to as “multiple domain certificates”.

Do Not Use RFC 1918 Addresses (Private Addresses) in Certificates

RFC 1918 is Address Allocation for Private Internets. Private addresses are Internet Assigned Numbers Authority (IANA) reserved and include 192.168/16, 172.16/12, and 10/8. Certificates issued with private addresses violate EV Certificate Guidelines and should not be used.

Use Fully Qualified Names in Certificates

Use fully qualified names in the DNS name field, and do not use unqualifed names (e.g., ‘localhost’), or private IP addresses (e.g., 192.168.1.1) in the DNS name field. Unqualifed names, local names, or private IP addresses violate the certificate specification.

Be aware of the SHA-1 deprecation

In order to avoid presenting end users with progressive certificate warnings, organizations must proactively address the browser vendor’s push for SHA-1 deprecation. The Google Chrome plan is probably the most specific and aggressive at this point: Gradually sunsetting SHA-1. Generally speaking, all SHA-1 certificates must have expired before 1/1/2017.

Always Install/Provide All Needed Certificates

When a web visitor receives a web server’s certificate, the certificate must be validated back to a trusted root certification authority. This is known as path validation. There can be one or more intermediate certificates in between the end-entity (server or host) certificate and root certificate. In addition to validating both endpoints, the web visitor’ session will also have to validate all intermediate certificates. Validating all intermediate certificates can be tricky because the visitor’s browser may not have them locally. This is a well-known PKI issue called the “Which Directory?” problem. To avoid the “Which Directory?” problem, a [well installed] server should provide the user with all required certificates used in a path validation.

Only Support Secure Renegotiations

A design weakness in TLS, identified as CVE-2009-3555, allows an attacker to inject a plaintext of his choice into a TLS session of a victim. In the HTTPS context the attacker might be able to inject his own HTTP requests on behalf of the victim. The issue can be mitigated either by disabling support for TLS renegotiations or by supporting only renegotiations compliant with RFC 5746. All modern browsers have been updated to comply with this RFC but your server’s SSL configuration must do its part to satisfy compliance.

Disable Compression

Compression Ratio Info-leak Made Easy (CRIME) classified as CVE-2012-4929, is an exploit against the data compression scheme used by the TLS and SPDY protocols. The exploit allows an adversary to recover user authentication cookies from HTTPS. The recovered cookie can be subsequently used for session hijacking attacks.

Use Strong Keys & Protect Them

The private key used to generate the cipher key must be sufficiently strong for the anticipated lifetime of the private key and corresponding certificate. The current best practice is to select a key size of at least 2048 bits. Additional information on key lifetimes and comparable key strengths can be found in [1], NIST SP 800-57. In addition, the private key must be stored in a location that is protected from unauthorized access.

Update your Crypto Libraries

Only use versions of crypto libraries that are supported (eg. openssl). Watch out for related SSL vulnerabilities (e.g. via cvedetails.com) and update your crypto libraries on a regular basis.

Use Forward Secrecy

(Perfect) Forward Secrecy, abreviated as PFS, is a mechanism inherent is SSL/TLS designed to ensure the integrity of a session key in the event that a long-term key is compromised. PFS accomplishes this by enforcing the derivation of a new key for each and every session. The concept behind it is simple: client and server negotiate a key that never hits the wire, and is destroyed at the end of the SSL/TLS session. The RSA private key from the server is used to sign a Diffie-Hellman key exchange between the client and the server. The pre-master key obtained from the Diffie-Hellman handshake is then used for encryption. Since the pre-master key is specific to a connection between a client and a server, and used only for a limited amount of time, it is called Ephemeral. If an attacker gets a hold of the server’s private key, it will not be able to decrypt past communications. The private key is only used to sign the DH handshake, which does not reveal the pre-master key. Diffie-Hellman ensures that the pre-master keys never leave the client and the server, and cannot be intercepted by a MITM attack. The cipher suites that provide Perfect Forward Secrecy are those that use an ephemeral form of the Diffie-Hellman key exchange. Their disadvantage is their overhead, which can be improved by using the elliptic curve variants.

Only Support Strong Cryptographic Ciphers

Each protocol in the TLS family (TLSv1.0, TLSv1.1, TLSv1.2, etc) contains ciphering suites . As of TLS 1.2, there is support for over 300 suites (320+ and counting), including national vanity cipher suites. The strength of the encryption used within a TLS session is determined by the encryption cipher negotiated between the server and the browser. In order to ensure that only strong cryptographic ciphers are selected, the server must be modified to disable the use of weak ciphers and to configure the ciphers in an adequate order. It is recommended to configure the server to only support strong ciphers and to use sufficiently large key sizes. However, the challenge would be disabling weak ciphers without disabling legacy browsers and bots that have to be supported. Generally, the idea is to find the best compromise. In general, the following should be observed when enabling and selecting cipher suites:

• Set your settings so that the cipher order is activated by the server, e.g. ‘SSLHonorCipherOrder On’
• Disable cipher suites that do not offer encryption (eNULL, NULL)
• Disable cipher suites that do not offer authentication – specifically aNULL (aNULL includes anonymous cipher suites ADH [Anonymous Diffie-Hellman] and AECDH [Anonymous Elliptic Curve Diffie Hellman]).
• Prefer ciphers that support ‘Forward Secrecy’
• Keep in mind that it is not recommended to use 3DES together with perfect forward secrecy ciphers (DHE, ECDHE). To be safe, disable 3DES completely.
• Priorize the ciphers by the sizes of the cipher and the MAC
• Use SHA1 or above for digests, prefer SHA2 (or equivalent)
• Disable export level ciphers (EXP, eg. ciphers containing DES)
• Disable key sizes smaller than 128 bits for encrypting payload traffic
• Disable the use of MD5 as a hashing mechanism for payload traffic
• Disable the use of IDEA cipher suites
• Disable RC4 cipher suites
• Favor GCM over CBC regardless of the cipher size. Be aware that CBC suites are all deprecated now.
• If you want to get very granular, define a cipher string that works with different versions of your encryption tool, like openssl
• Verify your cipher string with an audit-tool or manually as shown below – there are many ssl test/audit tools out there (check with the IT Security team)

0x00,0x9F - DHE-RSA-AES256-GCM-SHA384   TLSv1.2 Kx=DH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
0x00,0x9E - DHE-RSA-AES128-GCM-SHA256   TLSv1.2 Kx=DH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
0x00,0x6B - DHE-RSA-AES256-SHA256       TLSv1.2 Kx=DH     Au=RSA  Enc=AES(256)    Mac=SHA256
0x00,0x67 - DHE-RSA-AES128-SHA256       TLSv1.2 Kx=DH     Au=RSA  Enc=AES(128)    Mac=SHA256
0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH   Au=RSA  Enc=AESGCM(256) Mac=AEAD
0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH   Au=RSA  Enc=AESGCM(128) Mac=AEAD
0xC0,0x28 - ECDHE-RSA-AES256-SHA384     TLSv1.2 Kx=ECDH   Au=RSA  Enc=AES(256)    Mac=SHA384
0xC0,0x27 - ECDHE-RSA-AES128-SHA256     TLSv1.2 Kx=ECDH   Au=RSA  Enc=AES(128)    Mac=SHA256
0xC0,0x14 - ECDHE-RSA-AES256-SHA        SSLv3   Kx=ECDH   Au=RSA  Enc=AES(256)    Mac=SHA1
0xC0,0x13 - ECDHE-RSA-AES128-SHA        SSLv3   Kx=ECDH   Au=RSA  Enc=AES(128)    Mac=SHA1
0x00,0x9D - AES256-GCM-SHA384           TLSv1.2 Kx=RSA    Au=RSA  Enc=AESGCM(256) Mac=AEAD
0x00,0x9C - AES128-GCM-SHA256           TLSv1.2 Kx=RSA    Au=RSA  Enc=AESGCM(128) Mac=AEAD
0x00,0x3D - AES256-SHA256               TLSv1.2 Kx=RSA    Au=RSA  Enc=AES(256)    Mac=SHA256
0x00,0x3C - AES128-SHA256               TLSv1.2 Kx=RSA    Au=RSA  Enc=AES(128)    Mac=SHA256
0x00,0x35 - AES256-SHA                  SSLv3   Kx=RSA    Au=RSA  Enc=AES(256)    Mac=SHA1
0x00,0x2F - AES128-SHA                  SSLv3   Kx=RSA    Au=RSA  Enc=AES(128)    Mac=SHA1
0x00,0x0A - DES-CBC3-SHA                SSLv3   Kx=RSA    Au=RSA  Enc=3DES(168)   Mac=SHA1
0x00,0x39 - DHE-RSA-AES256-SHA          SSLv3   Kx=DH     Au=RSA  Enc=AES(256)    Mac=SHA1
0x00,0x33 - DHE-RSA-AES128-SHA          SSLv3   Kx=DH     Au=RSA  Enc=AES(128)    Mac=SHA1

PFS and Cipher Prioritization Logic

The ordering of a ciphersuite is very important because it decides which algorithms are going to be selected in priority. The general recommendation is to prioritize algorithms that provide perfect forward secrecy. Keep in mind that older versions of OpenSSL may not return the full list of algorithms. Ciphers such as AES-GCM and some ECDHE are fairly recent, and not present on most versions of OpenSSL shipped with Debian or RHEL flavoured linuxes.
The following guidelines should be used when deciding on how to prioritize the ordering of a ciphering suite:

• ECDHE+AESGCM ciphers should be selected first. These are TLS 1.2 ciphers. No known attack currently target these ciphers.
• PFS ciphersuites should be preferred, with ECDHE first, then DHE.
• AES 128 should preferred to AES 256. There has been discussions on whether AES256 extra security was worth the cost, and the result is far from obvious. At the moment, AES128 is preferred, because it provides good security, is really fast, and seems to be more resistant to timing attacks.
• If you are using a backwards compatible ciphersuite, AES should be preferred to 3DES. BEAST attacks on AES are mitigated in TLS 1.1 and above, and difficult to achieve in TLS 1.0. In the non-backward compatible ciphersuite, 3DES is not present.
• RC4 must be removed entirely. 3DES is used for backward compatibility.

Similarly, the following items should be mandatorily discarded:

• aNULL contains non-authenticated Diffie-Hellman key exchanges, that are subject to Man-In-The-Middle (MITM) attacks
• eNULL contains null-encryption ciphers (cleartext)
• EXPORT are legacy weak ciphers that were marked as exportable by US law
• RC4 contains ciphers that use the deprecated ARCFOUR algorithm
• DES contains ciphers that use the deprecated Data Encryption Standard
• SSLv2 contains all ciphers that were defined in the old version of the SSL standard, now deprecated
• MD5 contains all the ciphers that use the deprecated message digest 5 as the hashing algorithm

Finally, make sure you keep yourself informed on how to securely configure and stay secure with regards to the settings for all the the products you use and which rely on some form of encryption. Resources such as BetterCrypto.org: Applied Crypto Hardening (2016) can assist in this task.

Most Common SSL/TLS Attacks and Mitigations

BEAST and RC4

The Beast attack works by tampering with the encryption algorithms of the CBC modes and when successful, it can lead to portions of the encrypted traffic to be decrypted. To mitigate this issue, the recommendation was to disable all TLS 1.0 ciphers and only offer RC4. However, RC4 has developed a significant number of attacks against it, many of which have crossed the line from theoretical to practical. Also, there is good reason to believe that the NSA has broken RC4 via their so-called “big breakthrough”. Disabling RC4 has several ramifications. One, users with lousy browsers such as Internet Explorer on Windows XP will, in lack of the RC4, use 3DES instead. 3DES is more secure than RC4, but it is significantly more taxing for your server. Two, RC4 mitigates BEAST. Thus, disabling RC4 makes TLS 1.0 users susceptible to that attack, by moving them to AES-CBC (the usual server-side BEAST fix is to prioritize RC4 above all else). Recent browser versions have enabled client side mitigation for the beast attack. Indeed, with client-side mitigation (which Chrome and Firefox both provide), BEAST is nowadays a non-issue. But the risk from RC4 keeps growing and it will have to eventually also be abandoned.

FREAK (Factoring RSA-EXPORT Keys)

FREAK is a man-in-the-middle (MITM) vulnerability discovered by a group of cryptographers at INRIA, Microsoft Research and IMDEA. FREAK stands for “Factoring RSA-EXPORT Keys”. The vulnerability dates back to the 1990s, when the US government banned selling crypto software overseas, unless it used export cipher suites which involved encryption keys no longer than 512-bits. It turned out that some modern TLS clients – including Apple’s SecureTransport and OpenSSL – had a bug in them. This bug causes them to accept RSA export-grade keys even when the client didn’t ask for export-grade RSA. The impact of this bug can be quite nasty: it admits a “man in the middle” attack whereby an active attacker can force down the quality of a connection, provided that the client is vulnerable and the server supports export RSA. To mitigate this, make sure your cipher-suite is updated to the latest available version and urge your clients to also use upgraded software.

Logjam (DH EXPORT)

Researchers from several universities and institutions conducted a study that found an issue in the TLS protocol. In the study the researchers report two attack methods. With the first attack, a man-in-the-middle can downgrade a vulnerable TLS connection to 512-bit export-grade cryptography which would allow the attacker to read and change the data. The second attack abuses the fact that many servers use the same prime numbers for Diffie-Hellman key exchange instead of generating their own unique DH parameters. Keep in mind that Diffie-Hellman key exchange allows for TLS to agree on a shared key and negotiate a secure session over a plain text connection. The researches estimated that an academic team can break 768-bit primes and that a nation-state could break a 1024-bit prime. By breaking one 1024-bit prime, one could eavesdrop on 18 percent of the top one million HTTPS domains. Breaking a second prime would open up 66 percent of VPNs and 26 percent of SSH servers. To mitigate this, make sure your SSL software is updated to the latest available version and urge your clients to also use upgraded software. To combat this, browsers now refuse DH parameters lower than 768/1024 bits. Cloudflare has a detailed guide on logjam.

Heartbleed

OpenSSL is a widely used implementation of the Transport Layer Security (TLS) protocol and Heartbleed is a security bug affecting the OpenSSL cryptographic library and disclosed in April 2014. Heartbleed results from improper input validation (due to a missing bounds check) in the implementation of the DTLS heartbeat extension (RFC6520), thus the bug’s naming from the SSL’s “heartbeat”. Heartbleed may be exploited regardless of whether the party using a vulnerable OpenSSL instance for TLS is a server or a client. The vulnerability is classified as a buffer over-read, a situation where more data can be read than should be allowed. The bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April 2014 fixed the bug. If you are using an updated version of OpenSSL you are not vulnerable to this bug (see table below).

Versions of OpenSSL which are/or not affected by Heartbleed

• OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
• OpenSSL 1.0.1g is NOT vulnerable
• OpenSSL 1.0.0 branch is NOT vulnerable
• OpenSSL 0.9.8 branch is NOT vulnerable

CRIME (SSL Compression attack)

The CRIME attack uses the SSL Compression feature to produce information leakage, and this happens when data is compressed prior to encryption. If an attacker can repeatedly inject and mix arbitrary content with some sensitive and relatively predictable data, and observe the resulting encrypted stream, then the attacker will be able to extract the unknown data from it. In practice, the attack works best against session cookies. If a man-in-the-middle (MITM) attacker 1) can observe network traffic, and 2) manipulate the victim’s browser to submit requests to the target site, the attacker can, as a result, steal the site’s cookies, and thus hijack the victim’s session. In the current form, the exploit uses JavaScript and needs 6 requests to extract one byte of data. The use of JavaScript is desired, but not required: simple tags can do the job just as well, although with a performance penalty.

To mitigate CRIME on Apache 2.2.24+, add the following line to the SSL config file:

SSLCompression off

SSLv2 and DROWN

SSLv2 has been created by Netscape in 1995 and SSLv3 by the same company in 1996. From the start, SSLv2 showed weaknesses and has quickly been replaced by SSLv3. SSLv2 was highly insecure and should no longer be enabled, one of the main reasons being that it can facilitate the DROWN attack. DROWN is a MitM (Man in the Middle) attack using principles similar to the Bleichenbacher attack (1998) and targeting SSL/TLS based protocols. DROWN allows the attacker to break the server encryption and as a result, intercept all client-server communication using the enabled SSLv2 support on the server. The attack can be successfully executed on any server that allows SSLv2, including those whose vulnerables ciphers are disabled. The successful exploitation of this vulnerability allows access to the private key, so a correctly configured server re-using a key installed on a vulnerable server would also be equally vulnerable. Openssl versions inferior to 1.0.1f and 1.0.2g are especially vulnerable due to a bug allowing the use of disabled vulnerable ciphers, facilitating the exploitation of the vulnerability in minutes using consumer-grade hardware. For most late generation browsers, a yellow triangle appears on the padlock when the website visited uses an outdated protocol such as SSLv2 or SSLv3. To disable these on the server side, insert this line on the Apache SSL config file:

SSLProtocol All -SSLv2 -SSLv3

All is a shortcut for +SSLv2 +SSLv3 +TLSv1 or – when using OpenSSL 1.0.1 and later – +SSLv2 +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2, respectively. The above line enables everything except SSLv2 and SSLv3. More info on the apache website

For Openssl users, a migration toward versions equal or superior to 1.0.1f or 1.0.2g is strongly advised.

SSLv3 and POODLE

Despite being quite old, SSLv3 was still being kept enabled in SSL/TLS implementations dating back to 2014 and prior, mostly with the intent of remaining backwards compatible. This was achieved by allowing for protocol downgrading for legacy clients – an operation known as SSLv3 FallBack. The POODLE attack (Padding Oracle On Downgraded Legacy) shattered this by producing an attack that relies on the non-deterministic feature of the cipher block padding of CBC encryption, and which integrity cannot be verified during decryption. PODDLE subverts this padding and by means of this, reveal significant parts of the encrypted message if applied continuously. The recommendation for mitigation is to disable SSLv3 altogether. If there is occasional need to work with legacy systems, the TLS-FALLBACK-SCSV mechanism can be used to prevent an attacker from forcing a protocol downgrade. This extension was originally proposed by Google to prevent forced SSL protocol downgrade.

Return Of Bleichenbacher’s Oracle Threat (ROBOT)

This attack is aptly named after a 19-year-old vulnerability that allows performing RSA decryption and signing operations with the private key of a TLS server. In 1998, Daniel Bleichenbacher discovered that the error messages given by SSL servers for errors in the PKCS #1 v1.5 padding allowed an adaptive-chosen ciphertext attack; this attack fully breaks the confidentiality of TLS when used with RSA encryption. For hosts that are vulnerable and only support RSA encryption key exchanges it’s pretty bad. It means an attacker can passively record traffic and later decrypt it. For hosts that usually use forward secrecy, but still support a vulnerable RSA encryption key exchange the risk depends on how fast an attacker is able to perform the attack. ROBOT only affects TLS cipher modes that use RSA encryption. Most modern TLS connections use an Elliptic Curve Diffie Hellman key exchange and need RSA only for signatures.
The RSA encryption modes are so risky that the only safe course of action to mitigate this is to disable them (the ciphers that start with TLS_RSA). Apart from being risky these modes also lack forward secrecy. Ciphers that do use RSA signatures, namely the ones that include DHE and ECDHE in their name are not affected by ROBOT. Preliminary tests have determned that the cost of disabling RSA encryption modes are relatively low. Cloudflare indicates that around one percent of their connections use the RSA encryption modes and disabling these modes on HTTPS servers operated by them caused no notable problems.

Adapted from:
OWASP: Transport Layer Security Cheat Sheet
Strong SSL Security on Apache2
OPENSSL Vulnerabilities

Other Articles:

Issues with SSL Certificates (Intermediate/Root)