Critical Vulnerability in Cryptocat
blog.crypto.cat
blog.crypto.cat
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.
The thanks on the cryptocat page wasn't there about 4-5 hours ago (last time I checked).
[1] http://webcache.googleusercontent.com/search?q=cache%3Ahttps...
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
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.
$ 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
Of course, only the Cryptocat folks could clarify what percentage (all?) of their users actually connect over an SSL method that offers PFS.
'course RC4 is considered more than a bit iffy itself these days.
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 if it's dropped off the front page by the time you're reading this comment.)
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-encrypt... At least the documentation warns it's really a bad choice.
Making technology accessible to everybody is very important
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.
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.
You just seem to be confirming my point, that in the name of "more security" they're shunning everything that's not their idea of "perfect security" (which may be faulty). Result: less people using encryption.
It's one thing to use a fragile encryption key like the Cryptocat failure, another to exclude RSA in favour of ECC (except if you're dealing with leaking government secrets of course)
To apply SSL to a cryptocat style system would require both parties to generate keys and somehow verify them, not so simple.
The CA problems with HTTPS/TLS aren't fundamental to SSL/TLS. They're a consequence of browser UI. If you build your own software that uses TLS to make secure connections, you have a variety of options to avoid the browser CA problem; you can run your own CA (every instance of Burp Suite, the industry standard web pentest tool, does exactly that), or you can verify certificate fingerprints statically, or you can invent a new authentication system.
Alice -> Bob
without doing.
Alice -> Facebook -> Bob
Unless both alice and bob know how to generate and manage their own keys (and verify each others keys).
The problem is there is no "mpOTR" for them to switch to for multiperson. I'd argue for SSL protected IRC (like, SILC) and some kind of transparent/tamper-evident server on an .onion as an interim measure, instead of a roll-your-own alternative.
Resistance to compelled disclosure (at least for historical stuff; they could still turn someone and force him to chat with people with an FBI agent watching over his shoulder...) is the benefit for PFS in the user to user case.
I strongly agree with you.
Unfortunately they have made security less accessible.
Why are they rolling their own crypto, and not trying to make some existing product easier to talk?
> At least the documentation warns it's really a bad choice.
It seems the warnings are small and the hype is big.
What if the technology is fundamentally flawed and the users are at risk for using it?
GPG and such are terrible to use, imo, but at least they work. CryptoCat could be exploited with relative ease, at least at times. Considering their considered demographic, this is quite dangerous.
It's not because crypto people don't care, it's because privacy is hard.
Say you and a friend are in opposite corners of a crowded room and you have to somehow come up with a mutual secret by yelling at each other with everyone listening. Do you think you'd be able to design a way to do it? Thanks to Diffie and Hellman, that's not only possible, but rather easy.
Do you think you could design a seamless way for all your snail mail to be private, even when the post office has an unlimited budget and its #1 priority is to read your mail? I'm pretty sure you'd make some concessions, such as "you have to lock it in a box before sending", and then make sure the recipient had the corresponding key, etc etc. Saying "these security guys make me jump through all these hoops, if they cared about me I could just send the exposed letter and it'd somehow be secure" is not only unfair, but completely unrealistic.
So we should commend young, inexperienced kids with no medical training and an obviously deeply flawed understanding of neuroscience - for bringing easy-to-use "home brain surgery kits" to "regular people or even non-experts".
"At Trepan-o-cat, we've undertaken the difficult mission of trying to bridge the gap between practical first aid kit use, and frontal cortex lobotomy. This will never be easy."
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?
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.