Nadim Kobeissi: > > On 2013-07-05, at 6:15 AM, Matthew Green <matthewdgr...@gmail.com> > wrote: > >> >> >> On Jul 5, 2013, at 12:01 AM, Jacob Appelbaum <ja...@appelbaum.net> >> wrote: >> >>> Nadim Kobeissi: >>>> >>>> On 2013-07-05, at 3:15 AM, Jacob Appelbaum >>>> <ja...@appelbaum.net> wrote: >>>> >>>>> Nadim Kobeissi: >>>>>> Hello everyone, I urge you to read our response at the >>>>>> Cryptocat Development Blog, which strongly clarifies the >>>>>> situation: >>>>>> >>>>>> https://blog.crypto.cat/2013/07/new-critical-vulnerability-in-cryptocat-details/ >>>>> >>>>> >>>>>> Has there been a rotation of the certificate and keying material for all >>>>> services that serve CryptoCat chat traffic? >>>> >>>> Rest assured we're working on it as an extra precaution (as >>>> mentioned in the blog post). Also, our services use SSL forward >>>> secrecy. >>> >>> I'm not really assured and I think I should clarify something >>> that is perhaps slipping past like a ship in the night. I went to >>> crypto.cat in Chrome only to find myself not connected in a >>> forward secure manner. >>> >>> According to ssllabs[0], CryptoCat supports some odd SSL/TLS >>> configurations: >>> >>> Protocols TLS 1.2 Yes TLS 1.1 No TLS 1.0 No SSL 3.0 >>> Yes SSL 2.0 No >>> >>> Further more - it appears that CryptoCat supports >>> SSL_RSA_WITH_RC4_128_SHA, as well as other non-forward secure >>> modes Is there really any reason to support such a mode with 3DES >>> in 2013 for this kind of service? > > TLS1.1 and 1.2 are both supported, actually, in addition to SSL 3.0.
Why does ssllabs think otherwise, I wonder? It looks now like ssllabs thinks SSL 3, TLS 1.1 and TLS 1.2 are supported, while TLS 1.0 isn't. Did you reconfigure the protocols that are offered? Why offer SSL 3.0 but not TLS 1.0? > > AES-GCM is already prioritized over RC4, but unfortunately most > browsers don't support AES-GCM yet, which is why RC4 remains as the > secondary choice. In the case that AES-GCM is not supported, we use > RC4 instead of AES-CBC in order to mitigate for BEAST. If you have > alternate suggestions to this, please let me know. None of the browsers supported by the plugin, certainly not those which support forward secrecy, should be vulnerable to the BEAST attack. I believe that almost everyone is using 1/n-1 record splitting or something that is functionally similar. > > We've just removed some of the more obsolete suites that use 3DES. > They were unlikely to be used anyway due to their very low priority. > Are you sure? I'm still seeing SSL3 with RSA and RC4 in Chrome. If the SSL key is taken tomorrow, my session from today is compromised... >>> >>> Also, I'm not sure if this is obvious but it appears that many >>> users may be using SSL 3.0: >>> >>> Chrome 27 SSL 3 TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) >>> Forward Secrecy 128 Firefox 21 SSL 3 >>> TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Forward Secrecy 128 >>> Internet Explorer 10 SSL 3 >>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Forward Secrecy >>> 128 Safari iOS 6.0.1 TLS 1.2 >>> TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Forward Secrecy 128 >>> Safari 5.1.9 SSL 3 TLS_ECDHE_RSA_WITH_RC4_128_SHA >>> (0xc011) Forward Secrecy 128 >>> >>> RC4 is not my favorite choice when all the other crypto has >>> failed. >>> >>> Do you know how many users are impacted? How many users are >>> actually choosing the forward secret protocols? Also, I'll ask again: Do you know how many users are impacted? How many users are actually choosing the forward secret protocols? All the best, Jacob _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
