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.
pleese see this good article related :http://www.networkworld.com/weblogs/security/003879.html
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.
It's a best practice... how can it be wrong?
Maybe I'm missing something but since when is 17-20% market share (the estimates I've heard of the number of affected sites) a "monoculture"? Sure there were some biggies in there, but seems to me diversity worked pretty well in this case.
Can't blame Microsoft for this or use the "many eyes" argument either.
Only the State obtains its revenue by coercion. - Murray Rothbard
It sounds like he is talking about security-by-obscurity and using something different from the norm is "better".
While I now (didn't previously till the heartbleed issue) think that OpenSSL should have been better maintained, I think it would be worse in general if we all rolled our own implementations (by this I mean, not just forking it or compiling it ourselves, I mean fully writing it from scratch so you know exactly how it is meant to work).
It kind of reminds me of that XKCD comic about standards in that we would end up with so many different implementations to "stay secure" that we might then try to make one implementation that acts like all of them.
This also seems similar to the argument people used for Macs saying they don't get viruses because they aren't used by enough people.
Uh, someone seems mad that they have to resort to the ready-for-granny kind of OS. Sweet.
CLI paste? paste.pr0.tips!
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.
Penguins feathers ruffled by truth. Go figure. From +1 to 0 Insightful, to -1 Troll. If truth = troll something's amiss.
Too bad they hadn't forked OpenSSL a while back. Now there is a competing library.
Now we need to support that fork, and assess the feasibility of porting to Linux as well as the other BSD's, of course.
Do they have a new name for it yet?
If SSL = "Secure Sockets Layer", how about: ActualSSL (it's actually secure), DaemonSSL, Pitchfork(ed)SSL, something...
-- Mike Greaves
It looks like they called it: LibreSSL
http://www.libressl.org/
That's what it looks like, anyway.
Support them if you can!
-- Mike Greaves
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.
Most web sites have no need for SSL/TLS. Therefore, 17% of web sites could mean ALL "secure" sites were affected. OpenSSL might have 90% market share in the sense that 90% of SSL connections use OpenSSL and that could still be 17% of web sites.
Some can say C language is a problem, maybe they are right it will do more harm to FOSS, then proprietary software ever will...
Grouping together the Windows OS business monopoly and the wide use of OpenSSL fails to recognize a critical point. Windows OS is huge and closed. OpenSSL, for all the naive press about how big a code base it is, is actually pretty small (and could be much smaller) and completely open. Microsoft has a well-funded army to ensure its monopoly; laziness on the parts of users has made OpenSSL ubiquitous. The two situations are entirely different and their inherent problems must be solved in entirely different ways. The problem of Windows is a big one; a lot of money and time will have to be spent to deal with it, and probably won't be for a very long time. The problem with OpenSSL is not that big and is being dealt with promptly. The cost estimates we've been reading about are silly: the IT people are employed, anyway, so it's not like that much extra dough is being shelled out for dealing with the Heartbleed problem, and all that's happening is people are scurrying to do what should've been done all along.
For those criticizing OSS, let me ask: what's the solution? More closed-source monopolies? No! The solution, of course, is more OSS! What was the failure here? *Not enough* (to be precise: exactly one) OSS! In the future, we need >= 2 well-supported OSS projects fulfilling the same infrastructure need.
The programmers here claim so few bugs that I'm astounded that software has any remaining bugs at all.
That said, proprietary code can be open too.
No, it can't, by definition. If it's not available to everyone, then it's not "open" in this context.
It absolutely can be open. You can retain full ownership and control of your source code and still let your users have access it to it.
To quote the OSI [opensource.org], "Open source software is ... GNU project's four freedoms [gnu.org] ...
Good thing I didn't say proprietary software is FOSS, mere that it can be open. Sorry but OSI and GNU don't get to redefine the word open.
And you don't get to move the goal post. This discussion is about inspecting source code for bugs. And in this sense proprietary can be as open as FOSS.
No, it isn't, at least not without really exceptional leadership.
Linus holds himself to exceptionally high standards of work, standards which he expects everyone else who commits to the kernel to also adhere to. He's also a complete and total asshole and will think nothing of publicly chastising anyone who doesn't. Self Organisation works for the Linux kernel because for one, only the very best of the best are actually allowed commit privileges and for another anyone who fucks up or gets slack will be caught and will be punished. This means that the people self organize to do the right things.
Debian doesn't write software, at least not much anyway, so they don't really count in the same way. I'd also hazard the guess that the core of Debian is actually rather tightly organised with package maintainers largely being self organised.
Microsoft is a monoculture because of compulsion and despite of sucking more than the alternatives.
OpenSSL isn't quite a monoculture, there are a lot of alternatives, they just happen to suck more.
There are pros and cons to a monoculture in code, but the pros vastly outweigh the cons.
It is no different than any other code-reuse system, from functions that are called from many places in a system, to common libraries, to open-source software running 1/2 the internet. Yes, if there is a bug in a widely-used piece of code, it affects a lot of parts of the system - and the more places it is used the worse the bug is - TEMPORARILY.
The upside is, because this code is used in so many parts, these bugs are rarely missed because of the ramifications. And, when they do happen to be missed and are later discovered, when you fix the bug, the fix "fixes" the whole system at once, not just a piece of it and then you need to go check all the other pieces of the system to see if you need to make the same fix elsewhere.
If the web used many different SSL libraries, some open and some closed, that is not a solution, it is just opening more vectors for attacks and bugs. The more eyes on the code and the more people using it, the fewer the bugs will be. Reducing your attack surface is a HUGE part of security, in fact one of the #1 things. Reuse of code libraries is a major way to reduce that vector.
When the Tsunami hit the east coast of Japan and caused so much saddening destruction.
Our industry (MFP) was hit with a shortage of faxes, and this was purely down to a single low cost chip from a factory in the Tsunami effected region. It was a single point of weakness that no manufacturer was aware of. The supplier companIES were actually just all distributors for the one single producer/factory of the chip.
Lucky the chip was simple and manufacturing was moved to another factory in Chine, but it still took several months for stock to reach a nominal level.
Everyone in the IT industry knows that single points of failure are the most critical aspect of any process. And it's not just the IT industry it's the same in all industries, eg logistics, mining, agriculture, etc. Hence why process design is big in all industries (or getting there).
OK - here's a niche industry page listing about forty open source, commercial and cloud solutions that all have secured by SSL and their responsed to heartbleed:
http://www.filetransferconsult...
Of these...maybe a third had OpenSSL...most of the rest used a Java stack, and many of the rest were on IIS or using MS crypto. Within my own company (about 1500 people and 20 web apps on a mix of platforms), heartbleed affected exactly 3 sites.
If you looked around other industries and saw >50% affected rates maybe I'd believe "monoculture"...but if you're talking the entire web dev world, OpenSSL is just one of the top options.
He pointed to weak/absent leadership and tried to use it as an argument against the need for strong leadership.
Futurist Traditionalism
I have a couple problems with the implication that "short time to find/fix" is so acceptable.
1. Some amount of damage was done (and no one really knows for sure) through this bug. A fix was identified rapidly after the bug was -discovered-, but that's a long time after the bug was -introduced-.
2. For some systems, particularly those like SCADA systems where we really have deep information assurance concerns, patching software is not easy! Not everything can use "grab the patched source, rebuild and reinstall" or even "download the patch and install" repairs.
Thus the emphasis Has To Be on preventing these kinds of problems, then defending against them. Fixing them after the system is deployed is by far the weakest strategy. (Thus I salute with a full hand the initiative announced today, and discussed on a related SlashDot thread: http://news.slashdot.org/story... )
Yup. Heartbleed only affected software running openSSL.
Apache *is* running on openssl, so given that's popularity, heartbleed did affect a lot of websites.
Also curl and wget use it, so a lot of client-side scripts and cron jobs could have been attacked by a rogue webserver.
BUT
it didn't affect GnuTLS (though that one has has its share of problems, too).
and it's very widely used too.
So purple (= pidgin, adium and many other multichat systems), exim (= a huge chunk of email servers), cups (= anything that prints and isn't windows), etc. weren't affected.
it didn't affect Mozilla's NSS
and that one is very popular too (specially in web browser).
So almost Firefox wasn't affected, Chrome wasn't affected, OpenOffice[*] wasn't affected, Purpe use that in addition to GnuTLS but wasn't affected either.
*: Normally used mostly for WebDAVS. But could also use it to retreive any information online (downloading files from HTTPS), including by extentions (think Google Drive syncrhonisation or simply small weather bug).
And that's just 3 big name in the SSL/TLS world.
Not exactly a monoculture, even if openSSL is a bit to much popular.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
I agree quality code is important. I'm glad software architecture is now recognized as an engineering discipline, so you can choose to have a qualified Professional Engineer lead or review a software project.
All of which is largely a separate issue from the observation that with enough people looking at a problem, the solution will be shallow - obvious to someone.
Dear fuckwit author:
CyaSSL
GnuTLS
PolarSSL
NSS
This is not a monoculture. Get a clue.