3 ms·

This is most alarming. CryptoCat's OTR implementation on all platforms allows a chat peer to change their OTR key during a chat session without user notiﬁcatio

This is most alarming. CryptoCat's OTR implementation on all platforms allows a chat peer to change their OTR key during a chat session without user notiﬁcation. An attacker performing a man-in-the-middle attack against the client's XMPP or HTTPS stream can inject their own OTR key in the discussion after a user has authenticated their peer's OTR ﬁngerprint. This permits the attacker to decrypt all messages that follow, and no user would have reason to suspect the compromise.

kaeporan 13y ago
Fixes and improvements to this, and more, are covered in our blog post. I strongly urge you to read it. This audit alone doesn't give enough context. https://blog.crypto.cat/2014/04/recent-audits-and-coming-improvements/ https://blog.crypto.cat/2014/04/recent-audits-and-coming-imp...
- anologwintermut 13y ago
  What's your fix for the man-in-the-middle attack on all platforms (including deployed ones) the audit identifies and your blog acknowledges? In your blog post there seems to be little context that can excuse such a mistake and nothing that explains how you fix it? Am I correct in reading your blog post that right now there isn't a fix? I.e. it's an open attack assuming someone compromises a CA or a cryptocat server? Isn't this a rather big issue since the only point of cryptocat is to protect against that kind of an attack. If you just wanted security only against eavesdroppers(i.e. you trusted the chat server), xmpp over TLS would work fine.
  - kaeporan 13y ago
    Hi there, The fix for the MITM bug is to offer proper notice via the user interface when a user re-keys with a different public key. There's a demonstration of the user interface element in the blog post.
  - sneak 13y ago
    > In your blog post there seems to be little context that can excuse such a mistake This is a recurring theme with cryptocat. Stay away for 5-10 years until they get their act together.
daira 13y ago
This issue (or one with very similar effect) was also found by the Least Authority audit: https://github.com/cryptocat/cryptocat/issues/607 https://github.com/cryptocat/cryptocat/issues/607 (The 'issue E' that it references is https://github.com/cryptocat/cryptocat/issues/606 https://github.com/cryptocat/cryptocat/issues/606 .)
- daira 13y ago
  Actually I strongly suggest reading these in conjunction with iSec's issues 12 through 16, because each team spotted some details that the other missed.
  - tptacek 13y ago
    Are you sure that's not because the different teams had different scopes? The iSEC audit was specifically tied to the iOS application.
    - daira 13y ago
      The scopes had a great deal of overlap; although we (Least Authority) didn't consider the iOS client at all, the rest of iSec's audit has essentially the same scope as ours. The point I was trying to highlight is how easy it is to miss things, and therefore that having independent concurrent audits is actually a really good idea. It would probably be even better if the teams worked mostly independently but were able to exchange draft versions of their reports (before the mitigations necessary for a public release).

kaeporan 13y ago

Fixes and improvements to this, and more, are covered in our blog post. I strongly urge you to read it. This audit alone doesn't give enough context. https://blog.crypto.cat/2014/04/recent-audits-and-coming-improvements/ https://blog.crypto.cat/2014/04/recent-audits-and-coming-imp...

anologwintermut 13y ago
What's your fix for the man-in-the-middle attack on all platforms (including deployed ones) the audit identifies and your blog acknowledges? In your blog post there seems to be little context that can excuse such a mistake and nothing that explains how you fix it? Am I correct in reading your blog post that right now there isn't a fix? I.e. it's an open attack assuming someone compromises a CA or a cryptocat server? Isn't this a rather big issue since the only point of cryptocat is to protect against that kind of an attack. If you just wanted security only against eavesdroppers(i.e. you trusted the chat server), xmpp over TLS would work fine.
- kaeporan 13y ago
  Hi there, The fix for the MITM bug is to offer proper notice via the user interface when a user re-keys with a different public key. There's a demonstration of the user interface element in the blog post.
- sneak 13y ago
  > In your blog post there seems to be little context that can excuse such a mistake This is a recurring theme with cryptocat. Stay away for 5-10 years until they get their act together.

daira 13y ago

This issue (or one with very similar effect) was also found by the Least Authority audit: https://github.com/cryptocat/cryptocat/issues/607 https://github.com/cryptocat/cryptocat/issues/607 (The 'issue E' that it references is https://github.com/cryptocat/cryptocat/issues/606 https://github.com/cryptocat/cryptocat/issues/606 .)

daira 13y ago
Actually I strongly suggest reading these in conjunction with iSec's issues 12 through 16, because each team spotted some details that the other missed.
- tptacek 13y ago
  Are you sure that's not because the different teams had different scopes? The iSEC audit was specifically tied to the iOS application.
  - daira 13y ago
    The scopes had a great deal of overlap; although we (Least Authority) didn't consider the iOS client at all, the rest of iSec's audit has essentially the same scope as ours. The point I was trying to highlight is how easy it is to miss things, and therefore that having independent concurrent audits is actually a really good idea. It would probably be even better if the teams worked mostly independently but were able to exchange draft versions of their reports (before the mitigations necessary for a public release).