After the heartbleed bug I checked out the openssl code to see what the quality was like. I was horrified from what I saw; single character variable names outside of loops, preprocessor macro soup, no comments for functions. I've told interns off for less.
Given the reliance on openssl I really hope companies that are using it are doing robust automated checking on the codebase.
It's one of the most heavily audited codebases on the planet. Nobody likes the code quality, and Google has been restructuring it and rewriting it with their BoringSSL project.
At this point: when new bug classes are discovered, like carry propagation in optimized multiplication routines, or even simpler stuff like memory corruption due to bignum copies, yes, there's some cause for alarm, because you might not be able to count on OpenSSL having been audited for them.
But the basic stuff, at least in the core functionality (ie: not oddball TLS extensions) has received a very good shake.
> It's one of the most heavily audited codebases on the planet.
This is misleading. OpenSSL is probably one of the most heavily audited in terms of number of auditors currently working on it, but this only started with Heartbleed and there appears to be a large, unfinished backlog of things to get through.
Looking at https://www.openssl.org/news/vulnerabilities.html#y2015 , since Heartbleed 20 months have passed, and new security vulnerabilities have been announced on 14 separate dates (and most of those dates are multiple vulnerabilities being announced at the same time). This announcement breaks the streak of most consecutive months without a new vulnerability, of which there were almost five.
Okay, I may've been wrong about exactly when the auditing started, but do we agree that the number of security vulnerability announcements in the past year is somewhat predictive of the number of announcements coming in the next? For me the main worry is attacks from people who aren't doing their own research but just exploiting the window between the public announcement and when I get the patches installed, and I really wish there were fewer such windows.
Do you believe Google is or isn't a US company which would keep the most interesting stuff to itself/NSA/US-TLA's?
Having Google audit the OpenSSL code is not really a problem... but believing them to do things for the benefit of anyone else isn't really feasible. They've shown themselves to be both good and bad actors on multiple occasions, so trying to pick which one this is... guesswork. :(
> Do you believe Google is or isn't a US company which would keep the most interesting stuff to itself/NSA/US-TLA's?
They are a US-based company.
They absolutely would fix and/or publicly announce any vuln in a library that they rely on, rather than keep quiet about it or -far worse- sell the vuln information.
Do you have a credible example of an instance where they've acted to the contrary?
Hmm, no one has found out that they didn't tell us things. Clearly, that's proof that they tell us everything. Good thing we got our answer. Time to stop asking questions. Google tells us every time they find a serious vulnerability in OpenSSL, so no need to worry that they might not.
Absolutely not. Vigilance often keeps allies who might turn on you from turning on you, and -when it fails to do that- it alerts you to their treachery. This is why I asked for evidence of Google's treachery, rather than dismissing the possibility.
In any significant conflict it is very wise to have an idea of who your stalwart allies are, and who you are able to currently rely on.
Any ally can turn on you at any time. That's human nature. However, the man who allows himself no allies is far weaker and far more susceptible to attack than the man who has some.
Like any ally, Google may one day turn on us. For the past several decades, examination of the reports from people working in a variety of positions inside the organization leads us to understand that -despite the fact that Google is a huge advertising company- it realizes that insecure computers and computer systems hurt them at least as much as they hurt everyone else. Those reports also lead us to understand that Google works really hard to ensure that the software that it relies on and the software that it produces is as secure as it can be reasonably made, given the resources Google has available.
If this confuses you, think of it this way: Google makes money by keeping the data that it collects on you (and the analysis of that data) secure and out of the hands of everyone outside of Google. Because they use commodity hardware and software in the regular course of their business, they find themselves testing and fixing issues in software and -sometimes- hardware that we all use.
Because there is no competitive advantage for them to withhold those fixes (indeed, doing so makes everyone safer and keeps them using their computers, which keeps delicious data flowing into Google's robots), Google publishes these fixes on a regular basis.
Given the reliance on openssl I really hope companies that are using it are doing robust automated checking on the codebase.