Slashdot Mirror

← Back to Stories (view on slashdot.org)

OpenBSD Team Cleaning Up OpenSSL

Posted by timothy on from the devil-you-say dept.

First time accepted submitter Iarwain Ben-adar (2393286) writes "The OpenBSD has started a cleanup of their in-tree OpenSSL library. Improvements include removing "exploit mitigation countermeasures", fixing bugs, removal of questionable entropy additions, and many more. If you support the effort of these guys who are responsible for the venerable OpenSSH library, consider a donation to the OpenBSD Foundation. Maybe someday we'll see a 'portable' version of this new OpenSSL fork. Or not."

4 of 304 comments (clear)

  1. Re:Okay, Go! by Rigel47 · · Score: 5, Informative

    It's not a shameless plug. Theo has been openly critical of the OpenSSL team's development practices. By forking in-house he's essentially saying that they will put their proverbial money where their mouth is by doing their own development.

  2. "Please Put OpenSSL Out of Its Misery" by Anonymous Coward · · Score: 5, Informative

    We also have a comment from the FreeBSD developer Poul-Henning Kamp.

    He starts by saying "The OpenSSL software package is around 300,000 lines of code, which means there are probably around 299 bugs still there, now that the Heartbleed bug — which allowed pretty much anybody to retrieve internal state to which they should normally not have access — has been fixed." After that he notes that we need to ensure that the compiler correctly translates the high-level language to machine instructions. Later Kamp rants a bit about the craziness of CAs in general — would you trust "TÜRKTRUST BLG LETM VE BLM GÜVENL HZMETLER A.."? Then he lists some bullet points about things that are wrong in OpenSSL:

    - The code is a mess
    - Documentation is misleading
    - The defaults are deceptive
    - No central architectural authority
    - 6,740 goto statements
    - Inline assembly code
    - Multiple different coding styles
    - Obscure use of macro preprocessors
    - Inconsistent naming conventions
    - Far too many selections and options
    - Unexplained dead code
    - Misleading and incoherent comments

    "And it's nobody's fault. No one was ever truly in charge of OpenSSL, it just sort of became the default landfill for prototypes of cryptographic inventions, and since it had everything cryptographic under the sun (somewhere , if you could find out how to use it), it also became the default source of cryptographic functionality. [...] We need a well-designed API, as simple as possible to make it hard for people to use it incorrectly. And we need multiple independent quality implementations of that API, so that if one turns out to be crap, people can switch to a better one in a matter of hours."

    1. Re:"Please Put OpenSSL Out of Its Misery" by Anonymous Coward · · Score: 5, Informative

      I agree that the OpenSSL code base is very bad. (I was doing some work based on modifying the library recently and I had to hold my nose.) However, I take objection with some of this:

      - 6,740 goto statements

      Otherwise known as "the only sane way to simulate exceptions in C". Seriously. Read up on how "goto" is used in low-level code bases such as OS kernels, instead of citing some vague memory of a 1960s paper without understanding its criticisms.

      - Inline assembly code

      Otherwise known as "making the thing go fast". Yes, I want the bignum library, or hashing algorithms, to use assembly. Things like SIMD make these tasks really effing fast and that is a good thing...

  3. Re:de Raadt by EvanED · · Score: 5, Informative

    The freelist is not an "exploit mitigation countermeasure",...

    He was being somewhat sarcastic, because OpenBSD's allocator is in contrast to

    Read overflows don't kill canaries, so you wouldn't detect it except for with an unmapped page--a phenomena that doesn't happen with individual allocations smaller than 128KB in an allocator that uses brk(), like the default allocator on Linux and FreeBSD

    and does try to separate allocations specifically to mitigate Heartbleed-style vulnerabilities.

    In other words, the OpenBSD allocatior does have exploit mitigation, and the OpenSSL freelist acts as a countermeasure to those mitigation capabilities whether it was intended or not.

    The comment even says that it's done because performance on allocators is slow.

    It says it's slow on "some platforms", yet they disabled it on all and then didn't test the alternative.

    But of course everyone knows it's way better to quickly implement a dramatically awful security vulnerability than to do things slowly and correctly.