Opened 4 years ago

Closed 4 years ago

Last modified 3 years ago

#18274 closed defect (invalid)

3DES_EDE_CBC cipher is weak in the current TBB configuration!

Reported by: bugzilla Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Major Keywords: tbb-security
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

From The Design and Implementation of the Tor Browser [DRAFT]:

we also enable TLS False Start via the Firefox Pref security.ssl.enable_false_start.

From TLS False Start https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00

generally symmetric ciphers with an effective key length of 128 bits or more can be considered strong. In TLS 1.2 [RFC5246], this allows all cipher suites except those using the NULL or 3DES_EDE_CBC ciphers

Detected by https://www.ssllabs.com/ssltest/viewMyClient.html

TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112

In about:config:
security.ssl3.rsa_des_ede3_sha;true
Why is this security hole still present?

Child Tickets

Change History (10)

comment:1 Changed 4 years ago by cypherpunks

Why is this security hole still present?

Any PoC it was used for False Start protocol?

   Clients MUST NOT use the False Start protocol modification in a
   handshake unless the cipher suite uses a key exchange method that has
   been whitelisted for this use.
   Implementations may have their own whitelists of key exchange methods
   and client certificate types

CanFalseStartCallback

ECDHE is allowed, but DHE (and RSA) are not.

comment:2 Changed 4 years ago by bugzilla

Indeed, Mozilla has "Disable TLS False Start for non-ECDHE key exchange" bug fixed. But after SLOTH and Logjam can we trust them? And why do we need this weak cipher suite at all?

comment:3 Changed 4 years ago by cypherpunks

And why do we need this weak cipher suite at all?

Bug 1139778

The usage rate of 3DES is still too high to use whitelist

comment:4 Changed 4 years ago by gk

Keywords: TorBrowserTeam201602 removed
Resolution: invalid
Status: newclosed

Seems invalid to me given the description. And again, please don't mess with our keywords if you don't know what you are doing. We use them to get actual work done.

comment:5 in reply to:  3 Changed 4 years ago by bugzilla

Ok. I was too hurry that hadn't checked Mozilla's whitelisting. But today a lot of security labs propose disabling SHA at all, not saying about 112-bit deprecated ciphers. And, thank you, cypherpunks, for

Bug 1139778

The usage rate of 3DES is still too high to use whitelist

But that citation refers to a research https://tools.ietf.org/agenda/91/slides/slides-91-saag-3.pdf#page=12
where:
29-oct-2014, 3DES, share in % - 0,1
last date of SSLv3, share in % - 0,26
last date of RC4, share in % - 25,2

So disabling 3DES is easier then RC4.

comment:6 Changed 4 years ago by yawning

Not interesting.

Despite what guidelines say, the best known attacks against 3DES are computationally infeasable.

The best known attack against 3DES is computationally infeasible (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.119.1761&rep=rep1&type=pdf). Anything that could break 3DES could break 128 bit AES as well, because the only likely feasible break is a quantum computer.

(Landauer's principle doesn't go away just because you have lots of money.)

comment:7 Changed 4 years ago by bugzilla

Really?
There were no questions to 3DES itself.
And a quantum computer is an ordinary computer, it's just a misnaming of teleportation-based computer (which is not scalable).

computationally infeasible

you say? Ok, let's check for our case:

So you can't get to 112 bit security strength without:

1) Negotiating TLS 1.2 for connection (you need TLS 1.2 because it is the only level of the protocol that provides a way to control the hash used for signing during the protocol.)
2) Using an authentication certificate that has 112 bit security strength in its trust chain (e.g. RSA-2048 with SHA-256 signature).
3) Negotiating a cipher suite with 112 bit security.
4) Negotiation a hash and signature algorithm with 112 bit security (e.g. SHA-256)
5) You need a FIPS approved PRNG algorithm and an entropy source with at least 112 bits of entropy.

And what do we have now?

  1. No warning about or disabling obsolete TLS 1.0 & 1.1 (TLS 1.1 is also limited to using MD5+SHA-1 for ServerKeyExchange signatures and deriving keys from the premaster secret. Also see www.isg.rhul.ac.uk/tls/Lucky13.html)

    Chrome browser has been warning about lack of TLS 1.2 and authenticated (GCM) suites

  2. SHA-1 does not have 112 bit security strength (80 bit only) in certificates. Mozilla didn't add security update about that to the ESR! And you prefer to wait instead of backporting (#18042).
  3. NIST is saying you should have at least 112 bit security by 2014 and that this is generally acceptable to 2031. But they also say that you have to use FIPS approved algorithms. But NSS has separate FIPS-approved cipher suites for 3DES. Can you prove that enabled suit isn't worse?
  4. HMAC SHA-1 is enough.
  5. Have you checked that?

And about False Start in Mozilla:

Any PoC it was used for False Start protocol?

Bug 952863 was reported 2013-12-22 15:53 PST by Brian Smith (:briansmith, :bsmith). But it was fixed only for FF36 (not esr) 2014-12-12! So until Tor Browser 5.0 (38esr) -- August 11 2015 it was vulnerable!

Another one moment about security in Mozilla and Tor Project:
Bug 587407 - Disallow connections when the server uses a DHE key that is too weak

for the case where the key size is 512-1024 bits, where NSS won't return an error but where we already know that the encryption is more-or-less broken.

2011.04.26 Brian Smith (:briansmith, :bsmith)

We already disallows 512-bit DHE key in NSS.

2015.03.03 Masatoshi Kimura [:emk]

In fact, the TLS design is just completely broken here, because the DHE key is effectively authenticating itself. That means that a secure minimum size for the DHE key is whatever the minimum size we require for authentication, which is going to be *2048* bits after bug 1137484 lands. And, almost nobody doing DHE is using 2048-bit DHE keys.

2015.03.19 Brian Smith (:briansmith, :bsmith)
Welcome, Logjam!

Bug 1137484 - Show Untrusted Connection Error when cert in chain uses less than RSA 2048 signatures
Extend this to DH suites or continue to wait something?

And, of course, about implementation of 3DES at Mozilla:
see the level of discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=918231
Can you prove that three keys they generated are correct and different, and used properly? Taking into consideration that they use ABA in EDE for their Master Password? (But it's not so important, because it's a small part of listed above).
And don't forget that 3DES is used with TLS < 1.2 and only for compatibility with IE6!

So, TBB should be step forward. Or not?

comment:8 Changed 3 years ago by bugzilla

Summary: 3DES_EDE_CBC cipher is vulnerable in the current TBB configuration!3DES_EDE_CBC cipher is weak in the current TBB configuration!

(Good Trac Update! Could somebody ask Yawning to continue conversation?)

Last edited 3 years ago by bugzilla (previous) (diff)

comment:9 Changed 3 years ago by mancha

Bhargavan and Leurent describe a computationally feasible attack on 3DES. It's probably a good time to review our assumptions and re-open this for further consideration.

See SWEET32 paper for a detailed technical description.

tags: CVE-2016-2183, CVE-2016-6329, SWEET32

Last edited 3 years ago by mancha (previous) (diff)

comment:10 Changed 3 years ago by bugzilla

It looks like Tor devs think that some crypto is weak only after the public disclosure :(
Mozilla isn't going to backport its workaround to esr: https://bugzilla.mozilla.org/show_bug.cgi?id=1268745

Note: See TracTickets for help on using tickets.