Select Monthly Archives
- May 2018
- March 2018
- February 2018
- December 2017
- November 2017
- September 2017
- August 2017
- June 2017
- May 2017
- March 2017
- February 2017
- January 2017
- December 2016
- November 2016
- October 2016
- September 2016
- August 2016
- July 2016
- March 2016
- October 2015
- September 2015
- July 2015
- May 2015
- March 2015
- February 2015
- January 2015
- December 2014
- September 2014
- August 2014
- July 2014
- June 2014
- March 2014
- January 2014
- December 2013
- September 2012
Written By: Adam Caudill August 24, 2016
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 (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 2^32 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
- 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. 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.
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.
- 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, 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.