Hacker News Reader

A verification of security is always based on an attacker model. There is no general security.

The actual point is not security, but trust and certainty. Being Open Source does not change whether some messaging app is secure or not. It changes our knowledge about the code. It also makes me have a little bit more trust in some company for revealing their stuff.

Even if WhatsApp open-sources the clients, there is still the problem of US jurisdiction. NSA can force them to silently including a backdoor or send everything to NSA-servers.

Trust is a difficult thing.

> But if the code is open source, we _can_ verify it's security?

No - the code could be "open source" but unreadable. But if it's not open-source there's definitely nothing we can do.

> Heartbleed and Shellshock, the two most significant vulnerabilities found in heavily used open source software, were found by vulnerability testing and not code inspection. So while being open source is a nice-to-have attribute for a piece of software, that's as far as it goes

a) afl-fuzz and the like require access to the source code.

b) Those were the vulnerabilities that made it into production. They tell you nothing about what proportion of potential vulnerabilities were stopped by it being open source.

note that Heartbleed was not discovered via fuzzing.

Thanks for the correction regarding ali-fuzz, I wasn't aware of that. Unfortunately I can't update my post to fix that anymore.

I think this doesn't fundamentally change my point though. ali-fuzz was used to find shellshock, but that vulnerability had been in bash for decades. If it had ben found and closed within months of being introduced I'd be cheering the advantages of open source with the best of them, but that's decades during which a bad actor could theoretically have found and exploited that vulnerability with impunity using code analysis. That's exactly what I mean by the balance of advantages versus disadvantages of open source being tipped the wrong way right now.

I'm not enemy of open source, far from it, I'm just arguing for an open and honest assessment of the situation. If open source is really going to be a genuine security advantage, there's an awful lot of work to be done to make it so. It's not going to happen spontaneously.

> I'm not enemy of open source, far from it, I'm just arguing for an open and honest assessment of the situation. If open source is really going to be a genuine security advantage, there's an awful lot of work to be done to make it so. It's not going to happen spontaneously.

I don't think you've shown anything about relative vulnerability rates. I agree that there are massive problems with even major open-source projects, the general state of software security is terrible, and we have a lot of work to do on that front (starting with moving to memory-safe languages post-haste). But none of those things contradicts that open-source software is much more secure than closed-source software.

You haven't yourself empirically established that open source software is more secure, so you should be less smug about the logic you're using here.

In reality, software security is a function of the amount of expert attention that has been paid to a given piece of software. Popular open source software attracts a certain, stochastic, significant amount of attention, but money buys a more reliable amount of attention. There is insecure open source and secure open source, insecure closed source and secure closed source. Open source is a red herring.

There's a reason why, for instance, Firefox had Bleichenbacher's E=3 vulnerability, while IE didn't.

Fuzzers do not require source code. That is absolutely false. Afl-fuzz does, but you badly overplayed your hand by adding "and the like". Fuzzing proprietary closed source protocols by instrumenting closed-source binaries is a bread-and-butter software security project that virtually any application security consultant can do effectively.

And even afl has qemu-mode, although I have no idea how well that works.

there's definitely nothing we can do.

This is very much not true. Understanding what any executable does is possible without the source code. In fact, if you are looking at the binary, you know exactly what you are dealing with, and don't have the doubt about what the build chain actually does with the source.

potential vulnerabilities were stopped by it being open source.

This presumably comes from "many eyes make all bugs shallow". But operationally this is not true, because there isn't really, except for rare circumstances, any useful review.

"The open source community has a long way to go if it's going to clearly demonstrate that it's model is advantageous"

How is it less safe than not having the source, though? Absent the source, how can you trust that the once trustworthy, if secret, code hasn't been nobbled via hackers, a court order etc.

The model of security through obscurity is what's broken, and that's what we've got here. You have to trust Facebook today, and forever and trust anyone else with the technical or legal power to silently violate its security; something that's much harder if the code is available for analysis.

It's not less safe to have the source code. Source code is a good thing. All things being equal, I prefer open source components too. But all things are not equal.

In this case, if you're ideologically attached to open source, you're in luck: the cryptographic components WhatsApp uses are open source, and there's another good messenger that uses them: Signal, by Open Whisper Systems.

The problem with WhatsApp is that IT is not open source, so you only have facebook's say-so that they're using the signal code, and you have to have faith that they've implemented it securely, and you have to trust that, as an american company, the current or future government won't silently compel them to introduce a weakness, such as allowing that when a phone gets the message `sing` it sends an encrypted copy of the last n messages back to facebook. I'd be more comfortable using the compilable, open source signal app, because i at least have the opportunity to see what the code is doing, should i somehow manage to find an sabotaged version of clang, gcc, vs etc.

People need to stop writing this exact comment. Even if you're right about open source and security, you can't be right about it for this reason, because this comment is false.

You are not in fact stuck with Facebook's "say-so" about what WhatsApp is doing. Obviously, if you have the executable binary, you can straightforwardly validate its functionality with a disassembler/decompiler. There are thousands of people that do this professionally.

There might be some other reason why it's important that WhatsApp's code be published, but it can't possibly be this one.

Has anyone actually done this? I lack the skill to but for a piece of software this important, surely someone is working on this? And will it be repeated for every update?

Personally if I was the NSA or GCHQ I think it would be a wicked smart plan to release this and have it be actually secure, have it audited, gain trust, let people use it for a while then after a while release an update that shoved all the messages in memory to a server somewhere once people let their guard down. Implausible yes, but that's the issue with trust. And I'm not sure releasing the clean source would really help this. The only thing would be to hold up on updating the app until a trusted party had audited the updated binary. More paranoia: Also would have to audit the specific binary for every country with wierd laws (e.g. UK's RIPA) appstore to make sure we didn't get a nice local flavour of poison.

If WhatsApp releases the code, how do you know that's the code they run their service on? Open source does _nothing_ with respect to the trust issue with third party services like WhatsApp or Facebook. It's completely orthogonal.

I was wrong about heartbleed, it was found through a source code analysis technique called fuzzing - decades after the vulnerability was introduced. That's decades during which source code analysis could have been used by bad actors to find the same vulnerability and exploit it.

Opening the code doesn't by itself eliminate the vulnerabilities. What it does do is fire the starting pistol on a race between black hats and white hats to find and either exploit or close the vulnerabilities. It's very much a two edged sword. So what we need is confidence that the white hats are winning that race.

"Opening the code doesn't by itself eliminate the vulnerabilities. What it does do is fire the starting pistol on a race between black hats and white hats to find and either exploit or close the vulnerabilities."

The race is more dependent on motivation than whether the code is open or closed. Often, blackhats are financially motivated (whether they themselves monetize the vulnerabilities directly - or they are hired-by/paid-for a 3rd party) - they factor in their return on investment (ROI). Open source merely makes their job easier but given enough motivation, they can and will find vulnerabilities in binaries, remote services, etc almost as easily.

One problem is that many people believe in "many eyes makes all bugs shallow". Numerous examples prove that assumption false. Is it because there is more financial interest in closed systems? ...or is it because in open systems people automatically assume that because it's open that someone else must have vetted it? (e.g. "if I'm interested in it, and thousands/millions are too, then it's highly likely some expert better than me already looked at")

If the source is open you can verify/test both ways, if it isn't then you only have the external testing option.

The code being publicly available does not guarantee security but makes insecurity easier to find which on balance indirectly increases security.

"Rogues are very keen in their profession, and know already much more than we can teach them" said locksmither Alfred Charles Hobbs, who in 1851 demonstrated to the public how state-of-the-art locks could be picked, in response to concerns that exposing security flaws in the design of locks could make them more vulnerable to criminals. This quote is not less true today when applied to blackhats. Open source doesn't mean secure, but security trough obscurity is not a good security model.

>The open source community has a long way to go if it's going to clearly demonstrate that it's model is advantageous

Some in the open source community flout the "many eyes makes all bugs shallow" argument, but in the free software community we do not assert this. Part of security is transparency, and this means being able to read the source code, freedom 1. Free software is a prerequisite for secure software that a user can trust.

I understand and respect the tenets of your religion, but I do not practice that religion myself.

Thanks for being condescending.

If it helps you understand where I'm coming from, while I do in fact admire the FSF's ethic of free software, more so than I admire "open source", as a practitioner in the field of cryptographic security I find FSF-style preaching about security to be intensely condescending as well.

More here:

https://news.ycombinator.com/edit?id=11455588

The linked comment has NOTHING to do with what the FSF has said about software security.

Be civil. Don't say things you wouldn't say in a face-to-face conversation. Avoid gratuitous negativity. - Hacker News Guidelines

If you are opening up for incivility, I doubt there is an end what people will start calling each other. Do you really want to go down that road?

If you want to compare track records of close sources software with open source, we have IE6 and flash. We have windows 98 and XP. We have every snake oil product ever sold that the producer knew wasn't safe but sold anyway. Heartbleed and Shellshock were big bugs, but they did not create the concept of botnets nor was they so successful that they created a market where before there wasn't.

So basically the theory here is that if you look back to software written in the mid-to-late 1990s, you tend to find insecure software.

If you want to be like that, all of them were written mid-to-late 1990 or before it:

Bash was released in 1989 and initially development started some time before that.

OpenSSL project was founded in 1998.

Windows XP was initial developed in the late 1990s, released 2001.

Macromedia Flash 1.0 was released 1996 and initially developed a couple years before.

So should we only count software vulnerabilities that was created after 2010? 2016? What proof would satisfy you?

I'm really not sure what point you're trying to make here, because obviously both Bash and OpenSSL are poster children for the perils of legacy insecure software, and both are still in wide use --- far wider than Windows XP!

Are you confused by the parent argument that Heartbleed and Shellshock is proof that open source has the same likelihood of software vulnerabilities being exploited maliciously as closed software?

Or are you confused by your own argument that software written in the mid-to-late 1990s tend to be insecure software, and thus we should disregard that some software has been more exploited historically than others?

Neither. I think age has a lot to do with whether software is or isn't secure. Software written in the 1990s (or before) is unlikely to be secure. I think open/closed source has very little to do with security. Some open source software is secure, some isn't, and the same goes for closed-source software.

When the source code has a whitelist of usernames for which encryption should be disabled, put there under court order, you'll see the difference between external verification vs source code inspection.

I really think that's what most people arguing against WhatsApp believe: that a backdoor in a secure messaging application would take the form of intelligible source code expressing directly that backdoor.

Obviously, a WhatsApp backdoor would not in fact take that form.

What would it look like?

A binary patch.

Could be a number of things. Some might be visible only during build/packaging as you say, others visible in code.

Why would anyone patch the source code when they can just as easily patch binaries?

"Open source" isn't quite the right term, but it's on the right track.

What you definitely don't need is permission to redistribute, modify, etc. the software. Those are important for user freedom, but for the goal of verifying that a particular app on a walled-garden app store does what it claims to do, those don't help you. You just need access to source code.

What you do need, whether or not you have source, is an understanding of what the software does. Sure, you can probably do this by disassembling the software. But if you can disassemble the software and understand it, there is nothing more that having the actual source would tell you. If the company is expecting that people will disassemble it to verify it, they might as well release source.

What you also need, given either source or a binary, is assurance that everyone else is running the same binary as you have. Given source, that probably requires reproducible builds and a documented and reasonable build chain. Given a binary, that requires some distribution mechanism that ensures that everyone in fact gets the same binary.

> But if the code is open source, we _can_ verify it's security?

But if the code is not open source, we _cannot_ verify it's security?

Ability is already good. Not enough but necessary.

Why do you believe that we _cannot_ verify its security?

I mean closed sources are .. closed sources (did I say something stupid?). Unless you consider black box testings or things I don't know.

The original source code is unavailable. But the assembly code that actually implements the program is not, and there are a variety of techniques reversers use to lift assembly into higher-level representations --- not that you'd need to in this case.

Do you understand the concept of "necessary, but not sufficient"?

Yes I do, but that's not what the post I was responding to was saying. However I have not seen any arguments that convince me if its necessity. Furthermore were talking about third party services. What code they open sourcezsndcegat code they actually run on their servers are two different questions. Open source doesn't solve this problem whichever way you slice it.