In India where I currently live, foreigners on tourist visas often use numbers for less than six months. Those numbers get reused, and on many occasions my contact in WhatsApp has changed, for example, from a German guy to an Indian girl! The only warning that came from this is the profile picture and status message changed. Messaging them happens flawlessly with no warning that the other user is no longer your friend. It even keeps the chat history as one identity, which can be really hilarious out of context. ð
So in my experience, WhatsApp as a client just swallows the exception quietly. Makes sense, considering that as far as we know they still haven't ported their Windows phone or iPhone versions to use libaxolotl. I cannot say that I have seen this in a truly Android-to-Android scenario.
Anyway, I hope that's useful to you. My opinion/experience with WhatsApp is that they couldn't care less about an untrusted identity exception.
Jeff
-----Original Message-----
From: "drakula 84" <***@gmail.com>
Sent: â8/â30/â2015 4:39
To: "Jeff R" <***@gmail.com>
Cc: "James Firth" <***@james-firth.com>; "***@lists.riseup.net" <***@lists.riseup.net>
Subject: Re: [whispersystems] Untrusted identity key
Thanks for the responses..
It totally makes sense why this step is there when the identity key changes. And I know what I outline is a security issue. However, I am just wondering why WhatsApp doesn't do this (I didn't try very recently, but as far as I remember you dont get any notification if your contact has removed and reinstalled the app hence changed the keys).. although it was claimed in the press that they adapted the same protocol. Might they have a better idea to deal with this scenario and avoid user intervention with the fact that most ordinary users would get confused with this? Or do they just prefer a smoother user experience at the expense of a security hole?
On Sat, Aug 29, 2015 at 4:51 PM, Jeff R <***@gmail.com> wrote:
You probably just need to remove the conditional on line 107 of:
https://github.com/WhisperSystems/libaxolotl-java/blob/4b48599f8925a242584901b4f204017a63d7c768/java/src/main/java/org/whispersystems/libaxolotl/SessionBuilder.java
But, as James explained, this seems like a really bad idea no matter how you slice it. I won't stop you from making your own custom build to function that way, but I for one sure don't want the app to do that!
Jeff
On Sat, Aug 29, 2015 at 9:08 PM, James Firth <***@james-firth.com> wrote:
From my understanding of things this would remove a primary security feature of TextSecure: Knowing you are talking to the person you think you're talking to.
However, to answer your question I believe it would be a client side change, likely removing a few calls/changing some conditionals (not looking at the code right now) but this is a bad idea and a security issue as you mentioned. Due to the security concerns I cannot see it ever being implemented as a configuration option (especially as OWS doesn't like adding excessive configuration options).
I know you said you understand it would be a security issue but I'd like to outline the reasoning in case anyone else in the mailing list doesn't :)
The untrusted identity key occurs when a friend reinstalls, but it is also the flag for a potential man-in-the-middle attack. The purpose of the validation is to ensure your friend *did* in fact reinstall and that the new key isn't from an attack.
By automatically trusting the key as you suggested, you remove the validation step and thus can no longer trust anyone you are talking to as you haven't verified anyone's identity/would not be alerted when an identity key changed unexpectedly.
On Sat, Aug 29, 2015 at 9:18 AM drakula 84 <***@gmail.com> wrote:
Hi All
(I had sent this to whispersystems-community-unofficial as well, sorry for cross-posting).
When the remote party removes the app and installs it again, and when you try to send them a message, you get the untrusted identity key information and you need to go ahead and validate the key manually by pressing a few buttons. For example on Android, libaxolotl throws UntrustedIdentityException when that happens. I think I get the idea behind that design and it makes sense.
Although it would be a security issue, is it possible to make this configurable somehow so that you automatically trust the remote party's identity? Kind of an always trust model? Anybody has any idea on what would it take to implement this? At glance, I think it would be client side change.