9 ms·

Critical Vulnerability in Cryptocat

111 points by amouat 13y ago

tptacek 13y ago
Cryptocat is not any different from any of the other notable privacy, encryption and security projects, in which vulnerabilities get pointed out on a regular basis and are fixed. I feel bad for the team that worked on this (although I stand by my belief that they shouldn't be working on it), but this is an extremely aggravating statement. When was the last cryptographic vulnerability discovered in any mainstream implementation of PGP? Vulnerabilities are found semi-routinely in TLS, which was designed by several of the smartest crypto people in the world. But there's a key difference between TLS and Cryptocat: the whole world is working on TLS security. Vulnerabilities in TLS that are far less critical than this one are career-making. Vulnerabilities that devastate the security of Cryptocat earn a blog post. I'm also a little confused: if the team put Steve Thomas on their thank-you page, why did Steve Thomas write a blog post linking directly to that page saying he wasn't on it? I bring this up because it's a valuable lesson for startups. You should have a thank-you page. But you should also err on the side of quickly adding people's names to it when they report things. It looks (from the pull request) like much of this was reported over a month ago. Don't wait a month to thank people who report vulnerabilities in your code.
- a_bonobo 13y ago
  >I'm also a little confused: if the team put Steve Thomas on their thank-you page, why did Steve Thomas write a blog post linking directly to that page saying he wasn't on it? The thanks on the cryptocat page wasn't there about 4-5 hours ago (last time I checked).
  - tptacek 13y ago
    Either you and Steve Thomas are right, or this release is right. Both can't be true.
    - pathy 13y ago
      The Google cache [1] from 26th of June does not show Steve Thomas' name on that page, so it seems that Steve is right and CryptoCat are not telling the truth. That said, 26th is quite a few days ago so it might have changed between then and now. [1] http://webcache.googleusercontent.com/search?q=cache%3Ahttps%3A%2F%2Fcrypto.cat%2Fbughunt%2F&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a http://webcache.googleusercontent.com/search?q=cache%3Ahttps...
      - makomk 13y ago
        Technically they're not lying since they have put his name on their thank-you page now, they're just deceiving us with the truth.
  - m0skit0 13y ago
    Yes, you're right, I checked around that same time and it wasn't there.
makomk 13y ago
"The vulnerability was so that any conversations had over Cryptocat’s group chat function, between versions 2.0 and 2.0.42 (2.0.42 not included), were easier to crack via brute force." That's quite an understatement - and they helpfully don't link to Steve Thomas's blog post so readers can't easily discover just how weak the encryption actually was. (See https://news.ycombinator.com/item?id=5989707 https://news.ycombinator.com/item?id=5989707 if it's dropped off the front page by the time you're reading this comment.)
raverbashing 13y ago
" At Cryptocat, we’ve undertaken the difficult mission of trying to bridge the gap between accessibility and security. This will never be easy." Really, Cryptocat should be commended for this Because the crypto people usually don't care and in some cases makes extra-hard for regular people (or even non experts) to have security. Like the ECB fiasco. http://www.codinghorror.com/blog/2009/05/why-isnt-my-encryption-encrypting.html http://www.codinghorror.com/blog/2009/05/why-isnt-my-encrypt... At least the documentation warns it's really a bad choice. Making technology accessible to everybody is very important
- tptacek 13y ago
  Wanting hard problems to be easy doesn't make them easy. Computer science and math don't care how much you need cryptography. And, a reminder: while I agree that we could use better UX for GPG, that's not what Cryptocat is. Cryptocat is simpler to use because it's a simpler, less secure system. The Cryptocat team seems to have a flair for attractive, usable interfaces, and people seem to like the way Cryptocat works. They should spend their time building a similar interface for GPG and give up on the custom cryptosystem. They wouldn't be able to say they'd designed their own cryptosystem, but in reality, people with a professional understanding of cryptography would think more highly of them for that, not less.
  - raverbashing 13y ago
    > Cryptocat is simpler to use because it's a simpler, less secure system. Simple does not need to mean less secure. HTTPS is easy (for the user) and secure. > They should spend their time building a similar interface for GPG and give up on the custom cryptosystem Yes, that could be an approach, using a higher level crypto infrastructure and focusing on the UX.
    - tptacek 13y ago
      No, that's not true. HTTPS is simpler than GPG and also provides less security. You rely on HTTPS/TLS today with certificate-pinned DHE HTTPS connections to Gmail. Clearly, the people who use Cryptocat don't feel like they're getting enough security from Gmail. HTTPS is simpler to use because it's a simpler, less secure system.
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.
tete 13y ago
> Private chats are not affected: Private queries (1-on-1) are handled over the OTR protocol, and are therefore completely unaffected by this bug. Their security was not weakened. Hey, that sounds great to me. Also wouldn't it be possible to talk to multiple parties, by simply doing the OTR-Jazz to every party? Would kinda be hack, but would make sure you can use that cool OTR protocol that is secure or am I wrong somewhere?
- whackedspinach 13y ago
  I would be careful before trying this. I don't know much about crypto, but you might be able to do some interesting statistical attacks if you are encrypting the same plaintext with multiple keys.
hnolable 13y ago
Does anyone know if there are any issues with the javascript OTR library they use (https://github.com/arlolra/otr https://github.com/arlolra/otr)? Or are all the issues only with their custom multi party chat encryption system?
X4 13y ago
The man in the "black suits" that were folloing Nadim Kobeissi, didn't have anything todo with these bugs right? However I'm sure that the NSA can crack SSL/TLS in a matter of minutes, not because they have such powerfull secret hardware, but because they probably have agents that spotted or added bugs here and there in different software. Wouldn't that mean that even when you invented a perfectly secure super encryption, they could wiretap your OS and get the message in cleartext without your consent. Thanks to backdoors, bugs and incompetence.

111 points by amouat 13y ago

Cryptocat is not any different from any of the other notable privacy, encryption and security projects, in which vulnerabilities get pointed out on a regular basis and are fixed. I feel bad for the team that worked on this (although I stand by my belief that they shouldn't be working on it), but this is an extremely aggravating statement. When was the last cryptographic vulnerability discovered in any mainstream implementation of PGP? Vulnerabilities are found semi-routinely in TLS, which was designed by several of the smartest crypto people in the world. But there's a key difference between TLS and Cryptocat: the whole world is working on TLS security. Vulnerabilities in TLS that are far less critical than this one are career-making. Vulnerabilities that devastate the security of Cryptocat earn a blog post. I'm also a little confused: if the team put Steve Thomas on their thank-you page, why did Steve Thomas write a blog post linking directly to that page saying he wasn't on it? I bring this up because it's a valuable lesson for startups. You should have a thank-you page. But you should also err on the side of quickly adding people's names to it when they report things. It looks (from the pull request) like much of this was reported over a month ago. Don't wait a month to thank people who report vulnerabilities in your code.

a_bonobo 13y ago
>I'm also a little confused: if the team put Steve Thomas on their thank-you page, why did Steve Thomas write a blog post linking directly to that page saying he wasn't on it? The thanks on the cryptocat page wasn't there about 4-5 hours ago (last time I checked).
- tptacek 13y ago
  Either you and Steve Thomas are right, or this release is right. Both can't be true.
  - pathy 13y ago
    The Google cache [1] from 26th of June does not show Steve Thomas' name on that page, so it seems that Steve is right and CryptoCat are not telling the truth. That said, 26th is quite a few days ago so it might have changed between then and now. [1] http://webcache.googleusercontent.com/search?q=cache%3Ahttps%3A%2F%2Fcrypto.cat%2Fbughunt%2F&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a http://webcache.googleusercontent.com/search?q=cache%3Ahttps...
    - makomk 13y ago
      Technically they're not lying since they have put his name on their thank-you page now, they're just deceiving us with the truth.
- m0skit0 13y ago
  Yes, you're right, I checked around that same time and it wasn't there.

makomk 13y ago

"The vulnerability was so that any conversations had over Cryptocat’s group chat function, between versions 2.0 and 2.0.42 (2.0.42 not included), were easier to crack via brute force." That's quite an understatement - and they helpfully don't link to Steve Thomas's blog post so readers can't easily discover just how weak the encryption actually was. (See https://news.ycombinator.com/item?id=5989707 https://news.ycombinator.com/item?id=5989707 if it's dropped off the front page by the time you're reading this comment.)

raverbashing 13y ago

" At Cryptocat, we’ve undertaken the difficult mission of trying to bridge the gap between accessibility and security. This will never be easy." Really, Cryptocat should be commended for this Because the crypto people usually don't care and in some cases makes extra-hard for regular people (or even non experts) to have security. Like the ECB fiasco. http://www.codinghorror.com/blog/2009/05/why-isnt-my-encryption-encrypting.html http://www.codinghorror.com/blog/2009/05/why-isnt-my-encrypt... At least the documentation warns it's really a bad choice. Making technology accessible to everybody is very important

tptacek 13y ago
Wanting hard problems to be easy doesn't make them easy. Computer science and math don't care how much you need cryptography. And, a reminder: while I agree that we could use better UX for GPG, that's not what Cryptocat is. Cryptocat is simpler to use because it's a simpler, less secure system. The Cryptocat team seems to have a flair for attractive, usable interfaces, and people seem to like the way Cryptocat works. They should spend their time building a similar interface for GPG and give up on the custom cryptosystem. They wouldn't be able to say they'd designed their own cryptosystem, but in reality, people with a professional understanding of cryptography would think more highly of them for that, not less.
- raverbashing 13y ago
  > Cryptocat is simpler to use because it's a simpler, less secure system. Simple does not need to mean less secure. HTTPS is easy (for the user) and secure. > They should spend their time building a similar interface for GPG and give up on the custom cryptosystem Yes, that could be an approach, using a higher level crypto infrastructure and focusing on the UX.
  - tptacek 13y ago
    No, that's not true. HTTPS is simpler than GPG and also provides less security. You rely on HTTPS/TLS today with certificate-pinned DHE HTTPS connections to Gmail. Clearly, the people who use Cryptocat don't feel like they're getting enough security from Gmail. HTTPS is simpler to use because it's a simpler, less secure system.

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.

tete 13y ago

> Private chats are not affected: Private queries (1-on-1) are handled over the OTR protocol, and are therefore completely unaffected by this bug. Their security was not weakened. Hey, that sounds great to me. Also wouldn't it be possible to talk to multiple parties, by simply doing the OTR-Jazz to every party? Would kinda be hack, but would make sure you can use that cool OTR protocol that is secure or am I wrong somewhere?

whackedspinach 13y ago
I would be careful before trying this. I don't know much about crypto, but you might be able to do some interesting statistical attacks if you are encrypting the same plaintext with multiple keys.

hnolable 13y ago

Does anyone know if there are any issues with the javascript OTR library they use (https://github.com/arlolra/otr https://github.com/arlolra/otr)? Or are all the issues only with their custom multi party chat encryption system?

X4 13y ago

The man in the "black suits" that were folloing Nadim Kobeissi, didn't have anything todo with these bugs right? However I'm sure that the NSA can crack SSL/TLS in a matter of minutes, not because they have such powerfull secret hardware, but because they probably have agents that spotted or added bugs here and there in different software. Wouldn't that mean that even when you invented a perfectly secure super encryption, they could wiretap your OS and get the message in cleartext without your consent. Thanks to backdoors, bugs and incompetence.