Resolve SSL Vulnerabilities Detected by testssl

Spread the love
(Last Updated On: March 11, 2018)

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:

qualys alexa ranking grade F 2018

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.

Image result for poodle ssl

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. 

sweet32 birthday attack TLS 3DES CBC vulnerability1

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)

Image result for BEAST ssl

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”]

BrowserVersionPlatformsSSL 2.0 (insecure)SSL 3.0 (insecure)TLS 1.0TLS 1.1TLS 1.2
Microsoft Internet Explorer7, 8, 9Windows VistaDisabled by defaultEnabled by defaultYesNoNo
7, 8,9Server 2008Disabled by defaultEnabled by defaultYesDisabled by defaultDisabled by default
8, 9, 10Windows 7Disabled by defaultEnabled by defaultYesDisabled by defaultDisabled by default
10Windows 8Disabled by defaultEnabled by defaultYesDisabled by defaultDisabled by default
10Server 2012Disabled by defaultEnabled by defaultYesDisabled by defaultDisabled by default
Apple Safari6OS X 10.8NoYesYesNoNo
Apple Safari (mobile)4, 5iPhone OS 3, iOS 4NoYesYesNoNo
Opera Browser12.15–12.17WindowsNoDisabled by defaultYesDisabled by defaultDisabled by default
Mozilla Firefox25.0.1, 26
ESR 24.1.1
ESR only for:
Windows, OS X (10.9+)
NoEnabled by defaultYesDisabled by defaultDisabled by default
Google Android OS BrowserAndroid 4.1–4.3.1, 4.4–4.4.4NoEnabled by defaultYesDisabled by defaultDisabled by default
Google Chrome26–29Windows (7+)
OS X (10.9+)
Android (4.1+)
iOS (9.0+)
NoEnabled by defaultYesYesNo

[/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.

 

Team Cook

Self-taught IT guy, and Communist slayer for the past 40 years. Who controls the information, controls the future.

0 0 votes
Article Rating
Subscribe
Notify of
guest

1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Gurjit Singh
4 years ago

Thanks for sharing this useful information

1
0
Would love your thoughts, please comment.x
()
x