Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

There is no WhatsApp 'backdoor'

whispersystems.org

Post reply on HN
Print view View original

391–400 of 437 posts

Re: There is no WhatsApp 'backdoor'

#391

Post by lisper »

tptacek wrote: post #385
lisper wrote: post #382

Earlier quoted context omitted.

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, rega…

OK, I concede the point.

Let me try to advance a different thesis then: it is possible to write software in such a manner that the source code is amenable to methods of analysis that the object code is not. Accordingly, for software written in such manners, it is possible to provide certain guarantees if the source code is available for analysis, and those guarantees cannot be provided if the source code is not available. Would you agree with that?

Re: There is no WhatsApp 'backdoor'

#392

Post by meowface »

hsivonen wrote: post #288
meowface wrote: post #285

Earlier quoted context omitted.

Assuming this is a laptop they assigned to you, what's wrong with any of that?

If you are in Europe (or at least some countries in Europe), it's illegal to read in-transit messages even if the recipient is at work and the interceptor is their employer.

I'd hate to work security at a European company...

Re: There is no WhatsApp 'backdoor'

#393

Post by tptacek »

lisper wrote: post #391
tptacek wrote: post #385

Earlier quoted context omitted.

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, rega…

OK, I concede the point. Let me try to advance a different thesis then: it is possible to write software in such a manner that the source code is amenable to methods of analysis that the object code is not. Accordingly, for software written in such manners, it is possible to provide certain guarantees if the source code is available for analysis, and those guarantees cannot be provided if the source code is not avail…

I think it's possible that that's true, but am uncertain: the claim depends on formal methods for software construction that defy decompilation. But the higher-level the tools used for building software, the more effective decompilation tends to be. I also don't think we're even close to the apex of what decompilation (even of the clumsy, lossy compiled languages we have today) will be able to do.

So, it's an interesting question, and one I have much less of a strong opinion on.

If you can't tell, my real issue here is the idea that closed-source software is somehow unknowable. I know you're not claiming that it is. But I think if you look over these threads, you'll see that they tend to begin with people who do believe that, or claim to.

Re: There is no WhatsApp 'backdoor'

#394

Post by gsylvie »

meowface wrote: post #285
gsylvie wrote: post #269

Earlier quoted context omitted.

At one of my jobs the network team uses a thing called "Forcepoint's TLS inspection" (aka Websense) (aka Raytheon). My browser happily let's that network team MITM me all day long without a peep, and logs & archives all my TLS traffic for who knows how long. The funny thing is a VM I setup from my same laptop tried to make an https:// connection and the browser outright refused, without any possible workaround until…

Assuming this is a laptop they assigned to you, what's wrong with any of that?

Less than 2% of the total staff probably realize that all their https traffic is being intercepted. I find it odd that we try to teach everyone the difference between http and https, and then we do this.

Re: There is no WhatsApp 'backdoor'

#395

Post by smartbit »

ncallaway wrote: post #271
smartbit wrote: post #261

Earlier quoted context omitted.

why? The UI on the receiver end could show the warning, not the message, and in the dialog to the Whatsapp systems behave normally. In that way the user would be notified of rekeying, the MITM attacker wouldn't be notified that the user is security consious.

t0: Client A sends message (1) to Server for Client B t1: Server sends message (1) to Client B t2: Client B fails to decode message (1) due to an outdated key. Sends failure notification to Server t3: Server sends rekey notification to Client A t4: (usually 1 second) Client A sends rekeyed message (1') to Server for Client B For t4, if the Server notices the response from Client A came faster than a user could ever h…

Thanks for the extensive answer, indeed if the receiver need to react than this is discoverable.

I was more thinking along the lines of discharging rekeyed messages and not showing the message at all to security conscious receivers. Whether this is behavior is good, I can not say, UX tests could give more insights.

Re: There is no WhatsApp 'backdoor'

#396

Post by stouset »

xg15 wrote: post #311
moxie wrote: post #237

Earlier quoted context omitted.

> That defense, which happens to be the only defense, is turned off by default in WhatsApp. > You seem to argue they do so because it's bad UX to present such notification by default. That's - in my humble opinion - like suggesting browsers should turn off TLS chain errors by default because it's bad UX and just proceed with the connection as if nothing happened... One thing we've learned over the years is that secur…

Why not phase the message differently, e.g. "It looks like (user) is chatting from a new device. Is this correct?" Warning about unusual account activity seem to be very common these days, so why not using them here. The way the warnings are presented as part of the chat history (a very good idea) also means they could be used after-the-fact to figure out when an account was overtaken, even if the warning was initial…

> Why not phase the message differently, e.g. "It looks like (user) is chatting from a new device. Is this correct?"

Because of exactly what Moxie said in his post. This is a relatively common occurrence in practice. Someone gets a new device. Or uninstalls/reinstalls the WhatsApp app. Or wants to read messages on their laptop, too. And so on.

Warning everyone about this all the time leads to people becoming subconsciously blind to these notifications — even to people who should care about them. The solution taken by WhatsApp is a great compromise in this situation. Not everyone will have it on, but the odds are in favor that someone they might want to intercept messages for will. And if they can't know who has the notifications enabled and who doesn't, they run the risk of tipping their hand that they're doing it at all.

Re: There is no WhatsApp 'backdoor'

#397

Post by FabHK »

Response by the finder of the vulnerability:

As Eike Kühl pretty well describes, this functionality only increases usability in a rare corner case: When you dump your phone in the ocean and you need a month to get a new one. Then everyone who has sent you a message during this period will not need to press an additional "OK" button.

https://tobi.rocks/2017/01/what-is-facebook-going-to-do-a-su...

Re: There is no WhatsApp 'backdoor'

#398

Post by smartbit »

akvadrako wrote: post #330
taneq wrote: post #242

Earlier quoted context omitted.

Why are unsigned key changes a 'normal' thing? It'd be trivial to sign the new public key with the old private key, maintaining a chain of trust.

That is basically how 2FA works with Apple devices. You use an old device to approve new ones. Sure, if you lose your cloud account, laptop and phone all at once you'll need to start from scratch. But under normal circumstances it reduces the amount of blind trust.

Interesting answer, makes sense. Whether a similar scheme would work across platforms is another question. Thanks.

Re: There is no WhatsApp 'backdoor'

#400

Post by FabHK »

lisper wrote: post #384
tptacek wrote: post #381

Earlier quoted context omitted.

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.)

All agree that higher level (e.g. C) is easier to reason about than lower level (assembly).

Now, you say that open source (e.g. C) is not only easier, but qualitatively different: open source good, closed source bad.

tptacek points out: higher level (e.g. Haskell) is easier to reason about than lower level (e.g. C) - maybe even qualitatively.

So, why are people only complaining about closed source, when they should (by analogous reasoning) be complaining about code written in C? Granted, it's possible to analyse, but it's obviously easier when it's written in Haskell!

Post reply on HN