netwo233gur
Those "bugs" were found by third party hackers reviewing the code. Heartbleed was found by someone conducting a blackbox pentest. Log4shell was found by someone reviewing the code, and using the exploit before white hats discovered it as a 0-day. This is the exact opposite of championing open source white hats, and is exactly the concern raised by the original author of the statement which created this entire thread.
>However, try to find evidence of issues found by a 3rd party reviewing a closed crypto system .
I can speak from personal experience at a FAANG that this happens literally every day, multiple times a day. Just because you don't hear about it happening because its behind closed doors does not mean it isn't happening.
>There is a literal objective benefit to having an open system
And there is literal objective disadvantage to having an open system, as well. The entire point is that you must weigh the tradeoffs.
>why every engineer worth its salt is nowadays going to consider a closed crypto system as the snake oil it is.
The majority of software you use is using closed crypto systems. Just because the core algorithm used is open source doesn't mean the rest of the implementation is. The security industry does not view this as snake oil. If you think we do, you have a misunderstanding of the security industry.
>This is also missing the point. What is meant here is that a crypto system should not rely on obscurity of its design (rather, the design should be open for cryptonanalysis), not that you have to provide friggin debug- level access to every implementation of the system, even production.
It seems like you're the one that completely missed the point. Relying on third party cryptanalysis for your security goals (especially by unpaid volunteers, or low-paid bounty hunters) is terrible and lazy security, and will almost certainly not get you what you want. The design of a crypto wallet being open is a product decision made because your users want some level of assurance that you aren't secretly stealing their BTC, but it is not a security decision that can be relied on to secure your product from vulnerabilities.
Please, let's continue this back-and-forth of condescension. It's really productive. /s
Yes, need.
>you've just shown two good examples yourself. Bugs found by scrutinising open source software.
Bugs found years after they were introduced, and not found by white hats until after black hats were already exploiting them. This is your example of open source software being secure? These are poor examples, and the exact opposite of what you're arguing for.
>This sentence seems to make the same assumption others have: that "black hats" are exclusively looking at open source software.
It makes no such assumption. You appear to have completely missed the point.
>This might be true of a library noone uses (in which the impact of an exploit is limited by it's popularity). For popular libraries, there's an entire SCA industry of commercial vendors selling products that disprove this
Nope. You again seem to have completely missed the point. Openssl and log4j completely destroy your argument here, as they are two of the most used software packages in history and yet nobody noticed the bugs for years. I don't know how you can champion this as a win for open source security with a straight face. We still do not understand the full extent to which these vulnerabilities were exploited, but we do absolutely know that they were exploited before open source white hat researchers found anything. These were abject failures for open source.
> There's absolutely no comparison between this effort and the number of eyes looking at proprietary products internally in any given org.
You're right that there's no comparison. Right now in my company there are thousands of well-paid engineers whose full-time job is to look for vulnerabilities in our closed-source code bases. The amount of scrutiny that open-source libs get doesn't hold a candle to it.
The security departments of multiple FAANGs, not to mention security experts, completely disagree with you.
>log4j2 was widely disliked and rarely used, IME.
Tell that to the tens of thousands of FAANG engineers who worked all weekend remediating the hundreds of thousands (not exaggeration) instances in their companies where it is in use.
On the contrary, log4j incident is an excellent example of how relying on open source for security completely failed. This vuln existed for years, all while being open to security researchers to find it. They didn't. Instead, there is evidence that black hats found the vuln first (perhaps because log4j is open source?).
Security engineer here. No they aren't. I'd say they are being a much more comprehensive in their security analysis by including the cons in their calculation rather than dismissing them and assuming that the pros outweigh them.
>opinion is shared by most of the security community.
No it isn't.
Security by obscurity is a very valid defense-in-depth measure. There's a reason you disable "debug-level logging" on production webservers.
>There is ample evidence that the cons FAR outweigh the pros in this particular comparison.
Show said evidence, please, because there is ample evidence that open source software magically being reviewed by hordes of people is many times a myth.
Heartbleed was caused because pretty much nobody cared to look at openssl's code and review it for vulnerabilities. Just because it is available to be looked at by white hats doesn't mean anyone actually is looking at it. And if something so critical to security like openssl isn't even being reviewed by security researchers, what gives you any confidence that random software like JoesCoolLoggingLibrary is reviewed with any more scrutiny?
Speaking of logging, Log4shell is yet another example. The most ubiquitous libraries in use. Used everywhere by some of the largest tech companies in the world, that all have the largest and most well-budgeted security organizations. The vulnerability was present in code for years, available for anyone in the world to look at, and yet...? Instead, there is evidence that Log4shell was being exploited by black hats before any white hats discovered it.
>You're arguing that 99 white hats don't trump black-vs-white.
No, they're arguing that there is no guarantee that these 99 white hats are somehow better than the 1000 black hats, and I'd add to it that there is also no guarantee that these 99 white hats magically appear, anyway. In fact, I think a more realistic visualization for most software is:
- Closed source:
-- Pros: 1 well paid white hat can easily inspect the source
-- Cons: 1000 hackers can blackbox-attack the application
- Open source:
-- Pros: 1-2 unpaid volunteer white hats might inspect the source if they have time
-- Cons: 1000 black hats can whitebox-attack the application
As a security engineer, I know which one I feel more comfortable with.
I've seen some of the inner workings of the big cloud providers' networking stacks. The networking infrastructure, the software that runs it, the software that exposes it to customers, the thousands of engineers working at any given moment in AWS/GCP/Azure's NOCs to maintain uptime are truly some of the most impressive technical marvels I have ever seen. They aren't as sexy to discuss on HN as something like the managed containers services, functions as a service, EC2 etc, but the networking stacks like the VPC, NAT gateways, subnet routing, privatelinks, security groups, ENIs, nitro cards, etc are pure magic as far as I'm concerned and are so so so much more complicated than a standard data center's networking stack, or even Cloudflare's stack.
To use Cloudflare's "bucket of water" metaphor, AWS isn't even close to just being a dumb bucket of water that you fill with water and then get charged to take out the water. There is so much that happens inside of that bucket to segment your water into different pipes, routing your water in all kinds of customer-customizable ways for many different use cases, mixing/heating/cooling your water as you need, all while guaranteeing things like making sure your water arrives exactly where it is supposed to arrive and doesn't get contaminated or leaked along the way.
Does AWS make a big markup on bandwidth? Yea, surely they do. But is it as simple as Cloudflare says it is? Not even close.