Live data from Hacker News

There is no WhatsApp 'backdoor'

whispersystems.org

381–390 of 437 posts

Re: There is no WhatsApp 'backdoor'

#381
post #378

Earlier quoted context omitted.

How do you look at the last 15 years worth of Microsoft Windows OS advisories and conclude that closed source has prevented hats of all colors from discovering vulnerabilities?

Why do you keep raising this straw man? It is obviously possible to reverse engineer object code and find vulnerabilities. But it is (equally obviously) easier to examine source code to find vulnerabilities.

This slippery slope goes in both directions. Software is also easier to audit when it's built in higher-level languages, but we don't have ideological objections about verifiability to software written in C.

Re: There is no WhatsApp 'backdoor'

#382
post #370

Earlier quoted context omitted.

> Open vs. closed source is an orthogonal concern to verifiability. The evidence you have presented does not support this conclusion. All you've shown is that it is possible to reverse-engineer object code, but this was never in doubt. It is still an open possibility (indeed it is overwhelmingly probable) that it is a hell of a lot easier to audit code if you have access to the source. All else being equal, more info…

I'm sorry, but once again: this thread began with a different claim. I'm not interested in debating whether it's easier to audit C code or assembly code: I've repeatedly acknowledged that it is.

Then what exactly are we arguing about? My original claim was:

"You can demonstrate the presence of a vulnerability in closed source software but there's no way to demonstrate (or even provide evidence of) the absence of any vulnerabilities." [Emphasis added] (Also please note that I very deliberately did not use the word "prove".)

Your response was:

"That's identically true of open-source software."

If you acknowledge that it is easier to audit source code then it cannot be the case that anything is "identically true" of open and closed source software (except for uninteresting things like that they are both subject to the halting problem). If it is easier to audit source code (and you just conceded that it is) then it is easier to find vulnerabilities, and so it is more likely that vulnerabilities will be found, and so (for example) the failure of an audit conducted by a competent and honest agent to find vulnerabilities is in fact evidence (not proof) of the absence of vulnerabilities.

But if you have source code written in a language designed to admit formal proofs then it is actually possible to demonstrate the absence of certain classes of vulnerabilities. For example, code written in Rust can be demonstrated (maybe even proven) to not be subject to buffer overflow attacks.

Re: There is no WhatsApp 'backdoor'

#383

Earlier quoted context omitted.

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 chec…

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…

> once you see a warning, you could just delete all messages that don't have the double checkmark

No, as it stands, they are automatically (without user intervention) re-encrypted and re-sent.

Re: There is no WhatsApp 'backdoor'

#384
post #378

Earlier quoted context omitted.

Why do you keep raising this straw man? It is obviously possible to reverse engineer object code and find vulnerabilities. But it is (equally obviously) easier to examine source code to find vulnerabilities.

This slippery slope goes in both directions. Software is also easier to audit when it's built in higher-level languages, but we don't have ideological objections about verifiability to software written in C.

I'm not sure I understand what you mean by that. Do you mean that people think that it doesn't matter what language code is written in as long as it is open source? I certainly don't believe that. It's pretty clear to me that C is a terrible language for writing secure code. (But coming up with something that is actually better than C is not so easy.)

Re: There is no WhatsApp 'backdoor'

#385
post #382

Earlier quoted context omitted.

I'm sorry, but once again: this thread began with a different claim. I'm not interested in debating whether it's easier to audit C code or assembly code: I've repeatedly acknowledged that it is.

Then what exactly are we arguing about? My original claim was: "You can demonstrate the presence of a vulnerability in closed source software but there's no way to demonstrate (or even provide evidence of ) the absence of any vulnerabilities." [Emphasis added] (Also please note that I very deliberately did not use the word "prove".) Your response was: "That's identically true of open-source software." If you acknowle…

Look at the original claim you made. You said it's possible to provide evidence of the existence of vulnerabilities in closed source software, but not of their absence. To the extent that's true, it's true of open source software as well. The dichotomy you presented, about absence of evidence vs. evidence of absence, is not about open source software but about all software built without formal methods --- which, regardless of the language used, is almost all software.

The point you made is orthogonal to the question of whether we can understand and evaluate ("verify") closed-source software.

Re: There is no WhatsApp 'backdoor'

#386
post #57

I take this blog post as confirmation that: 1) ANY one message can be intercepted even if the sender exhibits ideal levels of alertness [Whatsapp server drops message to recipient; sends a rekey request with a fake key; message is intercepted since fake key was generated by server. Sender will see a warning if they turned on that setting (default is to show no warning), but it's too late]. 2) Only Whatsapp has this v…

Best summary I've seen. There are two significant facts here that surprised me: 1. The double checkmark has security implications. How would a typical user know that? 2. Even if you are completely vigilant, follow best practices, etc, Whatsapp messages can be intercepted. They claim this is a "wontfix" UX choice. I'm skeptical why the non-default feature cannot even provide the protection that almost everyone assumed…

> How would a typical user know that?

I think that's basically the main problem: there is no way to get a typical user to understand security implications of anything without having that user give up before reaching that point...

Re: There is no WhatsApp 'backdoor'

#387

Earlier quoted context omitted.

>TLS certificate errors are not something that should happen under normal circumstances. When a TLS certificate fails to validate, something is really wrong. As we've gotten better about ensuring those conditions, browsers have made it harder and harder to get past the warnings, because they're not warnings anymore -- they're error conditions. Not paying Verisign your rent? That's an "error condition". (Here of cours…

> Not paying Verisign your rent? Would have been a fair statement a couple of years ago, but we live in a day when you can get free annual certs manually (Startssl) and free 90 day certs automatically (Letsencrypt).

The StartSSL CA is in the process of being blacklisted by major browser vendors because they issued a certificate for github.com to someone who clearly does not run github.com. [0]

LetsEncrypt just barely left beta (also this summer) and I'll admit that I haven't investigated it thoroughly, but it appears that some widespread devices are still incompatible (also consider the versions that accept LetsEncrypt; some of those are fairly recent, like CM 10). [1]

While some noble souls like LetsEncrypt have sought to remedy this rent-seeking behavior, it remains the fact that in most cases, a traditional CA is going to be required for a couple more years at least.

[0]https://www.schrauger.com/the-story-of-how-wosign-gave-me-an...

[1]https://letsencrypt.org/docs/certificate-compatibility/

Re: There is no WhatsApp 'backdoor'

#388
post #371

Earlier quoted context omitted.

Open vs. closed is obviously orthogonal to verifiability. Those who verify software have access to the source, open or not. More parties have the opportunity to be verifiers of open software. However, a given OSS program might not attract skilled verifiers.

> Those who verify software have access to the source, open or not. That's not true. Black hats are essentially verifiers, and they generally do not have access to closed source.

They are verifiers who cannot, with straight faces, declare a body of code verified.

Re: There is no WhatsApp 'backdoor'

#389
post #371

Earlier quoted context omitted.

> Those who verify software have access to the source, open or not. That's not true. Black hats are essentially verifiers, and they generally do not have access to closed source.

How do you look at the last 15 years worth of Microsoft Windows OS advisories and conclude that closed source has prevented hats of all colors from discovering vulnerabilities?

Here might be something to look for among those advisories: how many of them were discovered in the source versus in the field.

If the vendor is lazy about verifying code, it being closed is a big disadvantage. "We're not combing the code for bugs, and neither is anyone else; if it's not reported to us, it doesn't exist."

Re: There is no WhatsApp 'backdoor'

#390
post #371

Earlier quoted context omitted.

> Those who verify software have access to the source, open or not. That's not true. Black hats are essentially verifiers, and they generally do not have access to closed source.

They are verifiers who cannot, with straight faces, declare a body of code verified.

I'll bet some of them can.
Post reply on HN