Before you go changing your SSL config, it might be worth understanding exactly what the vulnerability is here.
When 3DES was introduced, there was a requirement that it was interoperable with legacy single-DES systems. The idea behind 3DES is that you can multiply the security by performing multiple DES operations with different keys. In order to provide compatibility, they used an EDE construction: 3 DES operations in sequence - Encrypt, Decrypt, Encrypt - or EDE for short. It turns out that a DES decrypt operation is basically interchangeable with an encrypt operation in terms of security, so this works quite well. When you use three independent keys for each operation (known as keying option 1) you essentially have a 168-bit key. If you want to go back to old single-DES mode, you use a different keying option (3) which has all three subkeys set to the same value, i.e. k1 = k2 = k3, so that two of the operations cancel out and only a single DES operation actually matters. There's also another keying option which has two of the keys with the same value but one different, producing a 112-bit key, but this isn't really used in reality and (somewhat confusingly) is completely unrelated to why you're seeing 3DES reported as 112-bit.
To make things even more confusing, you'll sometimes hear people talk about 64-bit DES or 192-bit 3DES. These are, from a cryptographic perspective, identical to 56-bit DES or 168-bit 3DES. DES specifies a key padding system whereby 8 padding bits can be added to a 56-bit key to produce a 64-bit padded key. This was for use in some old systems and it's not really important, but the 8 bits can be ignored and only 56 bits are actually key material. In 192-bit 3DES the same thing happens, where each 56-bit subkey is padded with 8 padding bits, but again the real cryptographic key is only 168 bits long.
Now, what's the 112-bit thing all about?
3DES suffers from a problem called a meet-in-the-middle attack. The approach is as follows:
- Find a known plaintext and ciphertext block pair for a given key you want to crack.
- Compute the first encryption step (i.e. one DES encrypt operation) on the plaintext block for all possible 56-bit keys.
- Store all of the resulting 64-bit blocks in a big lookup table.
- For each possible remaining 112-bit part of the key, perform the other two operations (decrypt, encrypt) on the ciphertext.
- If the result of the two operations matches any block in your lookup table, you've found the key. Otherwise try the next 112-bit key.
This is a time/space tradeoff that allows you to reduce the number of computations from 2168 down to 2112 with a space cost of 256 64-bit blocks (512 petabytes).
Now, for some bizarre reason, all security tools seem to report 3DES-EDE as 112-bit without actually qualifying why. 3DES-EDE does not have a 112-bit key length, nor does it really even have a 112-bit effective key length unless you specify that your attacker has 512PiB of lightning-fast storage available alongside their massive array of DES-cracking ASICs. The practice of reporting it as 112-bit appears to have started with the "sslscan" tool, and has been copied by various other tools since then, leading to all sorts of confusion and misconceptions (I even saw this incorrectly marked in a security exam!)
This isn't to say you shouldn't disable 3DES - it's an old algorithm now and there are problems with it, so it's probably worth moving away from it. It's just worth knowing why.
If you want to do so, add DESede
and DES
to your list of disabled algorithms. These names are defined in the cryptographic providers documentation, in case you want to disable any others.