Resolve SSL Vulnerabilities Detected by testssl

You checked your site SSL configuration with testssl.sh (see Test Your SSL Configuration with testssl) and it returned some SSL vulnerabilities? Here are some recipes to help you make sense of it all. You will most likely need the Mozilla SSL Configuration Generator to protect your site with an up-to-date, correct SSL configuration.

[callout type=”info” size=”lg”]

This post is purely informational.

You don’t need to do any of the things described here. Just use the the Mozilla SSL Configuration Generator and select modern configuration (for nginx or Apache) and use it in your site’ ssl.conf configuration. That’s it.

[/callout]

Why Does It Matter?

It matters to those of you who exploit commercial websites. You don’t want your clients to be fooled by hackers and fake sites. You don’t want your customers’ precious PII information to be stolen or compromised.

Unfortunately, in March 2018, still 13% of the top 150,000 Alexa ranked sites are graded F by Qualys’ SSL Pulse observatory:

You don’t want your site to be in the last bin, do you?

Resolve SSL Vulnerabilities Detected by testssl

POODLE

The SSLv3 POODLE vulnerability scanner attempts to find SSL servers vulnerable to CVE-2014-3566, also known as POODLE (Padding Oracle On Downgraded Legacy) vulnerability.

This vulnerability may allow an attacker who is already man-in-the-middle (at the network level) to decrypt the static data from an SSL communication between the victim user and a vulnerable server. The attacker will probably try to obtain the HTTP cookies or other static data. For that, he needs to convince both the victim’s browser and the server to speak SSLv3 and to use a vulnerable cipher (in Cipher Block Chaining mode). This could be done by forcing a downgrade during the SSL/TLS negociation.

[callout type=”success” size=”lg”]

Solution:

Disable SSLv3

[/callout]

SWEET32

testssl log:

SWEET32 (CVE-2016-2183, CVE-2016-6329) VULNERABLE, uses 64 bit block ciphers

SWEET32 is a vulnerability in 3DES-CBC ciphers, which is used in most popular web servers. 

Mitigate SWEET32:

The obvious way to avoid these attacks is to stop using legacy 64-bit block ciphers. Alternatively, the attack can be mitigated by re-keying the session frequently.

Concretely, we recommend the following measures to prevent our attack:

• Web servers and VPNs should be configured to prefer 128-bit ciphers. According to our scans, about 1.1% of the top 100k web server from Alexa, and 0.5% of the top 1 million, support AES but prefer to use 3DES.
• Web browsers should offer 3DES as a fallback-only cipher, to avoid using it with servers that support AES but prefer 3DES.
• TLS libraries and applications should limit the length of TLS sessions with a 64-bit cipher. This could be done with TLS renegotiation, or in some cases by closing the connection and starting a new one (i.e. limiting HTTP/1.1 Keep-Alive, SPDY, and HTTP/2 with 3DES cipher-suites).
• OpenVPN users can change the cipher from the default Blowfish to AES, using for instance cipher AES-128-CBC on the client and server configuration. If they don’t control the server configuration, they can mitigate the attack by forcing frequent rekeying with reneg-bytes 64000000.

To examine the ciphers that are enabled in the OpenSSL server, we use the ‘nmap’ command. The code ‘3DES’ indicate cipher suites that use triple DES encryption. These are the ones you need to disable for server security.

nmap -sV --script ssl-enum-ciphers -p 443 yourdomain.com

[code scrollable=”true”]

Starting Nmap 7.01 ( https://nmap.org ) at 2018-03-07 17:42 EST
Nmap scan report for yourdomain.com (35.153.191.83)
Host is up (0.00049s latency).
rDNS record for your-iaas-provider.domain.com
PORT STATE SERVICE VERSION
443/tcp open ssl/http nginx
| http-server-header:
| nginx
|_ nginx/version (Ubuntu)
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) – A
…
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) – C
| compressors:
| NULL
| cipher preference: server
| TLSv1.1:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) – A
…
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) – C
| compressors:
| NULL
| cipher preference: server
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) – A
…
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) – C
| compressors:
| NULL
| cipher preference: server
|_ least strength: C

[/code]

[callout type=”success” size=”lg”]

Solution:

Eliminate every DES ciphers, that is: ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA

[/callout]

BEAST

TLS 1.0 and earlier protocols suffer from a serious flaw: the Initialization Vector (IV) blocks that are used to mask data (plaintext) prior to encryption with a block cipher can be predicted by an active man-in-the-middle (MITM) attacker. IVs are used to prevent encryption from being deterministic; without them, every time you encrypt the same block of data with the same key, you get the same (encrypted) output. This is highly undesirable. A clever attacker who can 1) predict IVs, 2) see what encrypted data looks like, and 3) influence what is encrypted, is then able to make guesses about what plaintext looks like. Technically, he cannot decrypt any data, but he can find out if his guesses are right or wrong. With enough guesses, any amount of data can be uncovered.

testssl log:

BEAST (CVE-2011-3389) TLS1: ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA DHE-RSA-AES128-SHA DHE-RSA-AES256-SHA ECDHE-RSA-DES-CBC3-SHA EDH-RSA-DES-CBC3-SHA AES128-SHA AES256-SHA DES-CBC3-SHA
VULNERABLE -- but also supports higher protocols TLSv1.1 TLSv1.2 (likely mitigated)

Mitigate BEAST:

BEAST is purely a client-side vulnerability. Since it had been released to the public, most major browsers addressed it using a technique called 1/n-1 split. This technique stops the attacker from predicting IVs and effectively addresses the underlying problem.

Supporting TLS 1.1 and 1.2 does not actually address BEAST now or in the near future, even though these protocols do not have the predictable IV weakness that’s exploited by the attack. Reason is, all major browsers are susceptible to protocol downgrade attacks. As long as they support TLS v1, they are not safe.

[callout type=”success” size=”lg”]

Solution:

Enable TLS v1.2 only and disable all the others.

[/callout]

You will render some old clients incompatibles, and you can check which ones here:

[table-wrap bordered=”true” striped=”true”]

[/table-wrap]

LUCKY13

testssl log: (appears every time)

LUCKY13 (CVE-2013-0169), experimental potentially VULNERABLE, uses cipher block chaining (CBC) ciphers with TLS. Check patches

Note about LUCKY13 vulnerability:

The TLS protocol 1.1 and 1.2 and the DTLS protocol 1.0 and 1.2, as used in OpenSSL, OpenJDK, PolarSSL, and other products, do not properly consider timing side-channel attacks on a MAC check requirement during the processing of malformed CBC padding, which allows remote attackers to conduct distinguishing attacks and plaintext-recovery attacks via statistical analysis of timing data for crafted packets, aka the “Lucky Thirteen” issue.

It’s… not quite clear, is it? That’s because it’s the top level of hacking, and as mentioned by testssl, it’s still experimental since its discovery in 2013. It’s like the Spectre and Meltdown vulnerability: discovered by researchers, being addressed (successfully or not) for years, and still not exploited, AFAIK. No need to panic.