Hacker News Reader

Comment by ddevault | Hacker News Reader

All software related to security should be open source. This particular piece of software doesn't sit at a crucial point in a secure system, but a greater deal of transparency would be appreciated. I personally avoid using closed-source tools for security purposes, and especially closed-source tools that are hoping to monetize. I use Linux, though, so I guess it doesn't really matter to me in this case :)

I would also say that calling home is a huge no-no for this software. I would seriously consider revisiting that choice if I were you.

View on HN

> All software related to security should be open source.

That's a very common and dangerous misbelief.

Security products should come from a trustworthy source. Open source doesn't imply trustworthiness. If I were to screw you, I can very well do it with an open source product and pre-compiled binaries. Some people will rebuild from source, but a vast majority will use binaries provided assuming that since I'm all "open source" then I must be trustworthy. Hell of an assumption to make if I am not.

I'd argue that both criteria needs to be met :)

> If I were to screw you, I can very well do it with an open source product and pre-compiled binaries.

This is even easier to do to closed-source products, and if you're worried about security than compiling your own binaries is a pretty basic measure.

It is not just that open source software is inherently more trustworthy than closed source software.

1. It is more resistant to backdoor attacks (related to trustworthiness) and more effectively hardened. Fundamental to security is transparency. You cannot secure something if you cannot understand its attack surface; insecure undocumented features (ie the recent iPhone discoveries[1]) and binaries accidentally (or "accidentally") compiled with debug flags are only detectable if the source is available.

2. It is often more nimble and can respond to new threats which closed-source projects ignore. At my work, we were hit by as USB virus that McCaffe ignored despite our very premium support plan because it didn't exist anywhere else. This was before my time, but from my understanding it was a custom-tailored attack that was made in a virus creator -- a drag-and-drop not-so-advanced persistent threat. (Probably a prank or experiment; I work at a school.) If we used open source software, and the community shrugged at us, we could at least make our own signature. At it was, we had to bring the computers down one at a time, boot them into Linux, and run a script to delete the files and registry keys. This is the job antivirus software is meant to automate. I understand virus companies have a heavy workload, but what exactly were we paying for? With open source, you always get your monies worth. (For the software at least; open source support plans can still suck.)

3. Appsec is expensive, its not always something you can afford to pay for. If you aren't designing with security in mind from the start, its not just a feature you can build into your app. It will require pentests and likely a partial rewrite. On an open source project, theres a good chance someone will volunteer to close at least the widest holes. No one volunteers for closed source.

4. This is likely not a part of your threat model, but its harder to serve an open source project with a national security letter.

[1] http://www.theguardian.com/technology/2014/jul/23/iphone-bac...

most people do that but developers contribute to that will see it eventually.

It's not just about screwing intentionally. Open source also helps with getting more eyes on the code. You need to be able to catch vulnerabilities before the bad guys or no amount of good reputation would survive. That is the primary reason for security software to be open source - reducing security by obfuscation and easy vulnerability check.

That said, all software is written and audited by a group of individuals. Ultimately it all comes down to trusting them. Even audits on open source software is done by a few individuals, so when using any open source security software, you are only really trusting them. Any sense of security more than that is a smokescreen. In that regard, I agree with you. Open source does not help with reducing risk of bad intention. That is a myth.

That argument is often repeated and also that often falsified, that Open Source is better because there are more people who have an eye on it.

I just want to mention: — The famous Debian-Bug, which lead to easily guessable "random" numbers. Nobody reviewed that code change for years. — SSL Heartbleed. Nobody reviewed the code change by that guy. Not even the maintainer reviewed it.

So the problem with Open Source is, as I see it, that everybody - from those who are experienced - thinks, that someone else has done the review. Which leads to the situation, that at the end of the day nobody does a review.

It's a problem with the people who make that assumption. Not everyone does.

Just because you have examples of code that wasn't reviewed properly doesn't mean it applies to all open source software. I personally have my eyes on open source quite often, and I know many others who do. I also know we wouldn't have our eyes on it if it weren't for the source.

Really, software being open source doesn't make it secure. It's just a precondition that allows us to find out if it is secure (and fix it when it isn't). If it isn't open source, then we should assume the worst, as we likely have no other way of knowing whether it's reasonably secure.

> SSL Heartbleed. Nobody reviewed the code change by that guy. Not even the maintainer reviewed it.

I think this is a blatant counterexample actually.

The code _was_ reviewed. It passed the review. This just shows that security is hard and that reviews don't always catch everything.

But the only reason that heartbleed ever came to light was that OpenSSL is open source. Had it not been, such a bug would have been much much more difficult to find. Yes, this is not instant, yes, it takes time and leaves people vulnerable in that time, but it did work out in the end.

If a similar bug were to exist in proprietary software, there's a good chance it would never come to light at all. Save for the extremely dedicated intelligence agencies who may have the people and desire to exert the effort to find it. That's who proprietary security software helps.

The Debian bug isn't a terrible example, but it simply shows that distro-specific patches aren't well reviewed, not projects in general. Most people who want to see OpenSSL code go to OpenSSL, not Debian.

Bugs happen, reviewers miss things or may not look in the right places. Open source does not mean secure by any means, it simply removes some requirements of trust of a sole entity and eases reviews.

So if it wasn't open source, how would you go about discovering Heartbleed? It was discovered independently by multiple people beacause it was open source - so contrary to your naive assumption, people are looking at these things.

Here is a story how it happened and how it was patched - http://en.wikipedia.org/wiki/Heartbleed#Discovery

Are you really arguing that discovering and fixing Heartbleed would be simpler and faster in a closed source form?

heartbleed wasn't discovered by browsing the source code, it was found using a fuzzer. it wouldnt have mattered if it was open or closed source.

As a (unworthy, since I happen to use proprietary software accidentally) believer in Free Software, I tend to agree, but since that's unlikely to happen, I'd say all security-related software should be at least fully auditable by end-user. That is, there must be either 1) some form of human-readable (i.e. unobfuscated) source code and means to validate the built binaries to match the provided sources or 2) means to easily decompile the binaries to a human-readable high-level language and study their behavior.

That is, one of the first things this GlassWire app did is connection to its home server. It openly admitted that itself, but nonetheless, why it did so and what kind of data (~200+ KiB, that's a fair amount that probably exceeds any analytic and update-checking needs) were transferred — I have no idea and I'm too lazy to figure out.

Thanks for your feedback. We'll try to add more transparency. The calling home is for software updates and it shows up on the graph, and GlassWire can even block itself.

That may be the case, but it's still not acceptable in my opinion. Calling home to fetch a new database of malicious hosts and such is fine, but calling home for analytics is not okay. At the very least, clearly disclose it and make it easy to opt out.

Out of curiosity, do you have any security concerns about calling home for analytic or is it just you would prefer the privacy of not having your usage tracked?

It's mostly privacy concerns, but also the fact that you use this software at all can disclose some interesting information to eavesdropping attackers. Most worrisome is just that it's not very well disclosed - most users just don't know it's happening, and it's not very well justified.

How can you say "most users don't know it's happening" when it's the first thing you see in the graph when you load the application?

We got your initial point..

I think you're just grinding metal at this point.. Ease down.. ease down...

I don't see anywhere that it discloses what is being sent, just that it's sending something. Did I miss something?

If it's opt-in, I enable it. If it's opt-out, I disable it.

For me it's a matter of principle. That people politely ask is both an indication of trustworthiness and how I prefer things to be, so I try to help by enabling it.

It also depends on the way they ask. Mozilla Firefox for Android tells me that I should choose what I share, enabling crash reports and disabling telemetry by default. Even though the crash report is technically opt-out, they ask me in clear terms. I like that.

> but calling home for analytics is not okay

It's like you didn't even read what was written.

Update channels are very hard to secure and is a huge opportunity to take ownership of the software (and from it, the machine).

For an example, check out the Defcon 22 talk Hack All the Things[1], page ~61. NTV200-100NAS owned through unsigned updates....

[1] http://download.gtvhacker.com/file/generic/GTVHacker-DEFCON2...

Thank you. We will check it out in detail.

Another simple fix: tell us who you are. The contact page is woefully generic and anonymous. Glasswire appears to be a company, more than one person. Where are you based? What's your background? Funding?

> All software related to security should be open source

Why just security-related software? It doesn't get special permissions or anything. All software can do equal damage on most operating systems.

> I personally avoid using closed-source tools for security purposes

I too prefer open source tools for security purposes, but that means that for security purposes I prefer all my software to be open source.

In a perfect world, all software would be open source. Our world isn't perfect so I just live with asking people to make their security-related software open source.

Sounds like Debian is perfect world then :)

I must confess to using a few blobs for drivers, software that school wants me to run (for UML designing) and the occasional game. But overall, I'm pretty clean of closed source software.

How do you know software isn't security related if you can't see its source? They might tell you it isn't :)

I think you are conflating security advice with business advice. Obviously, you are not the target audience. I may agree with you on a technical level but on a business one I do not really agree.

>> All software should be free

Fixed that for you, yours RMS ;-)

Reply on news.ycombinator.com