Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] DecryptoCat

Jason Gulledge ramdac at ramdac.org
Tue Jul 9 09:20:17 PDT 2013


Here are more statistics on TLS modes failing back to less secure modes, and a semi-complete listing of affected browsers, published 2 days ago: 

http://jbp.io/2013/07/07/tls-downgrade/


Best,
Jason Gulledge

On Jul 9, 2013, at 4:29 PM, Jacob Appelbaum <jacob at appelbaum.net> wrote:

> Patrick Mylund Nielsen:
>> On Tue, Jul 9, 2013 at 9:22 AM, Eugen Leitl <eugen at leitl.org> wrote:
>> 
>>> On Tue, Jul 09, 2013 at 09:12:21AM -0400, Patrick Mylund Nielsen wrote:
>>>> If it's so easy, go ahead and produce a more secure alternative that
>>> people
>>> 
>>> You mean something like http://dee.su/ ?
>>> 
>>> And http://dee.su/cables ?
>>> 
>>> 
>> No, I mean an alternative to Cryptocat (i.e. an OTR client with multiparty
>> communication) that is more secure, and as easy to use.
>> 
> 
> While Cryptocat has OTR - the multi-party communication is not the OTR
> protocol.
> 
> Cables is as easy to use as email. Generally it is used with an email
> client.
> 
> If you boot liberte - there is little to no configuration beyond
> establishing communication and verifying that you've done so correctly.
> Once that is done, you do not need to do it again - a key defense
> against active attackers. As I understand things this critical step
> (verification and persistence, or merely verification in a usable
> manner) cannot be done in CryptoCat at the moment. Active attackers will
> win against everyone without verification. The last bug ensured that
> *passive* attackers won against everyone on the main server and they
> would also win against everyone not using forward secret TLS modes. As I
> understand, we do not have numbers on how many users are using the less
> secure TLS modes.
> 
> Please read this page:
> 
>  https://www.ssllabs.com/ssltest/analyze.html?d=crypto.cat
> 
> On three computers near me, I see it using non-forward secret modes
> today - SSL_RSA_WITH_RC4_128_SHA - this isn't good news.
> 
> This also means that if CryptoCat's security may be reduced to SSL, it
> is now possible to reduce that to plaintext by forcing disclosure of the
> current website's key. This may happen legally or it may happen through
> exploitation. I'm not sure why CryptoCat doesn't just exclusively offer
> everything with forward secret modes, and encourage everyone else to
> upgrade their browser when they use a less secure mode? I suggested this
> to Nadim on another mailing list, I'm not sure if he is working on this
> already? Perhaps so? I hope so...
> 
> In any case, "more secure than CryptoCat" is not a high bar during the
> time of this bug. Any CA could have subverted the very little security
> provided the web browser trust model. Also the security provided by
> non-forward secret TLS connections is a really serious problem.
> 
> If you mean "as easy to use" as a plugin in a browser and that it can be
> as secure as just chatting over HTTPS protected servers without any
> other security, I think that the requirement is not proportional.
> 
> Usability is absolutely critical - but we're not looking to build usable
> software without any security - if we were, we'd all be using Facetime,
> Skype, GChat and so on, without any complaints.
> 
> All the best,
> Jacob
> --
> Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys at stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech



More information about the liberationtech mailing list