This morning, the information security world was abuzz about SWEET32, a new vulnerability affecting a number of protocols, such as TLS, SSH, IPsec and OpenVPN. The issue isn’t a problem with the protocols themselves, but with their support for certain encryption algorithms that share a special property: small block size.
3DES (at the time of this article, the second most commonly supported encryption algorithm for TLS) and Blowfish both use a 64-bit block size, half of the size used by newer algorithms such as AES. The problem with this is that thanks to the birthday paradox, you will run into colliding blocks by 232 encrypted blocks – which puts it into the range that can be practically exploited.
For this article, the focus will be on TLS, and what you need to do to protect your systems from this attack.
How TLS Is Affected
By executing a sufficient number of requests (approximately 229 to 236 encrypted eight byte blocks) via a malicious JavaScript file, an attacker may be able to extract sensitive information such as a session cookie. This is a very similar attack model to that used by BEAST from 2011 – it relies on two things:
- Attacker can cause the user to execute malicious JavaScript – this can be done by a number of methods, from Cross-Site Scripting attacks against the target site, to using phishing techniques to trick a user into visiting a malicious site.
- Attacker has read-only access to the victim’s encrypted traffic – such as a user on open Wi-Fi, malicious network administrator, or the like.
Once the attacker has a copy of the traffic, they can then take it offline and analyze it to discover the sensitive information they are after. To put those numbers into perspective, the victim must generate 280GB to 785GB of traffic during the same TLS session for the attack to be effective.
There are some good things and bad things here; first the good news:
- Quite a bit of traffic is required to execute the attack; this makes the attack more visible to site operators – a user generating this much traffic should stand out in monitoring tools. If request throttling is in place for users generating significant amounts of traffic, that will help by slowing the attack, possibly to the point that it’s no longer practical.
- It’s not fast – under good circumstances, it can take nearly two full days of traffic to generate the collisions needed to recover data. If application session times are kept to a reasonable limit, the session will expire before the attack is able to complete.
- There are various techniques available that can mitigate this attack, which are discussed below.
- Modern clients prefer more secure algorithms over 3DES, so on a properly configured server, it’s rarely actually used. In a scan of the Alexa Top Million sites, only 1.2% negotiated 3DES.
Now, the bad news:
- 3DES is widely supported, very widely supported actually and was listed as a mandatory algorithm in the TLS 1.0 and TLS 1.1 specifications. At the time of this article and in the Alexa Top Million, 86% of sites support 3DES.
- Users of Windows XP may be a real problem – by default, they have two options, RC4 and 3DES. RC4 usage is down substantially as it’s cryptographically broken, which means these users are primarily using 3DES.
- 3DES cannot be used in TLS safely, without various other configuration changes to mitigate the issue.
- Obsolete software makes this more complicated. If client-side mitigations are implemented, they won’t receive them. This leaves a number of users out in the cold (estimates vary between 1% and 3%).
- Attacks get better with time – there very well may be more efficient techniques discovered over time.
Mitigating SWEET32
To mitigate SWEET32, the first step is to determine if you have a significant number of users on Windows XP, old versions of Android, etc. – if not, there’s a simple solution:
Disable all 3DES cipher suites.
If you do have users on older platforms, it’s more complicated – as they likely don’t have another cipher suite to fall back to. This means either abandon the users, or implement other mitigation options.
Options:
- Keep-Alive – The attack depends on being able to keep a TLS session alive for an extended amount of time. For some servers, there are settings that control how many requests can go over a single connection, for Apache, it’s the MaxKeepAliveRequests setting, for Nginx, it’s called keepalive_requests. Both of these servers use a default value of 100 requests, though it is sometimes increased or set to unlimited for performance. This needs to be set to a reasonable limit to prevent a large number of requests being executed on one connection – at the upper end, it shouldn’t exceed 100,000 to be safe. Unfortunately, not all servers offer such an option.
- Prioritize AES – 3DES should be the last cipher suite offered by the server. This will reduce the odds of it being negotiated if there is a better option.
- Enable 3DES on legacy protocols only – If your server of choice allows you to control cipher suites on a TLS version level, only enable it for TLS 1.0 and TLS 1.1; TLS 1.2 clients should not need 3DES, as they are required to support AES suites.
There are various efforts underway to mitigate the issue at the client, server, or CDN level; Firefox now limits the amount of traffic that can be transferred in a single TLS session, CloudFlare is planning on adding a similar restriction when 3DES is used, and OpenSSL will be disabling 3DES by default in version 1.1.0. Additional client-side mitigations may be released, though we do not recommend that they be relied on; the issue needs to be addressed from the server-side.
If you want to read more about SWEET32, you can read the paper or the excellent explanation by Matthew Green that goes into more technical detail.
