19 ms·

Color me still-unconvinced. This retort does not address the fundamental point made in the Guardian piece: > “[Some] might say that this vulnerability could

• maxerickson 10y ago
  Unconvinced of what exactly?
  • tedunangst 10y ago
    I remain unconvinced that people who build messaging apps used by billions of people know more about the problem space than I do.
    • dmix 10y ago
      This may be in need of a /s.
• tucif 10y ago
  He does address this: Once the sending client displays a "double check mark," it can no longer be asked to re-send that message. That means a user is able to verify visually that the end-to-end is working. "users might not notice" doesn't seem to me as a strong argument to state this as a backdoor. This would imply not noticing that you don't have a green padlock on chrome is a backdoor too, and it clearly is not.
  • MichaelGG 10y ago
    Couldn't the server change keys after every message? The delay would be fairly small. Hold the original, change key, retransmit, change key back? Guess that is easily enough mitigated if the client won't allow switching back to the same key.
    • tucif 10y ago
      It could. I guess the point here is: Can there be a backdoor in whatsapp? Of course! Is there a backdoor on Whatsapp as described on the guardian article? No. Can the UX be improved to alert the smaller percentage of users that rely heavily on the encryption features when their communication is not being actively protected without disturbing the UX of the rest of the users? Probably yes,
      • MichaelGG 10y ago
        No it's very different. Without further details, it sounds like it's possible for FB to switch keys and intercept all messages on everyone, all the time.
        • occamrazor 10y ago
          But the sender would receive at least a notification of key change by the recipient. It is up to them to confirm the validity of the key.
      • acqq 10y ago
        > Can the UX be improved to alert the smaller percentage of users that rely heavily ... Probably yes Hell yes! Imagine jusr changing background color and the banner "somebody spies on you." Now it's something like some checkmark somewhere looks a bit different or whatever.. I'm still not sure what when...
        • estel 10y ago
          But keys changes are pretty frequent and normal things that happen between clients - this would be an awful and inappropriate warning almost every time it was shown.
  • runn1ng 10y ago
    A little. Without reading the Guardian piece, I wouldn't even guess that delivery notifications have anything in common with security properties. In other words, the messages are secure only when there is a double checkmark, not just a single checkmark. How am I supposed to know that?!? I am not even sure what do the checkmarks mean. Frankly, that's not a "backdoor", that's just a poorly thought out GUI (in my opinion), that might eventually lead to backdoors with an evil server.
    • tucif 10y ago
      Absolutely. There is no evident connection that can be done from the double checkmark to a "secured communication". But when you think about it, the double check is a read confirmation so if we are in an end-to-end encrypted scenario, and the message content was read, it means the recipient's device was able to decrypt it successfully. This tells you that the recipient is still using the same set of keys that your device thought it had and used to encrypt the message.
    • JCzynski 10y ago
      The single/double checkmark is used with Signal's client as well. When you're sending unsecured texts, you get a single checkmark when you send it; when you are sending encrypted messages, a lock symbol and a single check when sent, and a double check when received.
      • makomk 10y ago
        Except that the obvious interpretation of the second checkmark not appearing is that the message was never received, not that it was decrypted by an attacker. Especially when there's a key change warning afterwards. I think this is still the correct interpretation in Signal proper, but who knows at this point?
      • runn1ng 10y ago
        Yes, but in Signal, it doesn't have bad security consequences when its meaning is misunderstood.
  • ploxiln 10y ago
    The "green padlock" was not considered enough because users would not be able to differentiate it from a big lock symbol within the page. Thus we got HSTS. (There was a time when browsers would color the entire URL bar yellow to indicate https, but that went out of favor many years ago.) Moxie deserves respect for the web vulnerabilities he discovered and raised awareness about years ago, and for his general competence at cryptography. But in recent years he's shown himself to be willing to make catastrophic sacrifices to make security applications popular and viable for the "lay person". If the "lay person" ignores the non-obtrusive key changes, and difference between single and multiple checkmarks (and the timing of them, whether single changed to double after a key change), and just trusts that "I heard WhatsApp is secure, so I'm good to go", then so much is sacrificed that there wasn't any point in the exercise to begin with. Except that real solid systems, with direct user control over key continuity, and fully open-source, are undermined by the confusion with these "lay person" super-convenient closed-source systems.
    • tucif 10y ago
      I agree, perhaps a further version of the signal protocol could implement a definitive solution that better addresses this kind of scenario the way HSTS did for ssl certs. And combined with a friendly UI solution (like the new padlock | Secure string in chrome) would lead to easier detection of possible eavesdroppers by the lay person.
      • gepoch 10y ago
        This isn't a vulnerability in the signal protocol. More a vulnerability in a particular UX decision that WhatsApp made (consciously, even.)
    • oconnor663 10y ago
      > catastrophic sacrifices to make security applications popular and viable for the "lay person" This isn't wrong, but it's unfair to bring it up without the most obvious counter-argument. PGP provides absolutely zero security to the average person, because average people don't use it. HTTPS provides lots of security to the average person, whether or not they know what the green lock means, because lots of people use it. Adoption is a feature. Of course both of these things are true. Security sacrifices for the sake of adoption suck. But let's not paint a picture of Signal as "desperate for popularity", as though that was a selfish and not security-minded goal. Be fair.
  • moomin 10y ago
    Correct me if I'm wrong, but don't double-ticks only appear in one on one conversations? What's the story on group chats?
    • barbs 10y ago
      A double-tick will appear once everyone has received the message. You can view details on a single message to see who has received the message on an individual basis (and also who has read it).
• avn2109 10y ago
  Regardless of the merit of this specific accusational-and-denial cycle, the fact remains that Whatsapp is closed source crypto and there is no way in principle for the user to verify any security claims. I happen to trust Moxie's principles, but not as much as I distrust the relationship-with-government imperatives implied by FB's vast business interests.
  • tptacek 10y ago
    There's "no way in principle"? How is this whole story not evidence to the contrary? The person who found this didn't use WhatsApp source code. Why do you feel that there's no way to verify closed-source software?
    • akvadrako 10y ago
      Whichever story you are talking about, this one or the guardian one, it doesn't address the closed-source point. There is theoretically a way to verify WhatsApp even though it's closed source, but it's practically impossible. It's hard enough to verify software even when the source is open, you built it yourself and the whole platform and toolchain is trusted. A bunch of the potential NSA crypto backdoors were totally in the open. The app could just be lying about resending old messages or even not encrypting them or any number of things much more subtle.
      • tptacek 10y ago
        I'm sorry, but this simply isn't true. Software of far, far greater complexity than WhatsApp has been reverse engineered comprehensively by hobbyists and amateurs. Meanwhile, professionals have pretty sophisticated tools for doing this work at scale.
        • akvadrako 10y ago
          Have you ever heard of the obfuscated C contest? Even with the code in front of your face and looking innocent it's hard to see what it does. When you only have decompiled assembly, obfuscation is much easier.
• FiloSottile 10y ago
  It wouldn't be a conversation. The attacker would have to rely Alice's messages to Bob before switching the key. But then if the attacker let Alice (the target) receive Bob's messages they will learn theirs got delivered and the attack would fail. So it only works once against a string of messages with no replies. That's not a conversation.
  • jMyles 10y ago
    Another thing that's not clear to me: Is the receipt confirmation from Bob (used as the basis for the double-check) signed by Bob?
  • FabHK 10y ago
    Here's my understanding of this attack vector: * when the client is compromised, you're screwed anyways, so let's assume the client behaves as expected. * now, with "proper" e2e, and Alice and Bob verifying key fingerprints, their messages can't be read even if the server gets compromised. * as it stands now with WhatsApp, AFAI understand, the server could be compromised to take Alice's message, send it on to Bob, but withhold the "delivery receipt". It could also pass back Bob's answers, and so Alice could have what appears to be a normal conversation - except that Alice only sees single ticks, instead of double blue ticks. * then, the server could send the "hey ho, new key" message, and Alice's client would re-encrypt and re-send all messages that it thinks haven't been delivered yet, the ones with a single tick. After that, it would display the "key changed" msg to Alice (if she had set that option).
    • FiloSottile 10y ago
      > It could also pass back Bob's answers, and so Alice could have what appears to be a normal conversation - except that Alice only sees single ticks, instead of double blue ticks. No, it can't do this, because Bob's answers contain the "delivery receipt". Hence, the attack doesn't work on conversations. EDIT to reply: messages are sequential and "delivery receipts" are messages, so it would be visible if the attacker dropped some but not all messages. AFAICT.
• derefr 10y ago
  I think that just misconstrues how IM apps are used. You have conversations on IM apps: you send one line of text to a person, and then you don't send another until the person has at least seen the first one, if not yet responded. Otherwise you're being rude. And, presuming you are seeing reply-messages from your peer and having a back-and-forth conversation, I don't think it's actually possible for those reply-messages to not implicitly also be ACKs of your own sent messages—the Axolotl ratchet underlying the protocol ensures that (I think. Crypto people chime in?) So, yeah, you can probably get a retransmitted transcript of one person talking into a void without seeing any delivery ticks in response. You can't really get a conversation.
  • jMyles 10y ago
    I think that, much of the time, in a journalistic setting, apps like WhatsApp are used to report. If WhatsApp is used to report conditions at an event of political upheaval in a totalitarian state - and the receiver isn't routinely and quickly replying, this is a damn serious problem.
    • derefr 10y ago
      WhatsApp seems to be built for a threat model where a single message (and you can think of a block of messages without reply as semantically equivalent to a single message, here) being compromised is no big deal; only a conversation being compromised is a problem. If there are cases (like this) where a single-message compromise is a big deal, and WhatsApp cares about these cases, then the simplest solution would be for WhatsApp to add a preference in the client to switch on—as the article describes—a "blocking mode" for re-key notifications, where retransmissions aren't allowed by default.
      • mos_basik 10y ago
        And - as the article describes - such a blocking mode would immediately expose to WhatsApp which users had not enabled it, and who would therefore be safe(er) to MITM (because they probably don't verify key changes in any meaningful way).
• grappler 10y ago
  If you are concerned enough about the security and privacy of the app, then you should learn how to use the app. That includes learning about the indicators provided by the UI telling you about key changes, delivery notifications, and anything else the developers considered important enough to show the user.
  • sangnoir 10y ago
    This is design issue and has little to do with knowing how to use the app. It is poor design for a pending message to be delivered to a device whose key was changed after the message was sent.
• rndgermandude 10y ago
  This allows WhatsApp to MITM. Whatapps can rekey both Alice and Bob, decrypt both their messages from that point onwards (incl unsent messages) and forward them re-encrypted with their real keys. The only notification might be that rekeying warning, if the users have turned it on. In this scenario even the double-checkmarks are present. This is contrary to WhatsApp's claim that even they cannot snoop. PS: I just check on my phone if those notifications were turned on. There were not. And I'd never turn those off myself, which leads me to conclude that the rekeying notifications are off by default (in their android app)
  • Normal_gaussian 10y ago
    I can confirm that the rekeying notifications are off by default, also Android
  • ehsankia 10y ago
    I'm confused. The way I understand it is that once the double checkmark appears, those messages are locked in and never rekeyed. That means once you see those checkmarks, you're guaranteed no one can snoop on that message anymore. Assuming you have the notification on (Which anyone who cares about security could and should turn on), once you see a warning, you could just delete all messages that don't have the double checkmark (if any) and not send new ones.
    • rndgermandude 10y ago
      One checkmark = message delivered / Double checkmark = somebody read it. That somebody might as well be WhatApp doing a MITM The double checkmark stuff the blog talks about just means you cannot retroactively rekey already sent (old) messages. WhatApp inserting itself as a MITM can however read (and double checkmark) and new messages after they did the MITM rekeying
      • srathi 10y ago
        It is actually slightly different. One checkbox means received by WhatsApp, two checkboxes means received by the recipient and two blue checkboxes means read by the recipient.
• msl09 10y ago
  Adding to this reply, here is the actual complaint that generated the guardian's article: https://tobi.rocks/2016/04/whats-app-retransmission-vulnerability/ https://tobi.rocks/2016/04/whats-app-retransmission-vulnerab...
• sfifs 10y ago
  Look if WhatsApp wants to read your messages without you detecting, there's nothing you can really do to prevent it apart from not using WhatsApp. For instance if you're on some list for message interception, they can give you MITMed keys when you first login. Or they can insert some subtle signal that tells the app on your specific phone to ignore key changes and avoid showing notification in some way you would struggle to check (closed source and obfuscated code) etc etc. They could even show you the right key if you attempt verification but use a compromised one for communication. This particular vuln. would be a ridiculously crude way to intercept messages. In any closed source system where key distribution and message distribution are centralized, there is no way to protect against the service provider - and anyone who co-opts the service provider (eg. with a court order). The objective of the encryption is to protect against other actors snooping on you
  • danenania 10y ago
    Doing those sorts of things would leave a trail of evidence, though, since the attacks have to be included in public app store releases. A typical user might not be able to catch trojans in an obfuscated binary, but there are people who can, and the compromised client would be available to anyone who wanted to dig in.
    • pbasista 10y ago
      Your point being? Yes, there would be a trace in the binary. Potentially detectable by maybe one person in a million. Is that supposed to keep WhatsApp from including malicious features? I do not think so. What happens is: 1. researcher finds a malicious part in WhatsApp binary 2. WhatsApp declares it a bug and fixes with a new binary 3. we are back at square one
• FabHK 10y ago
  The discoverer of the vulnerability, t0b0, is weighing in again, saying there is a backdoor: https://tobi.rocks/2017/01/there-is-a-whatsapp-backdoor/ https://tobi.rocks/2017/01/there-is-a-whatsapp-backdoor/ Edit to add: It's also on HN (empty so far): https://news.ycombinator.com/item?id=13404263 https://news.ycombinator.com/item?id=13404263
• make3 10y ago
  I'll be turquoise