[cryptography] DeCryptocat

Jacob Appelbaum jacob at appelbaum.net
Fri Jul 5 14:34:01 EDT 2013


Nadim Kobeissi:
> Sorry, I wasn't meaning to avoid any questions. I simply forgot to
> answer them. It's best to assume good will from others on a
> discussion list.

Glad to hear it.

> 
> I do not know how many users choose forward secret protocols, nor do
> I imagine there is a standardized or easy way to derive that
> knowledge. This is why private keys were reset, even though we use
> forward secrecy.

It appears that you're using nginx - it seems reasonable to discover
this information:

  http://mailman.nginx.org/pipermail/nginx/2010-July/021228.html
  http://wiki.nginx.org/NginxHttpSslModule#Built-in_variables

This directs us here:

"Module ngx_http_ssl_module supports the following built-in variables:

"$ssl_cipher returns the cipher suite being used for the currently
established SSL/TLS connection

"$ssl_protocol returns the protocol of the currently established SSL/TLS
connection — depending on the configuration and client available options
it's one of SSLv2, SSLv3 or TLSv1

=================================

If CryptoCat is not rotating keys frequently, as some companies do for
these modes, I guess that one rotation is not enough. CryptoCat is
currently offering non-forward secret modes for some people - so the
original concern really holds, sadly. SSL and TLS security is really
painful sometimes. :(

I could imagine that people who select such dangerous modes could be
redirected to a page that refuses chat service until they upgrade their
browser? Or perhaps something else that mitigates likely harm? That at
least prevents users from potentially using TLS in a dangerous manner as
they have been for quite some time.

However - if no one is using them, can't you just disable them? And if
many people are using them, will you ensure that they will fail closed
by disabling them? Or perhaps by rotating keys on a daily basis?

This seems like an important and relevant set of points:

  https://www.imperialviolet.org/2013/06/27/botchingpfs.html

All the best,
Jake


More information about the cryptography mailing list