Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification on OTR functionality in Legacy Conversations #2943

Closed
drduh opened this issue Apr 6, 2018 · 11 comments
Closed

Clarification on OTR functionality in Legacy Conversations #2943

drduh opened this issue Apr 6, 2018 · 11 comments

Comments

@drduh
Copy link

drduh commented Apr 6, 2018

Hi,

In #2908, it was said:

OTR was removed because it was highly unreliable, doesn’t work with multiple devices, was never really specified to work with XMPP [...] The way it was implemented meant it didn’t actually do any verification.

What does the latter clause mean? Do you mean that OTR was not implemented properly and users of Conversations were/are vulnerable to a man in the middle attack? Or do you mean that an OTR session also required the additional step of identity verification? Please clarify whether Legacy Conversations, which still has OTR functionality, actually implements the protocol properly.

Thanks

@iNPUTmice
Copy link
Owner

iNPUTmice commented Apr 6, 2018 via email

@drduh
Copy link
Author

drduh commented Apr 10, 2018

I think that's false.

From https://otr.cypherpunks.ca/index.php#faqs

Off-the-Record (OTR) Messaging allows you to have private conversations over instant messaging by providing:
[...]
Authentication
You are assured the correspondent is who you think it is.

From https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html

The general idea is that Alice and Bob do an unauthenticated Diffie-Hellman (D-H) key exchange to set up an encrypted channel, and then do mutual authentication inside that channel.

From https://otr.cypherpunks.ca/help/authenticate.php

You should authenticate a buddy the very first time that you talk to them using OTR. If you don't, then you can't really be sure that someone else isn't impersonating them or trying to listen in on your conversation. However, once you've authenticated your buddy once, you don't have to do it again. OTR will automatically do the authentication for all of your future conversations with that buddy.
The only exceptions occur when your buddy switches between multiple computers or multiple IM accounts. In this case, you will need to authenticate once for each computer and account. Once you've done this, your buddy can freely use any of the computers you've authenticated them on, and OTR will recognize them automatically. If your buddy uses a new computer or account that OTR does not recognize, a message will pop up in your conversation window telling you about it.

The fact you are apparently unaware of this is very troubling, indeed.

@licaon-kter
Copy link

licaon-kter commented Apr 10, 2018

Didn't Conversations already have this?

proof

@drduh
Copy link
Author

drduh commented Apr 13, 2018

That was also my impression, but the author is indicating he did not properly implement such a mechanism. So it remains unanswered, whether OTR in Conversations ever vulnerable to a MITM due to no actual verification. The fact that I can't get a straight answer to this question is really disappointing.

@iNPUTmice
Copy link
Owner

I’m not sure whats not to understand if I say that Conversations didn’t do any sort of verification.

@drduh
Copy link
Author

drduh commented Apr 13, 2018

Are you purposefully being facetious? Conversation prompted to verify OTR participants' identities, exactly like @licaon-kter showed in the screenshot, either through Q&A or by manually verifying fingerprints. So what I don't understand is why you keep saying there's no verification - was the aforementioned functionality not effectual, or do you mean something else entirely by "verification"?

@jesse-git
Copy link

I receive a warning about "OMEMO fingerprint blindly trusted" or something similar, but not when setting up OTR (yet). It would seem to me that the OMEMO implementation is the one that's dangerous, not OTR. I'm using 1.23.8

@licaon-kter
Copy link

@jesse-git Settings-Expert-Disable BTBV

Read about BTBV here: https://gultsch.de/trust.html

@jesse-git
Copy link

Thank you for that explanation and for preserving the "classic" behavior as an option. I, for one, am the type of user who wants to verify keys if at all possible and am willing to spend the extra couple of minutes doing it.

@TRSx80
Copy link

TRSx80 commented Jul 23, 2018

Yeah I also noticed that at some point the default became to blindly trust instead of verifying keys. I thought it very strange at the time (and still do) in such a security/privacy focused app.

Whenever I turn new people on to Conversations and XMPP I always explain what MitM attacks are and why it's important to verify keys. And then we do it together. It only takes a few moments.

Incidentally, I also noticed that the barcode scanner finally works to do this, making it even easier!

@ghost
Copy link

ghost commented Jul 26, 2018

So why do you made OTR available in the 1st place if you now admit that it wasn't correctly implemented, knowingly? What you saying is that everyone who used OTR in conversations was betrayed by fake security from the start.
Conversations isn't trustworthy cause of its developer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants