1267899 - Triple-DES is weak

Status: RESOLVED FIXED

(NSS :: Libraries, defect)

Description

[Martin Thomson [:mt:]]

From Karthik and his team:

We have been looking at the use of cryptography in TLS and realised that Triple-DES is not much more secure than RC4 when used with TLS and HTTPS.  RC4 was recently killed in all major web browsers following RFC7465, and we believe that Triple-DES should also be disabled for security reasons.  In particular, Triple-DES is now used more frequently than RC4 with recent browsers.  We estimate that it is negotiated for 1-2% of all HTTPS connections; this is a small fraction, but not negligible, and includes connections from modern browsers to important websites such as https://signin.ebay.com/ and https://icloud.com 

More precisely, the issue is the small block size of DES and Triple-DES, which is only 64 bits.  This makes birthday attacks a serious threat: after encrypting roughly 40GB under the same key, a collision is expected between two ciphertext blocks, and this reveals the xor between two plaintext blocks.  In particular, this can be abused to recover authentication cookies: an attacker with the ability to run scripts in the victim's browser (man-in-the-browser) can generate a large number of queries to a server, each including the secret cookie, and collect collisions until one of them reveals the xor between a predictable header and the cookie. 

With current network speeds reaching 40GB on a single connection is not that hard. We have implemented the attack, and it is “almost” practical (i.e. in the same ballpark as the RC4 attacks). Using a modern web browser and an IIS 6.0 server with their default configuration, an HTTPS session will be encrypted with Tripe-DES.  Our attack requires about 785GB of traffic on average. Experimentally, we have recovered a 16-byte cookie from a 610GB trace, collected in 30.5 hours.

Our work has been submitted to the Usenix Security '16 conference, and we plan to make our results public before the paper’s publication.  [August 10–12]

Comment 1

[Martin Thomson [:mt:]]

The simplest thing to do would be to disable the suites.  However, that risks interoperability problems.  We should look to limit the number of bytes sent or received.  Unfortunately, NSS doesn't have good accounting.  We'll have to add that.

We should add per-cipher limits so that we can hide this change.  That work can happen in another bug if we agree.

I have an addon ready for paranoid Firefox users.

Comment 2

[Martin Thomson [:mt:]]

I've opened bug 1268745 for implementing the limits and attached a patch.  It's clear that the limits are all strange.

If I actually used the formula from the AES-GCM analysis, which is

  max_records = (sqrt(2^(block_size + 1) * p) - 1)/(blocks_per_record + 1)

Then 3DES has a limit of ~1.5 records at a target attack probability of 2^-40.  The 40Gb/2^21record limit that I've used in the patch runs to a 50% probability of attack on these numbers, which is pretty bad.  Though I believe that also assumes full records, which is rare in practice.

I'd really like to turn this suite off entirely.  However:

We see about 1.1% of connections negotiating 3DES, slightly more in prerelease channels.  Chrome has similar values.  Microsoft report 0.4%, so they are obviously doing something right.

That's currently too much to break without enough lead time.  Even if we reduced record limits to something insanely low (e.g., 1000 records per connection), we would be better off than if we broke that many connections.

Comment 3

[Franziskus Kiefer [:franziskus]]

The paper has been published [1] and the fix in bug 1268745 has been released with NSS 3.27.

[1] https://sweet32.info/

Comment 4

[Martin Thomson [:mt:]]

We should perhaps retain this bug (though public) for discussing when to disable 3DES.

Comment 5

[Christian Stadelmann]

(In reply to Martin Thomson [:mt:] from comment #4)
> We should perhaps retain this bug (though public) for discussing when to
> disable 3DES.

Isn't that already tracked in bug #1227524?