[cryptography] DeCryptocat

Jacob Appelbaum jacob at appelbaum.net
Fri Jul 5 01:09:44 EDT 2013


Nadim Kobeissi:
> 
> On 2013-07-05, at 6:15 AM, Matthew Green <matthewdgreen at gmail.com>
> wrote:
> 
>> 
>> 
>> On Jul 5, 2013, at 12:01 AM, Jacob Appelbaum <jacob at appelbaum.net>
>> wrote:
>> 
>>> Nadim Kobeissi:
>>>> 
>>>> On 2013-07-05, at 3:15 AM, Jacob Appelbaum
>>>> <jacob at 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


More information about the cryptography mailing list