7 ms·

>The WhatsApp clients have been carefully designed so that they will not re-encrypt messages that have already been delivered. Once the sending client displays

by tyrust 10y ago

>The WhatsApp clients have been carefully designed so that they will not re-encrypt messages that have already been delivered. Once the sending client displays a "double check mark," it can no longer be asked to re-send that message. This prevents anyone who compromises the server from being able to selectively target previously delivered messages for re-encryption. Can this be verified? Can this be verified to be the case 100% of the time? Is there anything stopping the client from lying to a user [0] with this interface, saying one thing (i.e. "this will not be resent") and doing another (i.e. resending)? [0] - Or being triggered to lie to a particular user at a particular time.

UncleMeat 10y ago
If your threat model includes using a malicious app to send messages then you lose anyway. Nothing can ever be done to send messages securely using whatsapp if the client is neither trusted nor verified. This is true for basically all software that you use.
- hackuser 10y ago
  Open source software can be verified.
  - enduser 10y ago
    Source code can be verified. Binaries distributed via app stores may or may not have behavior different from the published code.
    - jMyles 10y ago
      Certainly it's possible to remedy this situation simply by having the app author sign a checksum of binaries in the app store. Why this is not currently an option (to my knowledge) is a mystery to me.
      - obscene 10y ago
        That doesn't protect you against a malicious developer.
        jMyles 10y ago
        You mean someone publishing source code and then falsely verifying the binary checksum? I mean, at the end of the day, it's very easy to verify - if the binary doesn't match what whomever gets when they compile, there better be a reason for it. Regardless, I don't think this is the biggest problem facing open source.
        Groxx 10y ago
        >if the binary doesn't match what whomever gets when they compile, there better be a reason for it. True, but deterministic compiles are stupendously difficult in most cases. Which is improving slowly, but still isn't usually an option.
        BuuQu9hu 10y ago
        Debian is up to 92% deterministic builds, so not that hard: https://tests.reproducible-builds.org/debian/reproducible.html https://tests.reproducible-builds.org/debian/reproducible.ht...
        Groxx 10y ago
        Ooh, that is a heck of a lot better than the last time I looked at it. And a very neat link - thanks!
      - Groxx 10y ago
        It kinda is - you could add it to the description. App stores seem to be getting progressively more hostile to this kind of thing though - you can't just download an APK / iOS app, you have to do it through a device. This lets the stores do "app slimming" (and per-country / per-carrier customized apks) to remove resources you don't need (like binaries that don't match your architecture), which would change the checksum. Which is useful, but inconvenient for this goal. Something like fdroid may be supportive of this, which would be cool. But I wouldn't expect the mainstream ones (or Apple) to ever embrace it - it'd be a bad user experience / wasted UI space in the vast majority of cases.
    - halomru 10y ago
      Any open source project can allow you to verify binaries by making builds reproducible. The fact that most apps don't do this is indeed a security problem, but one that's far from unfixable.
    - thesimon 10y ago
      > Source code can be verified But how often is that really done? And to be honest, it can be quite hard to spot critical bugs or backdoors, just look at http://www.underhanded-c.org/ http://www.underhanded-c.org/
      - DINKDINK 10y ago
        https://gitian.org/ https://gitian.org/ The bitcoin development community solved the problem of mapping source code to a binary build. Check sums or signatures of binaries is not sufficient. Open source is meaningless if you cannot verify the source maps to the build and you're running critical software with irreversible consequences. E.g. a bitcoin transaction or a dissident being imprisoned from state surveillance eaves dropping on communications.
    - andrepd 10y ago
      You can build and check against the binaries. What's your point?
    - Ao7bei3s 10y ago
      Reproducible builds will fix that, soon.
  - UncleMeat 10y ago
    To do this you must not only verify the open source code, but that the binary was built from this code, and that your operating system and every layer below it is also trustworthy. I stand by my claim that using software written by a malicious developer is game over in the vast majority of contexts.
    - gshulegaard 10y ago
      > verify the open source code The argument here is that open source code can be verified where closed source is explicitly non-verifiable by nature. > but that the binary was built from this code Doesn't code signing address this? If not could you explain (for my own learning)? https://en.wikipedia.org/wiki/Code_signing https://en.wikipedia.org/wiki/Code_signing > that your operating system and every layer below it is also trustworthy. Yep, this is the last major piece for true security in my mind. Although there is some movement in the open hardware space as well as USB mounted OSs (http://gizmodo.com/try-the-super-secure-usb-drive-os-that-edward-snowden-i-1563320487 http://gizmodo.com/try-the-super-secure-usb-drive-os-that-ed...). > I stand by my claim that using software written by a malicious developer is game over in the vast majority of contexts. Sure...perfectly accurate...but in the context you are implying that WhatsApp is malicious. To which I think "hackuser" was interpreting as "closed source is malicious" and therefore offering open source (and by implication Signal) as an alternative. Might just be a miscommunication moment :-)
      - kasey_junk 10y ago
        > The argument here is that open source code can be verified where closed source is explicitly non-verifiable by nature. This is not a belief that people who actually do software security audits hold. Verifying binary only software is table stakes to a security audit of a third party application as you cannot trust the source provided. Having source is a bonus for security audits not a requirement.
- amelius 10y ago
  > This is true for basically all software that you use. And hardware too.
  - akvadrako 10y ago
    And that's why we have 2FA on separate devices or even hardware tokens. They allow some security even if the computer isn't trusted, like protection against replay attacks at a minimum.
    - edejong 10y ago
      If you do not trust your hardware, 2FA is of no use. All communication and display can be MITMed on the untrusted computer. It gives the appearance of a normal login, but the behavior of the trusted site or system is emulated. The real username, password and 2FA authentication token is only send to the target machine by the attacker.
      - akvadrako 10y ago
        That's not true. It prevents replay attacks, as I said. More advanced tokens also do more. My bank uses a hardware token for signing transfers and other actions which can include a human readable message or part of the target account number, making MITM much harder.
        edejong 10y ago
        I'd say the risk of replay attack is not proportional to the risk of authenticating and authorizing on a fully compromised machine. It's comparing a candle light with a blazing fire. A definition issue with regard to "token": I sincerely do not think a device with display and keyboard used to sign transactions can be called "token". I'd say something like: trusted signing processor. But then again, I'm not a security specialist.
        akvadrako 10y ago
- andrepd 10y ago
  This is true for basically all proprietary software that you use. FTFY
contravariant 10y ago
No there's nothing stopping WhatsApp from lying to you, although if they are then the double checkmark seems like the least of your worries. As far as I can tell this 'backdoor' is only relevant for the scenario where WhatsApp is not actively malicious, but gets taken over by a malicious entity, which wants to target someone who's disabled updates.
jMyles 10y ago
Isn't it possible (in fact trivial) to sniff the traffic generated by WhatsApp and verify that it is indeed the message transmitted, encrypted by the key on the device? Has anyone performed such an audit?
- tyrust 10y ago
  This might be possible, but I don't think it addresses the issue that such an exploit could be turned on and off remotely. The only way to be sure would be to do such sniffing all the time.
  - NoodleIncident 10y ago
    Is an app like this enough for that purpose? https://play.google.com/store/apps/details?id=com.googlecode.networklog&hl=en https://play.google.com/store/apps/details?id=com.googlecode...
valarauca1 10y ago
>Can this be verified? Can this be verified to be the case 100% of the time? Is there anything stopping the client from lying to a user No. OpenWhisper system otherwise GPLv3 auditable libraries are closed source for usage by WhatsApp and Facebook Messenger. Either OpenWhisper systems has elected not to enforce their copyright (in which case you could make a BSD/MIT/Apache fork of their software), OR they have consented to Facebook allowing them to circumvent the license. Eitherway. The code in WhatsApp is off limits for anyone not working with Facebook so well never know. Closed source crypto is bad. We only have WhatsApp's word the Facebook libraries have no modifications.

by tyrust 10y ago

UncleMeat 10y ago

If your threat model includes using a malicious app to send messages then you lose anyway. Nothing can ever be done to send messages securely using whatsapp if the client is neither trusted nor verified. This is true for basically all software that you use.

hackuser 10y ago
Open source software can be verified.
- enduser 10y ago
  Source code can be verified. Binaries distributed via app stores may or may not have behavior different from the published code.
  - jMyles 10y ago
    Certainly it's possible to remedy this situation simply by having the app author sign a checksum of binaries in the app store. Why this is not currently an option (to my knowledge) is a mystery to me.
    - obscene 10y ago
      That doesn't protect you against a malicious developer.
      - jMyles 10y ago
        You mean someone publishing source code and then falsely verifying the binary checksum? I mean, at the end of the day, it's very easy to verify - if the binary doesn't match what whomever gets when they compile, there better be a reason for it. Regardless, I don't think this is the biggest problem facing open source.
        Groxx 10y ago
        >if the binary doesn't match what whomever gets when they compile, there better be a reason for it. True, but deterministic compiles are stupendously difficult in most cases. Which is improving slowly, but still isn't usually an option.
        BuuQu9hu 10y ago
        Debian is up to 92% deterministic builds, so not that hard: https://tests.reproducible-builds.org/debian/reproducible.html https://tests.reproducible-builds.org/debian/reproducible.ht...
        Groxx 10y ago
        Ooh, that is a heck of a lot better than the last time I looked at it. And a very neat link - thanks!
    - Groxx 10y ago
      It kinda is - you could add it to the description. App stores seem to be getting progressively more hostile to this kind of thing though - you can't just download an APK / iOS app, you have to do it through a device. This lets the stores do "app slimming" (and per-country / per-carrier customized apks) to remove resources you don't need (like binaries that don't match your architecture), which would change the checksum. Which is useful, but inconvenient for this goal. Something like fdroid may be supportive of this, which would be cool. But I wouldn't expect the mainstream ones (or Apple) to ever embrace it - it'd be a bad user experience / wasted UI space in the vast majority of cases.
  - halomru 10y ago
    Any open source project can allow you to verify binaries by making builds reproducible. The fact that most apps don't do this is indeed a security problem, but one that's far from unfixable.
  - thesimon 10y ago
    > Source code can be verified But how often is that really done? And to be honest, it can be quite hard to spot critical bugs or backdoors, just look at http://www.underhanded-c.org/ http://www.underhanded-c.org/
    - DINKDINK 10y ago
      https://gitian.org/ https://gitian.org/ The bitcoin development community solved the problem of mapping source code to a binary build. Check sums or signatures of binaries is not sufficient. Open source is meaningless if you cannot verify the source maps to the build and you're running critical software with irreversible consequences. E.g. a bitcoin transaction or a dissident being imprisoned from state surveillance eaves dropping on communications.
  - andrepd 10y ago
    You can build and check against the binaries. What's your point?
  - Ao7bei3s 10y ago
    Reproducible builds will fix that, soon.
- UncleMeat 10y ago
  To do this you must not only verify the open source code, but that the binary was built from this code, and that your operating system and every layer below it is also trustworthy. I stand by my claim that using software written by a malicious developer is game over in the vast majority of contexts.
  - gshulegaard 10y ago
    > verify the open source code The argument here is that open source code can be verified where closed source is explicitly non-verifiable by nature. > but that the binary was built from this code Doesn't code signing address this? If not could you explain (for my own learning)? https://en.wikipedia.org/wiki/Code_signing https://en.wikipedia.org/wiki/Code_signing > that your operating system and every layer below it is also trustworthy. Yep, this is the last major piece for true security in my mind. Although there is some movement in the open hardware space as well as USB mounted OSs (http://gizmodo.com/try-the-super-secure-usb-drive-os-that-edward-snowden-i-1563320487 http://gizmodo.com/try-the-super-secure-usb-drive-os-that-ed...). > I stand by my claim that using software written by a malicious developer is game over in the vast majority of contexts. Sure...perfectly accurate...but in the context you are implying that WhatsApp is malicious. To which I think "hackuser" was interpreting as "closed source is malicious" and therefore offering open source (and by implication Signal) as an alternative. Might just be a miscommunication moment :-)
    - kasey_junk 10y ago
      > The argument here is that open source code can be verified where closed source is explicitly non-verifiable by nature. This is not a belief that people who actually do software security audits hold. Verifying binary only software is table stakes to a security audit of a third party application as you cannot trust the source provided. Having source is a bonus for security audits not a requirement.
amelius 10y ago
> This is true for basically all software that you use. And hardware too.
- akvadrako 10y ago
  And that's why we have 2FA on separate devices or even hardware tokens. They allow some security even if the computer isn't trusted, like protection against replay attacks at a minimum.
  - edejong 10y ago
    If you do not trust your hardware, 2FA is of no use. All communication and display can be MITMed on the untrusted computer. It gives the appearance of a normal login, but the behavior of the trusted site or system is emulated. The real username, password and 2FA authentication token is only send to the target machine by the attacker.
    - akvadrako 10y ago
      That's not true. It prevents replay attacks, as I said. More advanced tokens also do more. My bank uses a hardware token for signing transfers and other actions which can include a human readable message or part of the target account number, making MITM much harder.
      - edejong 10y ago
        I'd say the risk of replay attack is not proportional to the risk of authenticating and authorizing on a fully compromised machine. It's comparing a candle light with a blazing fire. A definition issue with regard to "token": I sincerely do not think a device with display and keyboard used to sign transactions can be called "token". I'd say something like: trusted signing processor. But then again, I'm not a security specialist.
        akvadrako 10y ago
andrepd 10y ago
This is true for basically all proprietary software that you use. FTFY

contravariant 10y ago

No there's nothing stopping WhatsApp from lying to you, although if they are then the double checkmark seems like the least of your worries. As far as I can tell this 'backdoor' is only relevant for the scenario where WhatsApp is not actively malicious, but gets taken over by a malicious entity, which wants to target someone who's disabled updates.

jMyles 10y ago

Isn't it possible (in fact trivial) to sniff the traffic generated by WhatsApp and verify that it is indeed the message transmitted, encrypted by the key on the device? Has anyone performed such an audit?

tyrust 10y ago
This might be possible, but I don't think it addresses the issue that such an exploit could be turned on and off remotely. The only way to be sure would be to do such sniffing all the time.
- NoodleIncident 10y ago
  Is an app like this enough for that purpose? https://play.google.com/store/apps/details?id=com.googlecode.networklog&hl=en https://play.google.com/store/apps/details?id=com.googlecode...

valarauca1 10y ago

>Can this be verified? Can this be verified to be the case 100% of the time? Is there anything stopping the client from lying to a user No. OpenWhisper system otherwise GPLv3 auditable libraries are closed source for usage by WhatsApp and Facebook Messenger. Either OpenWhisper systems has elected not to enforce their copyright (in which case you could make a BSD/MIT/Apache fork of their software), OR they have consented to Facebook allowing them to circumvent the license. Eitherway. The code in WhatsApp is off limits for anyone not working with Facebook so well never know. Closed source crypto is bad. We only have WhatsApp's word the Facebook libraries have no modifications.