3 ms·

Steve Thomas: Yes this is scary but I believe everything is/was over https. So this just means that it was host based security. Meaning we have to trust that

by joeyh 13y ago

Steve Thomas: Yes this is scary but I believe everything is/was over https. So this just means that it was host based security. Meaning we have to trust that Cryptocat didn't store/transfer encrypted messages or leak their SSL private key. They should generate a new private key, to prevent someone from breaking into their server and stealing it. Which might let them decrypt old captured messages. Cryptocat response: Our SSL keys are safe: For some reason, there are rumors that our SSL keys were compromised. To the best of our knowledge, this is not the case. All Cryptocat data still passed over SSL, and that offers a small layer of protection that may help with this issue. whoosh

ams6110 13y ago
OK I had to think about this for a sec, not being a crypto expert by any means. Steve is not suggesting that their SSL private key HAS been compromised. He's saying that IF it were to be compromised, anyone who had captured CryptoCat traffic would now be in a position to break it easily. The suggestion is to generate a new private key (and presumably destroy the old one irrevocably) to prevent this eventuality.
graue 13y ago
$ curl -vI https://crypto.cat * About to connect() to crypto.cat port 443 (#0) * Trying 94.254.0.157... * connected * Connected to crypto.cat (94.254.0.157) port 443 (#0) * successfully set certificate verify locations: [ ... snip ... ] * SSLv3, TLS handshake, Finished (20): * SSL connection using ECDHE-RSA-RC4-SHA If my understanding is correct, ECDHE offers "perfect forward secrecy", as discussed on HN a few days ago — each session uses an ephemeral key created for just that session. So past sessions are already protected against an SSL private key compromise, and changing the key wouldn't add protection. Of course, only the Cryptocat folks could clarify what percentage (all?) of their users actually connect over an SSL method that offers PFS.
- Nursie 13y ago
  Assuming the server is set up to prefer these suites, and the browser supports them, this is good. Pretty sure all modern browsers will support this, though they may prefer other suites and the server may go with client preferences. 'course RC4 is considered more than a bit iffy itself these days.
- Spittie 13y ago
  As this blog post says, ECDHE got implemented only "in the past couple of weeks", which mean that there are still about six months of conversations that didn't use ECDHE and can be easily cracked in case someone leaks their SSL keys.

by joeyh 13y ago

ams6110 13y ago

OK I had to think about this for a sec, not being a crypto expert by any means. Steve is not suggesting that their SSL private key HAS been compromised. He's saying that IF it were to be compromised, anyone who had captured CryptoCat traffic would now be in a position to break it easily. The suggestion is to generate a new private key (and presumably destroy the old one irrevocably) to prevent this eventuality.

graue 13y ago

$ curl -vI https://crypto.cat * About to connect() to crypto.cat port 443 (#0) * Trying 94.254.0.157... * connected * Connected to crypto.cat (94.254.0.157) port 443 (#0) * successfully set certificate verify locations: [ ... snip ... ] * SSLv3, TLS handshake, Finished (20): * SSL connection using ECDHE-RSA-RC4-SHA If my understanding is correct, ECDHE offers "perfect forward secrecy", as discussed on HN a few days ago — each session uses an ephemeral key created for just that session. So past sessions are already protected against an SSL private key compromise, and changing the key wouldn't add protection. Of course, only the Cryptocat folks could clarify what percentage (all?) of their users actually connect over an SSL method that offers PFS.

Nursie 13y ago
Assuming the server is set up to prefer these suites, and the browser supports them, this is good. Pretty sure all modern browsers will support this, though they may prefer other suites and the server may go with client preferences. 'course RC4 is considered more than a bit iffy itself these days.
Spittie 13y ago
As this blog post says, ECDHE got implemented only "in the past couple of weeks", which mean that there are still about six months of conversations that didn't use ECDHE and can be easily cracked in case someone leaks their SSL keys.