11 ms·

End-to-end (E2E) code needs to be open source and venders that don't agree to an audit should be considered insecure; holds true for What's App, which declined

by nxzero 11y ago

End-to-end (E2E) code needs to be open source and venders that don't agree to an audit should be considered insecure; holds true for What's App, which declined to allow their E2E code to be audited. Also, message metadata is still being leaked by all of these E2E implementations and needs to be fixed.

ryanlol 11y ago
That's just an utterly ridiculous proposition. By that logic the entire application would need to be open source, because nobody would start out by targeting the crypto if they wanted to spy on someone.
- ikeboy 11y ago
  Ideally it would be possible to use third party clients to connect, and so anyone could use a fully open source solution if they wanted.
  - ryanlol 11y ago
    That's fair! But you need far more than just the crypto code to create a client, I think open source protocol specs would already achieve this. And my main complaint was with the claim that open sourcing their crypto code would somehow make a meaningful difference to the security of these applications to the extent where you could consider all applications that haven't done so "insecure".
    - CaptSpify 11y ago
      I don't think I get your complaint Without open-sourcing the crypto, they could be just doing rot16($message) for all we know. Open-source is a requirement for being considered secure. It doesn't mean they aren't secure if they aren't open-source, but that you shouldn't consider it so, because you don't know if it is or not.
      - CiPHPerCoder 11y ago
        > I don't think I get your complaint > Without open-sourcing the crypto, they could be just doing rot16($message) for all we know. There are two things you can do: 1. Watch the outbound traffic and attempt known-plaintext attacks 2. Reverse engineer the app Neither is particularly difficult. Most Android apps are trivial to break apart using Lobotomy. A large swath of software security folks specialize in binary auditing.
        ikeboy 11y ago
        Has anyone done that and produced a fully open source app to connect to whatsapp?
        ryanlol 11y ago
        Lots of people. https://github.com/tgalal/yowsup https://github.com/tgalal/yowsup for example
        ikeboy 11y ago
        Looks like WhatsApp isn't so happy about that ... https://gigaom.com/2015/01/20/whatsapp-cracks-down-on-people-using-unofficial-clients/ https://gigaom.com/2015/01/20/whatsapp-cracks-down-on-people... Do you know if the clients work with the new encryption?
        ryanlol 11y ago
        Yes, axolotl is open source. (However I can't comment on how much it's been modified for the official client)
- tremon 11y ago
  Even if I were to accept your logic, what's ridiculous about that?
  - ryanlol 11y ago
    Open sourcing the crypto code wouldn't be ridiculous, but pointless. What I find ridiculous though was >venders that don't agree to an audit should be considered insecure The same thing applies to every single part of the application, but not equally. No attacker is going to start out by trying to break the crypto, unless it's obviously broken. "Normal" bugs are far more common and often more dangerous (Thing RCE, or in the case of many modern apps: XSS)
    - CiPHPerCoder 11y ago
      > No attacker is going to start out by trying to break the crypto, unless it's obviously broken. Emphasis mine. I agree with ryanlol here. Why bother with active attacks when you can just steal their private key from a code execution? Similar to this, but with the priority flipped: https://www.bishopfox.com/blog/2016/04/if-you-cant-break-crypto-break-the-client-recovery-of-plaintext-imessage-data/ https://www.bishopfox.com/blog/2016/04/if-you-cant-break-cry...
- imaginenore 11y ago
  ryanlol is correct though. If you open source just the end-to-end crypto part, it doesn't mean that the there's no backdoor elsewhere - it could easily leak the keys or whole conversations. The second problem is - you don't know if that source is what ended up in the binary. So yeah, unless you can compile the whole thing yourself, it should not be considered secure.
  - exo762 11y ago
    Open source client and reproducible builds. Signal already does that. It's not a high bar.
    - ryanlol 11y ago
      That's a completely different from just wanting the e2e crypto source, which is useless by itself. https://www.bishopfox.com/blog/2016/04/if-you-cant-break-crypto-break-the-client-recovery-of-plaintext-imessage-data/ https://www.bishopfox.com/blog/2016/04/if-you-cant-break-cry...
      - nxzero 11y ago
        What to you are steps towards the mass adoption of universal turnkey state-level OPSEC for everyday use? ___ So, my point that the E2E should be open source is that that code should never be the basis for a business model, so to me, it being open source makes sense. As larger system, that's why I'm saying there needs to be an audit. Also, you mentioned ATP and I agree, which is why to me it is troubling Signal instead of guarding metadata, actively collects it. Please let me know I have missed anything you'd like me to address. And I really would be interested in your thought on the question above in as much detail as you're able to share. Thanks!
mtgx 11y ago
Would open sourcing the Whatsapp client hurt Whatsapp in any significant way? I mean, sure, there could be "Whatsapp clones" (aren't there already?!), but wouldn't Whatsapp still benefit from the phone number user base it has, thus maintaining a certain lock-in on its users from which it already benefits?
- andrey_utkin 11y ago
  > I mean, sure, there could be "Whatsapp clones" (aren't there already?!) Sounds funny if you consider that Whatsapp itself is just a branded deployment of FOSS XMPP server Ejabberd, with feature of federation taken away. Plus a client app implementation, of course.
  - jeena 11y ago
    That is only possible because Ejabberd doesn't use the AGPL license.
    - goodplay 11y ago
      Come on, it would definitely still be possible with AGPL code. What brought people to whatsapp is its ubiquity and the fact that it just works, and what keeps them from going elsewhere is the inevitable network effect. Nothing in the AGPL prevents either from occurring.
      - onli 11y ago
        I think you are misunderstanding jeena. If ejabberd were AGPL, then a fork/a instance of it like Whatsapp would be legally obliged to open up their code as well. No idea whether the assumption is true that Whatsapp is just a branded deployment.
        goodplay 11y ago
        I still don't understand how opening up the codebase would prevent them from being successful. As the countless messaging apps out there demonstrate, the value of communication apps lies in the network they build. If they provide a decent UX, and successfully bootstrap a network large enough, it wont matter if their code is open.
mikeokner 11y ago
> Also, message metadata is still being leaked by all of these E2E implementations and needs to be fixed. Ricochet (https://ricochet.im/ https://ricochet.im/) solves that problem using Tor hidden services. Desktop only at the moment AFAIK, though.
- nxzero 11y ago
  Are there any stats posted on the size of the network? (either from Tor or P2P network analysis)
- vox_mollis 11y ago
  One great benefit to ricochet is that you can choose to exclude those with whom you are communicating from your COMSEC threat model, due to the lack of (mostly connection) metadata availability.
  - nxzero 11y ago
    Sounds interesting. Appears to have a lot of docs/code, are you able to link to the related code & docs?
tptacek 11y ago
WhatsApp's "E2E" code is from Signal, which is open source. This zealous belief that all secure cryptography must be open source is something I hear a lot from open source advocates, but not so much from cryptography engineers.
- arbsn 11y ago
  Is the encryption/decryption code in WhatsApp open-source? I haven't been able to find it. My assumption was that they conform to the Signal encryption protocol, which is openly specified, but that the code they use to do so is not open-source.
  - moxie 11y ago
    Yes, it is. It's linked directly from the paper (https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf https://www.whatsapp.com/security/WhatsApp-Security-Whitepap...) that documents their use of the protocol. It's the exact same code we use in Signal: https://github.com/whispersystems/libsignal-protocol-java https://github.com/whispersystems/libsignal-protocol-java
- AJ007 11y ago
  The value is not just the public display of the source code for auditing, but the validation that what you are running was indeed compiled from that code.
  - russell_h 11y ago
    Simply open sourcing the code doesn't give that validation.
    - AckSyn 11y ago
      Not completely but I can certainly look at it, compile, and then side-load it onto my device knowing it's what it said it was.
  - brianacton 11y ago
moxie 11y ago
> which declined to allow their E2E code to be audited. Could you cite this? The Signal Protocol implementations they're using are both open source and well audited.

by nxzero 11y ago

ryanlol 11y ago

That's just an utterly ridiculous proposition. By that logic the entire application would need to be open source, because nobody would start out by targeting the crypto if they wanted to spy on someone.

ikeboy 11y ago
Ideally it would be possible to use third party clients to connect, and so anyone could use a fully open source solution if they wanted.
- ryanlol 11y ago
  That's fair! But you need far more than just the crypto code to create a client, I think open source protocol specs would already achieve this. And my main complaint was with the claim that open sourcing their crypto code would somehow make a meaningful difference to the security of these applications to the extent where you could consider all applications that haven't done so "insecure".
  - CaptSpify 11y ago
    I don't think I get your complaint Without open-sourcing the crypto, they could be just doing rot16($message) for all we know. Open-source is a requirement for being considered secure. It doesn't mean they aren't secure if they aren't open-source, but that you shouldn't consider it so, because you don't know if it is or not.
    - CiPHPerCoder 11y ago
      > I don't think I get your complaint > Without open-sourcing the crypto, they could be just doing rot16($message) for all we know. There are two things you can do: 1. Watch the outbound traffic and attempt known-plaintext attacks 2. Reverse engineer the app Neither is particularly difficult. Most Android apps are trivial to break apart using Lobotomy. A large swath of software security folks specialize in binary auditing.
      - ikeboy 11y ago
        Has anyone done that and produced a fully open source app to connect to whatsapp?
        ryanlol 11y ago
        Lots of people. https://github.com/tgalal/yowsup https://github.com/tgalal/yowsup for example
        ikeboy 11y ago
        Looks like WhatsApp isn't so happy about that ... https://gigaom.com/2015/01/20/whatsapp-cracks-down-on-people-using-unofficial-clients/ https://gigaom.com/2015/01/20/whatsapp-cracks-down-on-people... Do you know if the clients work with the new encryption?
        ryanlol 11y ago
        Yes, axolotl is open source. (However I can't comment on how much it's been modified for the official client)
tremon 11y ago
Even if I were to accept your logic, what's ridiculous about that?
- ryanlol 11y ago
  Open sourcing the crypto code wouldn't be ridiculous, but pointless. What I find ridiculous though was >venders that don't agree to an audit should be considered insecure The same thing applies to every single part of the application, but not equally. No attacker is going to start out by trying to break the crypto, unless it's obviously broken. "Normal" bugs are far more common and often more dangerous (Thing RCE, or in the case of many modern apps: XSS)
  - CiPHPerCoder 11y ago
    > No attacker is going to start out by trying to break the crypto, unless it's obviously broken. Emphasis mine. I agree with ryanlol here. Why bother with active attacks when you can just steal their private key from a code execution? Similar to this, but with the priority flipped: https://www.bishopfox.com/blog/2016/04/if-you-cant-break-crypto-break-the-client-recovery-of-plaintext-imessage-data/ https://www.bishopfox.com/blog/2016/04/if-you-cant-break-cry...
imaginenore 11y ago
ryanlol is correct though. If you open source just the end-to-end crypto part, it doesn't mean that the there's no backdoor elsewhere - it could easily leak the keys or whole conversations. The second problem is - you don't know if that source is what ended up in the binary. So yeah, unless you can compile the whole thing yourself, it should not be considered secure.
- exo762 11y ago
  Open source client and reproducible builds. Signal already does that. It's not a high bar.
  - ryanlol 11y ago
    That's a completely different from just wanting the e2e crypto source, which is useless by itself. https://www.bishopfox.com/blog/2016/04/if-you-cant-break-crypto-break-the-client-recovery-of-plaintext-imessage-data/ https://www.bishopfox.com/blog/2016/04/if-you-cant-break-cry...
    - nxzero 11y ago
      What to you are steps towards the mass adoption of universal turnkey state-level OPSEC for everyday use? ___ So, my point that the E2E should be open source is that that code should never be the basis for a business model, so to me, it being open source makes sense. As larger system, that's why I'm saying there needs to be an audit. Also, you mentioned ATP and I agree, which is why to me it is troubling Signal instead of guarding metadata, actively collects it. Please let me know I have missed anything you'd like me to address. And I really would be interested in your thought on the question above in as much detail as you're able to share. Thanks!

mtgx 11y ago

Would open sourcing the Whatsapp client hurt Whatsapp in any significant way? I mean, sure, there could be "Whatsapp clones" (aren't there already?!), but wouldn't Whatsapp still benefit from the phone number user base it has, thus maintaining a certain lock-in on its users from which it already benefits?

andrey_utkin 11y ago
> I mean, sure, there could be "Whatsapp clones" (aren't there already?!) Sounds funny if you consider that Whatsapp itself is just a branded deployment of FOSS XMPP server Ejabberd, with feature of federation taken away. Plus a client app implementation, of course.
- jeena 11y ago
  That is only possible because Ejabberd doesn't use the AGPL license.
  - goodplay 11y ago
    Come on, it would definitely still be possible with AGPL code. What brought people to whatsapp is its ubiquity and the fact that it just works, and what keeps them from going elsewhere is the inevitable network effect. Nothing in the AGPL prevents either from occurring.
    - onli 11y ago
      I think you are misunderstanding jeena. If ejabberd were AGPL, then a fork/a instance of it like Whatsapp would be legally obliged to open up their code as well. No idea whether the assumption is true that Whatsapp is just a branded deployment.
      - goodplay 11y ago
        I still don't understand how opening up the codebase would prevent them from being successful. As the countless messaging apps out there demonstrate, the value of communication apps lies in the network they build. If they provide a decent UX, and successfully bootstrap a network large enough, it wont matter if their code is open.

mikeokner 11y ago

> Also, message metadata is still being leaked by all of these E2E implementations and needs to be fixed. Ricochet (https://ricochet.im/ https://ricochet.im/) solves that problem using Tor hidden services. Desktop only at the moment AFAIK, though.

nxzero 11y ago
Are there any stats posted on the size of the network? (either from Tor or P2P network analysis)
vox_mollis 11y ago
One great benefit to ricochet is that you can choose to exclude those with whom you are communicating from your COMSEC threat model, due to the lack of (mostly connection) metadata availability.
- nxzero 11y ago
  Sounds interesting. Appears to have a lot of docs/code, are you able to link to the related code & docs?

tptacek 11y ago

WhatsApp's "E2E" code is from Signal, which is open source. This zealous belief that all secure cryptography must be open source is something I hear a lot from open source advocates, but not so much from cryptography engineers.

arbsn 11y ago
Is the encryption/decryption code in WhatsApp open-source? I haven't been able to find it. My assumption was that they conform to the Signal encryption protocol, which is openly specified, but that the code they use to do so is not open-source.
- moxie 11y ago
  Yes, it is. It's linked directly from the paper (https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf https://www.whatsapp.com/security/WhatsApp-Security-Whitepap...) that documents their use of the protocol. It's the exact same code we use in Signal: https://github.com/whispersystems/libsignal-protocol-java https://github.com/whispersystems/libsignal-protocol-java
AJ007 11y ago
The value is not just the public display of the source code for auditing, but the validation that what you are running was indeed compiled from that code.
- russell_h 11y ago
  Simply open sourcing the code doesn't give that validation.
  - AckSyn 11y ago
    Not completely but I can certainly look at it, compile, and then side-load it onto my device knowing it's what it said it was.
- brianacton 11y ago

moxie 11y ago

> which declined to allow their E2E code to be audited. Could you cite this? The Signal Protocol implementations they're using are both open source and well audited.