Slashdot Mirror
OpenSSL: the New Face of Technology Monoculture
chicksdaddy writes: "In a now-famous 2003 essay, 'Cyberinsecurity: The Cost of Monopoly,' Dr. Dan Geer argued, persuasively, that Microsoft's operating system monopoly constituted a grave risk to the security of the United States and international security, as well. It was in the interest of the U.S. government and others to break Redmond's monopoly, or at least to lessen Microsoft's ability to 'lock in' customers and limit choice. The essay cost Geer his job at the security consulting firm AtStake, which then counted Microsoft as a major customer. These days Geer is the Chief Security Officer at In-Q-Tel, the CIA's venture capital arm. But he's no less vigilant of the dangers of software monocultures. In a post at the Lawfare blog, Geer is again warning about the dangers that come from an over-reliance on common platforms and code. His concern this time isn't proprietary software managed by Redmond, however, it's common, oft-reused hardware and software packages like the OpenSSL software at the heart (pun intended) of Heartbleed. 'The critical infrastructure's monoculture question was once centered on Microsoft Windows,' he writes. 'No more. The critical infrastructure's monoculture problem, and hence its exposure to common mode risk, is now small devices and the chips which run them.'"
We already established that often corporations will use free software because of the cost, not because they're enthusiasts, and often those that are enthusiasts for a given project are specifically interested in that project only, not in other projects that support that project.
Besides, it's disingenuous to claim that no one knew that there were potential problems, the OpenBSD people were not exactly quiet about their complaints about OpenSSL. Of course, rather than considering their complaints on their merits, they were ignored until it blew wide open.
Do not look into laser with remaining eye.
In theory (the way OSS evangelists tell you) as a software package gets more popular, it gets reviewed by more and more people of greater and greater competency. The number of people using OSS packages has exploded in the past 10 years, but the number of people writing and reviewing the code involved doesn't seem to have changed much.
With open-source software, a monoculture isn't that bad a thing, as the Heartbleed exploit has shown. When something bad is discovered, people jump on it immediately and come up with a fix, which is deployed very very quickly (and free of charge, I might add). How fast was a fix available for Heartbleed? Further, people will go to greater lengths to make sure it doesn't happen again. Look at the recent efforts to rewrite OpenSSL, and the fork that was created from it.
None of this happens with proprietary software. First off, the vendor always tries to deny the problem or cover it up. If and when they do fix it, it may or may not be really fixed. You don't know, because it's all closed-source. It might be a half-ass fix, or it might have a different backdoor inserted, as was recently revealed with Netgear. What if you think the fix is poor? Can you fork it and make your own that's better? No, because you can't fork closed-source software (and certainly not selected libraries inside a larger closed-source software package; they're monolithic). But the LibreSSL guys did just that in the Heartbleed case.
Finally, monocultures aren't all that common in open-source software anyway; they only happen when everyone generally agrees on something and/or likes something well enough to not bother with forks or alternatives. Even the vaunted Linux kernel isn't a monoculture, as there's still lots of people using the *BSD kernels/OSes (though granted, there's far more installations of the Linux kernel than the *BSDs).
I have been a bit surprised that all these companies using OpenSSL (Google, Yahoo, Facebook, etc) haven't ensured that this critical piece of technology is getting the support it needs to be done correctly.
What other technology that is critical are these same/dependent companies overlooking in their investment of dollars in Open Source software??
Will be interesting to see what happens going forward.
But the rest of us do!
It's a silly argument. Put your eggs in one basket... then guard the basket. 2-3 FT developers doesn't cut it when there are so many attackers and the motivation is much greater than bragging rights at def con.
I am not anti-volunteer; I spend a lot of my time volunteering.
But you need strong leadership.
Otherwise, everyone does what they want to, which leaves huge holes in the project.
Whether a piece of code is open source or closed source doesn't matter. The quality of the leadership of the team that produces it is vital in both cases.
Futurist Traditionalism
I'm not sure it's a valid argument. The probability of errors that may be found in a given system is proportional to the complexity of that system. Likewise the cost to maintain and evolve a system is proportionally tied to its complexity. It is therefore a worthy to goal to reduce system complexity whenever possible. If network communication infrastructure is taken to be the system, then it naturally follows that the fewer implementations that exist for performing SSL/TLS communication the less likely there will exist security vulnerabilities. Relatedly the cost to identify and correct vulnerabilities will be proportionally smaller. Said simply, it's much easier to guard one door than it is to guard many.
Suggesting that a "monoculture" is bad relies upon the same faulty premises of "security through obscurity." The failure with respect to OpenSSL and Heartbleed wasn't the monoculture. It was the lack of altruistic eyes scrutinizing it. More implementations would have only required more eyes.
Two of my imaginary friends reproduced once
With respect to the discovery of heartbleed closed and open are equivalent. The bug was found by testing the binary not by eyes on source code.
That said, proprietary code can be open too. Some proprietary libraries are available with a source license option. You may have to ask, their ads don't necessary mention the source license option. It confuses some readers.
A large part of the low impact was older versions of OpenSSL from before the bug was introduced in the "stable" distributions of some widely used Linux distros.
I guess you're not a programmer, and therefore don't know what a shallow bug is. Conveniently, the rest of the sentence you alluded to explains the term:
"Given enough eyeballs, all bugs are shallow ... the fix will be obvious to someone."
If you have to dig deep into the code to figure out what's causing the problem and how to fix it, that's a deep bug. A bug that doesn't require digging is shallow. Heartbleed was fixed in minutes or hours after the symptom was noticed - a very shallow bug indeed. "The fix will be obvious to someone."
The presence or absence of bugs is an orthogonal question. That's closely correlated with the code review and testing process - how many people have to examine and sign off on the code before it's committed, and if there is a full suite of automated unit tests.
The proprietary code I write is only seen by me. Some GPL code I write also doesn't get proper peer review, but most of it is reviewed by at least three people, and often several others look at it and comment. For Moodle, for example, I post code I'm happy with. I post it with unit tests which test the possible inputs and verify that each function does its job. Then anyone interested in the topic looks at my code and comments, typically 2-4 people. I post revisions and after no-one has any complaints it enters official peer review. At that stage, a designated programmer familiar with that section of the code examines it, suggests changes, and eventually signs off on it when we're both satisfied that it's correct. Then it goes to the tester. After that, the integration team. Moodle doesn't get very many new bugs because of this quality control process. That's independent of how easily bugs are fixed, how shallow they are, depending on how many people are trying to fix the bug.
PolarSSL is GPLv2
I am very small, utmostly microscopic.