Testing for SWEET32 isn’t simple – when the vulnerability was announced, some argued that the best solution was to assume that if a TLS server supported any of the 3DES cipher suites, consider it vulnerable. The problem is, it’s not that simple. On my employer’s corporate blog, I wrote about practical advice for dealing with SWEET32 – and pointed out that there are ways around the vulnerability, and some are quite simple.
The easy options:
- Disable the following cipher suites:
- Limit HTTP Keep-Alive to something reasonable (Apache & Nginx default to 100 requests)
If you don’t need to worry about users on old platforms, it’s easy – just disable the 3DES suites and you’re done. If you do need to worry about customers using Windows XP, disabling the 3DES cipher suites may not be an option, as the only other cipher suites they support use RC4. In that case, you need to limit Keep-Alive sessions.
In cases where 3DES suites are enabled, but reasonable / default limits are in place, SWEET32 isn’t an issue – as there’s no way to issue enough requests within the same session (and thus the same encryption key) to be able to exploit it.
Testing with YAWAST
To test for this, I added a new feature to YAWAST that will connect to the server using a 3DES suite, and issue up to 10,000 HEAD requests, to see how many requests the server will allow in a single session. If the server allows all 10,000 requests, there’s a good chance that the server is vulnerable to SWEET32. This method is used to determine that the server is likely vulnerable, without the massive data transfer and time required to actually verify that it’s vulnerable.
Testing for SWEET32 with YAWAST looks like this:
$yawast ssl https://adamcaudill.com --tdessessioncount
__ _____ _ _ ___ _____ _____
\ \ / / _ \| | | |/ _ \ / ___|_ _|
\ V / /_\ \ | | / /_\ \\ `--. | |
\ /| _ | |/\| | _ | `--. \ | |
| || | | \ /\ / | | |/\__/ / | |
\_/\_| |_/\/ \/\_| |_/\____/ \_/
YAWAST v0.3.0 - The YAWAST Antecedent Web Application Security Toolkit
Copyright (c) 2013-2016 Adam Caudill <email@example.com>
Support & Documentation: https://github.com/adamcaudill/yawast
Ruby 2.2.4-p230; OpenSSL 1.0.2f 28 Jan 2016 (x86_64-darwin15)
[I] 184.108.40.206 (N/A)
[I] 220.127.116.11 (N/A)
[I] 2400:CB00:2048:1::681C:1A37 (N/A)
[I] 2400:CB00:2048:1::681C:1B37 (N/A)
[I] TXT: v=spf1 mx a ptr include:_spf.google.com ~all
[I] MX: aspmx4.googlemail.com (30)
[I] MX: aspmx.l.google.com (10)
[I] MX: alt1.aspmx.l.google.com (20)
[I] MX: aspmx2.googlemail.com (30)
[I] MX: alt2.aspmx.l.google.com (20)
[I] MX: aspmx3.googlemail.com (30)
[I] MX: aspmx5.googlemail.com (30)
[I] NS: hal.ns.cloudflare.com
[I] NS: vera.ns.cloudflare.com
Beginning SSL Labs scan (this could take a minute or two)
[SSL Labs] This assessment service is provided free of charge by Qualys SSL Labs, subject to our terms and conditions: https://www.ssllabs.com/about/terms.html
[I] IP: 18.104.22.168 - Grade: A+
TLS Session Request Limit: Checking number of requests accepted using 3DES suites...
[I] TLS Session Request Limit: Connection terminated after 100 requests (TLS Reconnected)
[I] HSTS: Enabled (strict-transport-security: max-age=15552000; preload)
In this case I’m using YAWAST to run a
ssl scan, using the
--tdessessioncount parameter to instruct YAWAST to perform the SWEET32 test. In this case, you can see that the TLS session was ended after 100 requests (
Connection terminated after 100 requests (TLS Reconnected)) – which is a clear indication that the server isn’t vulnerable. Had the server actually been vulnerable, this message would have been displayed:
[V] TLS Session Request Limit: Connection not terminated after 10,000 requests; possibly vulnerable to SWEET32
The use of 10,000 requests is somewhat arbitrary – it was selected as it’s far above the defaults used for the most common servers, and is small enough that it can be conducted in a reasonable time. It could be argued that it should be larger, to reduce false positives – it could also be argued that it’s excessive, as if it allows 5,000, it’s a reasonable bet that there’s no limit being enforced. This value may change over time based on community feedback, but for now, it’s a safe value that strikes a good balance.
Vulnerable or Possibly Vulnerable?
Unfortunately the only way to confirm that a server is truly vulnerable is to perform the attack, or at least a large part of it. There will be false positives using this technique, but that’s the cost of performing a quick test (that doesn’t involve transferring tens or hundreds of gigabytes of traffic).
When looking at the results, it’s important to understand that it indicates that the server is likely vulnerable, but it is not a confirmation of vulnerability.