[tbb-bugs] #18274 [Tor Browser]: 3DES_EDE_CBC cipher is vulnerable in the current TBB configuration!

[Tor Bug Tracker & Wiki]

#18274: 3DES_EDE_CBC cipher is vulnerable in the current TBB configuration!
--------------------------+--------------------------
 Reporter:  bugzilla      |          Owner:  tbb-team
     Type:  defect        |         Status:  closed
 Priority:  Medium        |      Milestone:
Component:  Tor Browser   |        Version:
 Severity:  Major         |     Resolution:  invalid
 Keywords:  tbb-security  |  Actual Points:
Parent ID:                |         Points:
  Sponsor:                |
--------------------------+--------------------------

Comment (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?
 [https://bugzilla.mozilla.org/show_bug.cgi?id=952863 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:
 [https://bugzilla.mozilla.org/show_bug.cgi?id=587407 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! '''

 [https://bugzilla.mozilla.org/show_bug.cgi?id=1137484 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?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18274#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online