Slashdot Mirror


Once a Forgotten Child, OpenSSL's Future Now Looks Bright

Trailrunner7 writes: Rarely does anything have a defined turning point in its history, a single day where people can point and say that was the day everything changed. For OpenSSL, that day was April 7, 2014, the day that Heartbleed became part of the security lexicon. Heartbleed was a critical vulnerability in the venerable crypto library. OpenSSL is everywhere, in tens of thousands of commercial and homespun software projects. And so too, as of last April, was Heartbleed, an Internet-wide bug that leaked enough memory that a determined hacker could piece together anything from credentials to encryption keys.

"Two years ago, it was a night-and-day difference. Two years ago, aside from our loyal user community, we were invisible. No one knew we existed," says Steve Marquess, cofounder, president and business manager of the OpenSSL Foundation, the corporate entity that handles commercial contracting for OpenSSL. "OpenSSL is used everywhere: hundreds, thousands of vendors use it; every smartphone uses it. Everyone took that for granted; most companies have no clue they even used it." To say OpenSSL has been flipped on its head—in a good way—is an understatement.

Heartbleed made the tech world realize that the status quo wasn't healthy to the security and privacy of ecommerce transactions and communication worldwide. Shortly after Heartbleed, the Core Infrastructure Initiative was created, uniting The Linux Foundation, Microsoft, Facebook, Amazon, Dell, Google and other large technology companies in funding various open source projects. OpenSSL was the first beneficiary, getting enough money to hire Dr. Steve Henson and Andy Polyakov as its first full-timers. Henson, who did not return a request to be interviewed for this article, is universally known as the one steady hand that kept OpenSSL together, an unsung hero of the project who along with other volunteers handled bug reports, code reviews and changes.

38 of 76 comments (clear)

  1. Huh? What? by Anonymous Coward · · Score: 1

    What in the fuck kind of summary did I just read?

    1. Re:Huh? What? by yamum · · Score: 2

      It was a big load of toss.

    2. Re: Huh? What? by Anonymous Coward · · Score: 2, Insightful

      Revisionist shitstory.

      The OpenSSL declared themselves emperors of security. They declared you knew shit and could help. They declared their cloth was whole.

      These emperors were shown to wear no clothes. They weren't secure, they were pompous asses.

      All the eyes don't matter when the gate keeper sucks.

    3. Re: Huh? What? by Anonymous Coward · · Score: 3, Informative

      Also: "...every smartphone uses it."
      Do any smartphones use openssl? Android uses BouncyCastle and Apple uses their own crypto libraries (they provide openssl for compatibility purposes on OSX, but not iOS). Microsoft has their own crypto libraries, too, so I doubt Windows Phones use openssl...

  2. Paid Advertisement by Elgonn · · Score: 4, Informative

    Someone has to be shilling to post a summary like that one. The only future for OpenSSL is to be replaced over time by LibreSSL or another competitor.

    1. Re:Paid Advertisement by Anonymous Coward · · Score: 2, Insightful

      So that's what they are using all those grants and donations for?
      To promote their shitty software and the engineers working on it?
      I really wish the money was called back and given to LibreSSL and other projects which actually deserve it.

    2. Re:Paid Advertisement by yuhong · · Score: 2

      Yes, but this saying nothing about the future of it etc.

    3. Re:Paid Advertisement by yuhong · · Score: 2

      LibreSSL is not a complete rewrite.

    4. Re:Paid Advertisement by swillden · · Score: 5, Insightful

      Someone has to be shilling to post a summary like that one. The only future for OpenSSL is to be replaced over time by LibreSSL or another competitor.

      Nah. The OpenSSL codebase will get cleaned up and become trustworthy, and it'll continue to be used. The other forks, especially LibreSSL and Google's BoringSSL, will be used, too... and that's a good thing. Three fairly API-compatible but differing implementations will break up the monoculture so bugs found in one of them (and they *will* have bugs) hopefully won't hit all three of them.

      It's tempting to see such apparent duplication of effort as wasteful, but it's really not. Diversity is good and competition is good.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    5. Re:Paid Advertisement by Anonymous Coward · · Score: 1

      I doubt yuhong is an idiot, but tsk tsk tsk with the childish name, clearly the sign of being the emotional equivalent of a 5 year old. It would have been a good post, but you had to put in the pointless insult that did nothing but make you look the part of a fool.

    6. Re:Paid Advertisement by Kjella · · Score: 4, Interesting

      Nah. The OpenSSL codebase will get cleaned up and become trustworthy, and it'll continue to be used. The other forks, especially LibreSSL and Google's BoringSSL, will be used, too... and that's a good thing. Three fairly API-compatible but differing implementations will break up the monoculture so bugs found in one of them (and they *will* have bugs) hopefully won't hit all three of them. It's tempting to see such apparent duplication of effort as wasteful, but it's really not. Diversity is good and competition is good.

      Has the fact that there's three major BSDs and one Linux been in BSD's favor? I have to pick an implementation and live with its bugs, either my machine is compromised or it's not. And those using other implementations will be hit with other bugs compromising their machines. Does it really provide any tangible benefit that not all of us are hit at the same time with the same bug, when we're all vulnerable some of the time? You divide the number of targets, but you also divide the number of developers and testers. For that matter, the eyes in "many eyes makes all bugs shallow" as well. And if you think the only true test is the test of time, the total value and exposure to the bad guys.

      Am I supposed to swap browsers every time a vulnerability is found in Firefox/Chrome/Safari/IE? And wouldn't that quickly lead to a monoculture as a project dies every time it screws up big? Or if not, what exactly are the other implementations going to do for me? Software isn't like experimental physics where you want independent verification that if you try the same thing you get the same result. It's more like math where you need a formal proof that the code will always do what you intend for it to do and that it stands up under scrutiny.

      We're not talking about something that must have a fail rate, if you get it right it's good. For example look at Apache and IIS, they're massively exposed yet there's very, very few exploits of significance. Okay so that's two not one implementation, but lack of diversity is mostly a problem when you have one bad product like java or flash that is a serial offender. Nobody has a problem with a monoculture that works and there's many of those. Don't allow crap in, code defensively, have reviews and fix the security bugs that get past you in a timely fashion and there won't be any need to reinvent the wheel.

      --
      Live today, because you never know what tomorrow brings
    7. Re:Paid Advertisement by Bengie · · Score: 1

      The main PFSense guy trusts one of the main new OpenSSL people, so PFSense is sticking with OpenSSL.

    8. Re:Paid Advertisement by swillden · · Score: 1

      Has the fact that there's three major BSDs and one Linux been in BSD's favor?

      Being able to choose an operating system (BSDs, Linux, commercial UNIXen, Windows, etc.) has been in your favor, particularly from a security perspective. And would you seriously argue that the existence of multiple BSDs has been a bad thing for their security? I'd argue exactly the opposite. The BSDs, have a well-deserved reputation for being more secure than Linux, and part of that reputation arose directly from the BSD forking. In particular, OpenBSD forked specifically to focus on security, and FreeBSD and NetBSD worked to keep up.

      Does it really provide any tangible benefit that not all of us are hit at the same time with the same bug, when we're all vulnerable some of the time?

      Yes, it does. You seem to think that being vulnerable none of the time is an alternative. It's not. The system as a whole is much more resilient if vulnerabilities affect only a subset.

      For that matter, the eyes in "many eyes makes all bugs shallow" as well.

      Look how well that has worked for OpenSSL in the past. The many eyes principle only matters if people are looking, and competition creates attention. Also, it's a common error to assume that the software ecosystem is like a company with a fixed pool of staff that must be divided among the projects. It's not. More projects (open and closed source) opens up more opportunities for people to get involved, and creates competition among them.

      Competition also often creates funding opportunities, which directly addresses what was OpenSSL's biggest problem. You can argue that it also divides funding, but again that only holds if you assume a fixed pool of funding, and that's not reality. Google is contributing to OpenSSL development and almost fully funding BoringSSL (not with cash, but with people). That isn't because Google's left hand doesn't know what its right is doing.

      Am I supposed to swap browsers every time a vulnerability is found in Firefox/Chrome/Safari/IE?

      Huh? No, obviously, you choose a browser with a development team that stays on top of problems and updates quickly. It's almost certain that developers will choose their SSL library at least partly on the same basis, again favoring more work and more attention on the crucial lib.

      It's more like math where you need a formal proof that the code will always do what you intend for it to do and that it stands up under scrutiny.

      It's not, it's really not. It would be nice if that were true. It's really more like a car that breaks down over time in various ways; some are more reliable than others, but all require ongoing attention and maintenance.

      We're not talking about something that must have a fail rate, if you get it right it's good.

      This is true in theory, but untrue in practice, because new attacks come along all the time and ongoing maintenance (non-security bugfixes, new features, etc.) introduce new opportunities for security bugs.

      Your Apache and IIS counterexamples are actually support my argument. IIS, in particular, was riddled with problems. Yes they've been cleaned up, but you're talking about a space that has been static for almost two decades (though it will soon be destabilized with the introduction of HTTP/2 and probably QUIC) and is, frankly, a much simpler problem than that solved by OpenSSL... and I assert that without the competition of alternatives, IIS never would have been cleaned up as thoroughly as it is.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    9. Re:Paid Advertisement by QuietLagoon · · Score: 1

      The OpenSSL codebase will get cleaned up and become trustworthy, and it'll continue to be used

      Cleanup up and trustworthy? Unlikely. The wrong people are still in charge for that to happen.

      Continue to be used? Unfortunately, that is probably correct.

    10. Re:Paid Advertisement by zeugma-amp · · Score: 1

      and I assert that without the competition of alternatives, IIS never would have been cleaned up as thoroughly as it is.

      That's a pretty safe assertion for anyone who remembers how long IIS stagnated after Microsoft had successfully destroyed Netscape. You might recall that Microsoft did almost nothing with IIS for years until Firefox was a credible competitor. How long did it take Microsoft to implement tabbed browsing?

      --
      This is an ex-parrot!
    11. Re:Paid Advertisement by swillden · · Score: 4, Insightful

      The OpenSSL codebase will get cleaned up and become trustworthy, and it'll continue to be used

      Cleanup up and trustworthy? Unlikely. The wrong people are still in charge for that to happen.

      Nonsense. The people running the OpenSSL project are competent and dedicated. OpenSSL's problem was lack of resources. It was a side project with occasional funding to implement specific new features, and the funders of new features weren't interested in paying extra to have their features properly integrated and tested. That's not a recipe for great success with something that really needs a full-time team.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    12. Re:Paid Advertisement by swillden · · Score: 1

      I think you're confusing IIS and IE, but your comment actually still make some amount of sense :-)

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    13. Re:Paid Advertisement by hairyfeet · · Score: 1, Insightful

      If there is but one thing everyone should have learned from Heartbleed and Shellshock it is this....many eyes is a myth based on an "is ought" fallacy.

      OpenSSL and Bash are the two most widely deployed pieces of code on the planet, bar none. If "many eyes" were true that fact SHOULD have made them the most vetted code on the planet....but they weren't, why? Because "many eyes" is an "is ought" fallacy in that because the source code IS there and it IS in wide use there OUGHT to have been at least one or more people with the years of training in low level code auditing that should have looked at the code and found the bugs and reported them.....this ignores the facts, which are 1.- The guys that can do low level auditing are very few, 2.- They are usually swamped with jobs that pay them, and most importantly 3.- Everyone is gonna ignore the code because they'll believe somebody else did it thanks to the "many eyes" myth.

      This is why "many eyes" should be considered a harmful myth to allow to spread, since everybody just assumes somebody else has done the work when in reality? I bet if you looked at the number of downloads of the source for the low level code in your average Linux distro you'll find that nobody other than the guys that are actually working on the code have downloaded it. So let us all put the "many eyes" myth to bed, and then maybe everyone won't just assume the work has been done and actually start looking at the code!

      --
      ACs don't waste your time replying, your posts are never seen by me.
    14. Re:Paid Advertisement by Sloppy · · Score: 1

      Install the emacs plugin.

      --
      As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
  3. LibreSSL by Anonymous Coward · · Score: 4, Informative

    OpenSSL.... yeah, right, whatever.
    LibreSSL is the one that deserves all the credit and support.
    With a smaller team and zero experience working with the codebase, LibreSSL has consistantly beat OpenSSL to the punch regarding ripping out trash, rendering and refactoring garbage into sanity, and fixing bugs.
    OpenSSL should have been doing this all along but were just lazy, not competent, poorly organized, etc.
    And now they just go all "we're a foundation now" and reap kudos from the world?
    BAH, totally undeserving.
    And all you're going to get is the same crap in the tarball instead of new original thoughts.

    1. Re:LibreSSL by phantomfive · · Score: 2

      With a smaller team and zero experience working with the codebase, LibreSSL has consistantly beat OpenSSL to the punch regarding ripping out trash, rendering and refactoring garbage into sanity, and fixing bugs.

      But they don't have a cloud-computing based audit of the source code (really.....according to the article, that is what the openssl team is waiting for; ok, they call it 'high-powered-computing' but a buzzword is a buzzword).

      --
      "First they came for the slanderers and i said nothing."
    2. Re: LibreSSL by Anonymous Coward · · Score: 1

      Cloud computing is a buzzword too

    3. Re:LibreSSL by gatkinso · · Score: 1

      "Buzzword" is a buzzword.

      --
      I am very small, utmostly microscopic.
    4. Re:LibreSSL by phantomfive · · Score: 1

      oh? You can go innovate your buzzword into the cloud!

      --
      "First they came for the slanderers and i said nothing."
  4. A giant pile of crap by EmperorOfCanada · · Score: 1

    I said this before Heartbleed when everyone thought that OpenSSL was the best and the programmer who made it, gods. The code is crap. The variable names 70s style crap. The file structure crap. The multi platforming methodology crap. The function names crap. The API crap.

    To call it spaghetti code is insulting to visual basic programmers everywhere.

    To me this is like what people are realizing with many police departments; it isn't just a few bad apples. If the good apples condone the bad apples then they are all bad apples. It is the same with OpenSSL it was a shitty project before heartbleed and keeping anyone with the project from those days is just wrong. If they were programmers with the slightest sense of decency or capability they would have grouped together and forked the project.

    1. Re:A giant pile of crap by Anonymous Coward · · Score: 2, Interesting

      To be fair, EAY wrote SSLeay in the mid-90s when standards were a secondary consideration, and compilers frequently generated incorrect code - while being infrequently updated. On top of that, there were no practical cross-platform build systems. It's easy to look at 'clean' code like PolarSSL, GnuTLS, etc., and conclude that they're better. The fact is, they haven't really been tested. I don't see countermeasures for cache timing attacks in many of the come-lately SSL/TLS libraries. The GnuTLS 'bignum' code is fucking amateur hour stuff. Even the bloated and exception-unsafe GMP library has better secure functions, despite the fact that it drops dead at the first sign of trouble, and is utterly unsuitable for embedded or secure environments.

      LibreSSL is going to be another 'NIH' project that will spend the next decade being patched by people who realise that crypto software can't be left to dilettantes.

    2. Re:A giant pile of crap by Anonymous Coward · · Score: 1

      You do not know how the assembly maps to uops in modern cpu
      And someone cant take the time to figure it out?

      I have been watching these hacking videos and watching the master piece of reverse engineering of the MAME/MESS team for many years. It is only a matter of time and knowledge. I have watched dudes take a single string exploit and turn it into total ownership of the whole system.

      There is a whole subculture of programmers that love ripping this stuff apart. They have amazing tools like IDA and its flotilla of plugins. Some then create complete software emulated versions using the original roms.

      That is just the amateurs. Then there are the pro guys. They are a whole different set and they have the tools to rip pretty much anything apart. They are not afraid of a bit of solder and an oscilloscope to bit bang out 500 bytes of data.

      I used to think like you. But over the past few years I have come to realize no computer is safe. NONE. All I can do is put up walls of stuff that the hackers neatly sidestep because of one little mistake.

    3. Re:A giant pile of crap by greg1104 · · Score: 1

      No one who looked at the code has ever considered the programmers behind it "gods". The PostgreSQL developers for example have been complaining about it for years, including a major look at alternatives in 2011 because we hated the code's API and its license so much. However, that crappy API serves as a form of lock-in, making it harder to migrate to other libraries than it should be.

  5. Money given to the people that screwed up... by QuietLagoon · · Score: 3, Insightful
    So let's see... from what I've read the OpenSSL project was a mess, poorly managed, with bad code and a very lax attitude towards fixing bugs that were reported.

    .
    So how was the problem with OpenSSL solved?

    Well, the same people, with their same ideas, who could not run a successful project in the past were given large amounts of money to run the project in the future. The summary for this thread reads more like a self-congratulatory press release from the OpenSSL people, rubbing in our faces that they managed to get money to continue their poor project management.

  6. nginx now supports BoringSSL and LibreSSL by QuietLagoon · · Score: 1
    From the nginx changelog

    *) Feature: now nginx can be build with BoringSSL and LibreSSL. Thanks to Piotr Sikora.

  7. Why wouldn't Henson even *respond*? by SuperBanana · · Score: 2

    Why couldn't Henson even be bothered to respond to the request for an interview, much less be interviewed?

    For fuck's sakes, man. You're now fully employed for OpenSSL. Would it kill you to do an interview?

  8. What's up with the diffs? by gustygolf · · Score: 4, Interesting

    The diffs are huge every single time, despite the releases being boring bug and security fixes. Things that shouldn't need more than twenty lines each.

    % diff -rNU 0 openssl-1.0.1[lm]|wc
        675635 2681760 21556437

    Twenty-one megabytes. 675 thousand lines changed.

    Here's the changelog between 1.0.1L and 1.0.1M, for two months of bugfixes:


      Changes between 1.0.1l and 1.0.1m [19 Mar 2015]

        *) Segmentation fault in ASN1_TYPE_cmp fix
            [detailed descriptions snipped]
        *) ASN.1 structure reuse memory corruption fix
        *) PKCS7 NULL pointer dereferences fix
        *) DoS via reachable assert in SSLv2 servers fix
        *) Use After Free following d2i_ECPrivatekey error fix
        *) X509_to_X509_REQ NULL pointer deref fix
        *) Removed the export ciphers from the DEFAULT ciphers

    Twenty-one megabytes for seven fixes. What the hell are they doing with their source code to create that much churn?

    --
    "Slow Down Cowboy! It's been 58 minutes since you last successfully posted a comment" -- slashdot, driving users away.
    1. Re:What's up with the diffs? by tmshort · · Score: 2

      They completely changed the formatting from the UGLYNESS that it was (actual tab characters and indented braces) to a much more sane formatting (closer to the Linux Kernel).

    2. Re:What's up with the diffs? by fisted · · Score: 1

      Yeah that's odd. If you add -w to diff, then it reduces to "only" 9 megs. If you look into the diff, you see it's a massive style commit. Removing redundant braces, breaking long lines, indenting preprocessor directives.

      They really should have mentioned it in the changelog.
      Plus, *adjusts tinfoil hat*, that's exactly the kind of commit where a deliberate change is as easily inserted as it is overlooked...

    3. Re:What's up with the diffs? by fisted · · Score: 1
  9. Tool assisted review by DrYak · · Score: 1

    The problem is that some of the design decision behind openssl are so aweful that some of the code review tools just don't work well to detect bug.

    Hearthbleed has specifically resisted to valgrind, because the geniuses behind openssl had implemented they own memory management replacement functions in a way that is resistant to memory analysis.
    The memory porblem went undetected.

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
  10. Depends by DrYak · · Score: 2

    For the "many eyes" to work, there are quite few requirement.

    Yes, being opensource is a requirement, but is not the single only requirement.

    The code need to be actually readable and to attract users motivated to check it.
    That wasn't the case. OpenSSL's code is known to be really crappy, with lots of bad decisions inside. Any coder trying to review it will have their eyes starting to bleed.
    It doesn't attract people who might review it. It only attracts the kind of people who just want to quickly hack a new feature and slap it on the top, without having a look at what's running underneath.

    The code need also to be reasonably accessible to code review tools.
    Lots of reviewers don't painfully check every single last line of code by hand. Some use tools to do controls. OpenSSL has had such a series of bad decision in the past, that the resulting piece of neightmare is resistant to some types of analysis.

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
  11. Time is the difference by tepples · · Score: 1

    You do not know how the assembly maps to uops in modern cpu

    And someone cant take the time to figure it out?

    I have been watching these hacking videos and watching the master piece of reverse engineering of the MAME/MESS team for many years. It is only a matter of time and knowledge.

    And "time" points to the major difference. The MAME project tends to wait years after a game's release before emulating it. Server operators, on the other hand, expect to use a cryptography library on servers with new CPUs immediately.