OpenBSD Journal

OpenBSD has started a massive strip-down and cleanup of OpenSSL

Contributed by phessler on from the how-i-learned-to-stop-worrying-and-shine-the-turd dept.

The denizens of lobste.rs (and no doubt you, eagle-eyed reader!) have made note of the ongoing rototilling of the OpenSSL code in OpenBSD, and Joshua Stein (jcs@) has chimed in with a quick breakdown of the action thus far:

Changes so far to OpenSSL 1.0.1g since the 11th include:

  • Splitting up libcrypto and libssl build directories
  • Fixing a use-after-free bug
  • Removal of ancient MacOS, Netware, OS/2, VMS and Windows build junk
  • Removal of “bugs” directory, benchmarks, INSTALL files, and shared library goo for lame platforms
  • Removal of most (all?) backend engines, some of which didn’t even have appropriate licensing
  • Ripping out some windows-specific cruft
  • Removal of various wrappers for things like sockets, snprintf, opendir, etc. to actually expose real return values
  • KNF of most C files
  • Removal of weak entropy additions
  • Removal of all heartbeat functionality which resulted in Heartbleed

To clarify, not all of the cryptographic engines were removed; the padlock and aesni engines are still in place.

As always, it's heartening to see a concentrated effort on such a critical software component.

(Comments are closed)

Comments

  1. By jdv (216.16.224.222) jdv@clevermonkey.org on http://clvrmnky.org/

    Oh thanks be to Crom. As someone who has had to integrate OpenSSL into two different product build trees, this is long overdue. Hopefully, they take the diffs upstream, but my guess is that this is going to be the OpenBSD fork of OpenSSL 1.0.1c (I think?).

    Messy, but necessary.

    Comments

    1. By jdv (216.16.224.222) jdv@clevermonkey.org on

      > Oh thanks be to Crom. As someone who has had to integrate OpenSSL into two different product build trees, this is long overdue. Hopefully, they take the diffs upstream, but my guess is that this is going to be the OpenBSD fork of OpenSSL 1.0.1c (I think?).
      >
      > Messy, but necessary.

      s/1.0.1c/1.0.1g/

      I like the phrase I'm seeing being used here: "now that there is limited communication with the upstream provider..."

      Comments

      1. By Anonymous Coward (184.70.180.50) on


        >
        > I like the phrase I'm seeing being used here: "now that there is limited communication with the upstream provider..."

        What upstream maintaner? All I see is a bunch of well paid FIPS compliance consultants using the codebase for their own business.
        nothing useful comes from "upstream" for anyone else.

  2. By Anonymous Coward (107.197.28.197) on

    Is this just because OpenSSL is just so widely used? Otherwise, axTLS or TropicSSL seem like more logical starting points (to flesh out rather than prune), unless the license is not a consideration here.

    Comments

    1. By Marc Espie (espie) on

      > Is this just because OpenSSL is just so widely used? Otherwise, axTLS or TropicSSL seem like more logical starting points (to flesh out rather than prune), unless the license is not a consideration here.

      Yep. The current changes are already going to be painful enough on ports that we didn't even consider seriously anything else.

      That effort won't amount to much if the "fork" doesn't stay compatible enough with openssl that we can keep porting software easily...

  3. By Anonymous Coward (23.242.254.17) on

    Can we please rename the forked project to something such as SecureSSL?

    OpenSSL is not maintained by responsible people. Even if OpenBSD cleans this up, and even if the OpenBSD code is absorbed upstream, this irresponsible group might screw things up again.

    If it is renamed to SecureSSL then it might be ported and adopted by major distributions and we can all sail off into the sunset.

    Comments

    1. By Chris (50.71.129.10) on

      > Can we please rename the forked project to something such as SecureSSL?
      >
      > OpenSSL is not maintained by responsible people. Even if OpenBSD cleans this up, and even if the OpenBSD code is absorbed upstream, this irresponsible group might screw things up again.
      >
      > If it is renamed to SecureSSL then it might be ported and adopted by major distributions and we can all sail off into the sunset.

      OpenOpenSSL

      Comments

      1. By Anonymous Coward (90.185.106.200) on

        > > Can we please rename the forked project to something such as SecureSSL?
        > >
        > > OpenSSL is not maintained by responsible people. Even if OpenBSD cleans this up, and even if the OpenBSD code is absorbed upstream, this irresponsible group might screw things up again.
        > >
        > > If it is renamed to SecureSSL then it might be ported and adopted by major distributions and we can all sail off into the sunset.
        >
        > OpenOpenSSL

        OpenSecret

        Comments

        1. By Anonymous Coward (183.179.14.210) on

          > > > Can we please rename the forked project to something such as SecureSSL?
          > > >
          > > > OpenSSL is not maintained by responsible people. Even if OpenBSD cleans this up, and even if the OpenBSD code is absorbed upstream, this irresponsible group might screw things up again.
          > > >
          > > > If it is renamed to SecureSSL then it might be ported and adopted by major distributions and we can all sail off into the sunset.
          > >
          > > OpenOpenSSL
          >
          > OpenSecret

          OpenTLS

          Comments

          1. By Anonymous Coward (23.242.254.17) on

            > > > > Can we please rename the forked project to something such as SecureSSL?
            > > > >
            > > > > OpenSSL is not maintained by responsible people. Even if OpenBSD cleans this up, and even if the OpenBSD code is absorbed upstream, this irresponsible group might screw things up again.
            > > > >
            > > > > If it is renamed to SecureSSL then it might be ported and adopted by major distributions and we can all sail off into the sunset.
            > > >
            > > > OpenOpenSSL
            > >
            > > OpenSecret
            >
            > OpenTLS
            >

            Original poster here... Thank you.

            Obviouly openssl would be a good name but it already has that name and then the other guy made the openopenssl comment but opentls would be legit

          2. By Philip Guenther (196.200.178.2) guenther@openbsd.org on

            > OpenTLS

            Do the people making this suggestion not *know* that there's already an unrelated project with that name? Is typing it into a browser URL bar too hard? Or do they just not *care*?

            Comments

            1. By G.P (193.200.119.132) on

              > > OpenTLS
              >
              > Do the people making this suggestion not *know* that there's already an unrelated project with that name? Is typing it into a browser URL bar too hard? Or do they just not *care*?
              >

              Of course we know there is/was opentls.org, but project seems pretty dead, isn't it?
              Throw out support for SSLv3 and rename it to OpenTLS IMHO.

      2. By Anonymous Coward (174.17.178.157) on

        > > Can we please rename the forked project to something such as SecureSSL?
        > >
        > > OpenSSL is not maintained by responsible people. Even if OpenBSD cleans this up, and even if the OpenBSD code is absorbed upstream, this irresponsible group might screw things up again.
        > >
        > > If it is renamed to SecureSSL then it might be ported and adopted by major distributions and we can all sail off into the sunset.
        >
        > OpenOpenSSL

        OpenBSDSSL

    2. By Anonymous Coward (46.114.130.131) on

      > Can we please rename the forked project to something such as SecureSSL?

      Yeah, let's stop the coding work, we need some elite name, a mailing list, and a logo first!

      Comments

      1. By Anonymous Coward (23.242.254.17) on

        > > Can we please rename the forked project to something such as SecureSSL?
        >
        > Yeah, let's stop the coding work, we need some elite name, a mailing list, and a logo first!
        >

        First of all I didn't suggest that we somehow prioritize something over the code. Second, you obviously do not understand how the world works. In case you are a noob, and since you are acting like one, let me give you some OpenBSD history.

        OpenBSD has spun up several major projects such as OpenSSH, OpenNTP, OpenBGP, PF, and the Apache fork. Some things have become an industry standard such as OpenSSH, and some things are not (such as the OpenBSD Apache fork, which has been removed even from base), and some things have found their way into some projects with moderate success such as PF. I was suggesting that OpenBSD treat this fork more like OpenSSH and less like the Apache fork.

        This can involve "branding" in the sense that people outside of the OpenBSD project, who happen to be the people with the insecure end of those sessions that you care about, will need some type of differentiation. Is the branding necessary? Not absolutely, but ssh became openssh, ipf became pf, and I thought that it would have a higher probability of global infrastructure penetration if OpenSSL became something else (having the word open as a prefix in the current project makes this a bit annoying and I came up with SecureSSL). This is because the same way that you are a noob to the way that noob technologists work, noob technologists are noobs to OpenBSD, it's side projects, and fixing the SSL issue.

        I would like to add that even if the fix is such that one end of the connection being secure using an OpenBSD box will make the session secure, there is nothing to say that in complex web architectures the same data will not get passed around in other places using broken SSL implementations (which is what I am really paranoid about). Since you are a noob, you probably do not understand this, but lets just say it is what it is because I fucking said so.

        For the record, I liked another persons suggestion in this thread that we call it OpenTLS. My original idea of calling it SecureSSL was not as cool.

        Now please go fuck yourself noob. :)

        Comments

        1. By phessler (phessler) on why in god's name am I wearing pants?

          > Now please go fuck yourself noob. :)

          Not only are you totally wrong, you are being rude. Please think before you post.

          Comments

          1. By Anonymous Coward (23.242.254.17) on

            > > Now please go fuck yourself noob. :)
            >
            > Not only are you totally wrong, you are being rude. Please thiif i k before you post.

            Why wrong? Perhaps my experience with industry behavior is not a good representitive of industry behavior, but thats irrelevant. I would like to hear your thoughts on the topic. As stated, the way I see it is that unfortunately a phrase like "did you switch from openssl to opentls? Its the new and secure openssl from the guys who make openssh." Is the best way to get people to adopt and or port a fork because of their ignorance. Look at all the obvious and avoidable disasters out there.

            my major issue is that you can upgrade you box all you want but every service or app that you use has multiple layers and tiers that are potentially connected with ssl, and they connect with partners and affiliates with ssl as well.

            also my default response to rudeness is to escalate, but I suppose I could have been less abrasive about it. It wasnt my intention to derail further.

          2. By Anonymous Coward (68.96.73.45) on

            > > Now please go fuck yourself noob. :)
            >
            > Not only are you totally wrong, you are being rude. Please think before you post.

            Original poster here. Guess who wasnt wrong? Libressl ftw

    3. By tbert (tbert) on

      > Can we please rename the forked project to something such as SecureSSL?
      >
      > OpenSSL is not maintained by responsible people. Even if OpenBSD cleans this up, and even if the OpenBSD code is absorbed upstream, this irresponsible group might screw things up again.
      >
      > If it is renamed to SecureSSL then it might be ported and adopted by major distributions and we can all sail off into the sunset.

      GoatseSSL

    4. By Anonymous Coward (216.16.224.222) on

      > Can we please rename the forked project to something such as SecureSSL?
      >
      > OpenSSL is not maintained by responsible people. Even if OpenBSD cleans this up, and even if the OpenBSD code is absorbed upstream, this irresponsible group might screw things up again.
      >
      > If it is renamed to SecureSSL then it might be ported and adopted by major distributions and we can all sail off into the sunset.

      OpenBikeShed

    5. By Ed Ahlsen-Girard (132.3.37.84) on

      > Can we please rename the forked project to something such as SecureSSL?
      >
      > OpenSSL is not maintained by responsible people. Even if OpenBSD cleans this up, and even if the OpenBSD code is absorbed upstream, this irresponsible group might screw things up again.
      >
      > If it is renamed to SecureSSL then it might be ported and adopted by major distributions and we can all sail off into the sunset.

      ReallySSL. Which would explain what that project is about.

  4. By Chas (147.154.235.102) on

    I'm not competent to code such things, but is it possible for calls to the OpenSSL library to automatically fork off a process with reduced privilege when appropriate?

    Transparent privilege separation could have prevented heartbleed.

    Comments

    1. By phessler (phessler) on why in god's name am I wearing pants?

      > I'm not competent to code such things, but is it possible for calls to the OpenSSL library to automatically fork off a process with reduced privilege when appropriate?
      >
      > Transparent privilege separation could have prevented heartbleed.

      No. You can't do that in libraries.

  5. By Anonymous Coward (9.98.35.50) on

    why not polarssl or other forks?

    Comments

    1. By Martin (88.159.206.139) on

      > why not polarssl or other forks?

      PolarSSL is not a fork of OpenSSL, but a completely different library. It's also GPL.

      Comments

      1. By Anonymous Coward (107.197.28.197) on

        > > why not polarssl or other forks?
        >
        > PolarSSL is not a fork of OpenSSL, but a completely different library. It's also GPL.

        I think he meant forks of PolarSSL, like TropicSSL, a fork of the last BSD-licensed release of XySSL/PolarSSL.

        In any case, it was explained to me above that simply too much software relies on OpenSSL to ever be replaced by a simpler library in any reasonable amount of time; fixing OpenSSL is higher up the list of priorities. Hopefully if OpenSSL can be cleaned up relatively well and given a solid API, another library can be fleshed out until it can be considered a drop-in replacement.

  6. By chronicdiscord (70.31.53.212) on

    Does this mean we'll be getting a Meatloaf-style song for the next release talking about how Puff would do anything for software, but he won't do that?

    Instead of a motorcycle engine revving up, they could use the sound of a damaged fan chugging along.

  7. By Anonymous Coward (65.110.26.253) on

    Removing the RSA key creates a timing attack https://twitter.com/matthew_d_green/status/456960435845996544

    Comments

    1. By Anonymous Coward (91.154.66.65) on

      > Removing the RSA key creates a timing attack https://twitter.com/matthew_d_green/status/456960435845996544

      "Removing the RSA key". Right. I guess you do not understand the code or the diff. You're just parroting something someone said on twitter. And that someone is wrong.

    2. By Anonymous Coward (79.238.24.72) on

      > Removing the RSA key creates a timing attack https://twitter.com/matthew_d_green/status/456960435845996544
      >
      >

      And you conveniently failed to keep reading to where he got the true state of things explained, and then recanted:

      https://twitter.com/matthew_d_green/status/457170063519657985

      Better trolls, plz.

  8. By JoeUser (184.56.20.112) ju@gmail.com on

    Too little, too late, imho.

    Theo et. al. rant and rave about "the most secure operating system on the planet" and yet the fixes to OpenSSL were left to be fixed AFTER the sky fell.

    So what DO you spend you money on Mr. DeRat? :) Those Hackathons really work, huh?

    Frikkn' morons.

    Comments

    1. By Anonymous Coward (91.154.66.65) on

      > Too little, too late, imho.
      >
      > Frikkn' morons.

      Thank you for doing so much and at the right time too. We are all thankful for your plentiful contributions, Joe. You sir have earned the right to bitch and moan.

    2. By Anonymous Coward (50.71.129.10) on

      >
      >
      > So what DO you spend you money on Mr. DeRat? :) Those Hackathons really work, huh?
      >
      The results of each hackathon can be seen on the CVS changes list.

    3. By Free Bird (217.149.210.16) on

      Well, no one else fixed OpenSSL either and in fact OpenBSD is the only project to now have started doing so (to the best of my knowledge), so the claim of being the most secure still stands.

      Comments

      1. By chronicdiscord (70.31.112.39) on

        > Well, no one else fixed OpenSSL either and in fact OpenBSD is the only project to now have started doing so (to the best of my knowledge), so the claim of being the most secure still stands.

        And really the reason they hadn't ever done it before is pretty fucking obvious - cause it's not their code.

        If someone expects every Linux development team to review the entire codebase of every userland tool they have in their systems, they're not just going to have a bad time, they're a moron.

        OpenBSD developers have a userland and a kernel that they review and maintain, OpenSSL was not a part of that until just recently because OpenSSL has it's own development team that were expected to do that.

        Comments

        1. By Anonymous Coward (91.154.66.65) on

          > OpenBSD developers have a userland and a kernel that they review and maintain, OpenSSL was not a part of that until just recently

          Cool, but OpenSSL has been included in the base system for.. I can't remember, almost 15 years now?

          Not that I blame the OpenBSD developers for having stayed merge-compatible with upstream, and having assumed they know what they are doing. Because with most software (surprisingly, considering how much crap there is!) that seems to be a reasonable stance.

    4. By Rich (62.232.9.62) on

      I made a comment recently about the poor quality of the OpenSMTP code and was called a troll for doing so. I could also make the same comments about OpenSSL (have you seen the code - it's shocking) and the last time I looked at the pf code (forced on my at the time because the API to it was completely undocumented, and I'm guessing still is), it too was almost incomprehensible (very poorly commented, if at all, and generally a mess).

      The stock answer to pointing this situation out is, of course "stop complaining <expletive> and submit some code then". The thing is, it doesn't work like that. If I submitted (say) a tidy, clean SMTP server (or SSL library for that matter), are you seriously telling me that the main dev's would think "oh, ok then - let's throw the existing stuff away and use this version from this guy called Rich". Of course not. Life is not like that.

      Unfortunately, quality often comes a very poor second (20th?) place when it comes to most code, and nobody seems to care (as in zero interest) until things go so very very wrong as in the OpenSSL case.

      And I sort-of agree with the sentiment of the OP - if Theo KNEW that the OpenSSL code was crap then why the hell was OBSD still using it?

      Comments

      1. By Anonymous Coward (2003:56:2e28:6e00:fd41:2f0c:f911:9f92) on

        > Unfortunately, quality often comes a very poor second (20th?) place when it comes to most code, and nobody seems to care (as in zero interest) until things go so very very wrong as in the OpenSSL case.
        >
        > And I sort-of agree with the sentiment of the OP - if Theo KNEW that the OpenSSL code was crap then why the hell was OBSD still using it?

        There are probably a few factors which kept it in place. Firstly, it's widely used, which means that it's theoretically widely tested. Secondly, given the state of the code (even just formatting-wise), any efforts to address it, as the current LibreSSL fork demonstrates, is herculean. Essentially, OpenSSL was kept, in OpenBSD and elsewhere, due to a great deal of inertia.

        A tipping point was reached, and a concentrated effort is being made to audit the codebase. Starting from scratch, as the other various SSL libraries have done, means that you get to rediscover all the same bugs, and unless the API is kept compatible, results in even more work for the consumers of said API.

        Comments

        1. By Rich (62.232.9.62) on

          I hear what you are saying and I'm not disagreeing. But this situation must have been building for years (decades?), and is manifesting itself in exactly the same way in other well used lumps of code; not just those close to or in the OBSD project, but lots of external stuff too.

          Code does not get into such a mess overnight - it starts off that way and gradually decays as "stuff" is added to it over time. I have been writing (usually pretty complex embedded) stuff for 25+ years now; a lot of which has to run 24/7 and not fail - no option. Simple pride in my work stops me from producing crap. I'm not claiming to be super-human or anything because I'm not. But the stuff I write works, and the stuff I wrote 20 years ago STILL works. Writing maintainable, easily read and understood, documented code is not rocket science - it just needs a bit of self-worth and pride in what you do.

          Comments

          1. By Anonymous Coward (91.9.218.132) on

            > I hear what you are saying and I'm not disagreeing. But this situation must have been building for years (decades?), and is manifesting itself in exactly the same way in other well used lumps of code; not just those close to or in the OBSD project, but lots of external stuff too.
            >
            > Code does not get into such a mess overnight - it starts off that way and gradually decays as "stuff" is added to it over time. I have been writing (usually pretty complex embedded) stuff for 25+ years now; a lot of which has to run 24/7 and not fail - no option. Simple pride in my work stops me from producing crap. I'm not claiming to be super-human or anything because I'm not. But the stuff I write works, and the stuff I wrote 20 years ago STILL works. Writing maintainable, easily read and understood, documented code is not rocket science - it just needs a bit of self-worth and pride in what you do.

            And I really can't disagree with what you're saying; the problem is, that's not the mindset most coders have. They want whiz-bang stuff, and, to use a phrase I've become fond of, just cram their dick in it, without any pride of craftsmanship.

            I'd hate to sleep with most of these folks for that reason alone.

      2. By Anonymous Coward (216.16.224.222) on


        > And I sort-of agree with the sentiment of the OP - if Theo KNEW that the OpenSSL code was crap then why the hell was OBSD still using it?

        It was broken water heater in an apartment that precipitated (ha!) LibreSSL. Until then, the assumption was that upstream was sort of taking care of their own damn business, and, well, there is always more stuff to so over *there*.

        You ship with the bugs you know about, and the ones you don't. No exceptions, and no amount of pride in your work is ever going to change this mathematical certainty.

        A TLS library based on an emerging spec targeted at a variety of platforms and compilers is a terrible thing. Add to that the usual barnacles that any large project collects over the years (...decades), and you have The Situation.

        Software is bad for a lot of reasons, but it isn't bad just because coders are bad, stupid, or lazy. That may be a contributing factor as it always is, but what we have here is a typical social problem that expresses itself in a particular manner. It was the social and political decisions made by upstream that kill it.

        It just doesn't know its dead yet.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]