Slashdot Mirror


Theo De Raadt's Small Rant On OpenSSL

New submitter raides (881987) writes "Theo De Raadt has been on a better roll as of late. Since his rant about FreeBSD playing catch up, he has something to say about OpenSSL. It is worth the 5 second read because it is how a few thousand of us feel about the whole thing and the stupidity that caused this panic." Update: 04/10 15:20 GMT by U L : Reader badger.foo pointed out Ted Unangst (the Ted in the mailing list post) wrote two posts on the issue: "heartbleed vs malloc.conf and "analysis of openssl freelist reuse" for those seeking more detail.

6 of 301 comments (clear)

  1. Summary for the lazy ones by Anonymous Coward · · Score: 5, Informative

    Years ago the BSD guys added safeguards to malloc and mmap, but they were disabled for all platforms in OpenSSL only because they caused performance problems on some platforms. He finishes by saying that OpenSSL is not developed by a responsible team.

  2. More commentary from OpenBSD's Ted Unangst by badger.foo · · Score: 5, Informative
    OpenBSD developer Ted Unangst (mentioned in the article) has gone into the code a bit more in two articles, both very well worth reading:

    heartbleed vs malloc.conf

    and

    analysis of openssl freelist reuse. Short articles with a lot of good information.

    --
    -- That grumpy BSD guy - http://bsdly.blogspot.com/
  3. Re:"It's Not a Tumor" - Oh Wait, It Is by Anonymous Coward · · Score: 5, Informative

    It is good practice to sign against an intermediate certificate. That way if it is compromised you can reject it and issue a new intermediate certificate signed by your root certificate. You can push the new certificates as updates since they would be validated against the root certificate.

    You need to read up on authenticating the entire chain of certificates.

  4. Re:"It's Not a Tumor" - Oh Wait, It Is by Anonymous Coward · · Score: 5, Informative

    I don't get what you're saying, and I think that's probably because you don't know what you're talking about. Having certificate chains is only a plus, the flat structure was crap. Here's how it works:

    I have a root certificate that's universally trusted. It is used *only* to sign intermediate certificates. Having the public cert in the public is fine since it only contains the public key part of the asymmetric public/private key pair. The private key, sits on a server which is physically isolated from the world. By that, I mean that the root certificate and private keys are literally on servers with *no* network connections. When you want to generate a new intermediate certificate, you put the CSR on a USB stick, plug it in, and sign it from that machine. In this way you never have to worry about external threats potentially gaining access to your private key (internal are an ever constant threat, and you put in good safeguards to prevent against that).

    Now that you have a chained hierarchy, you can use different intermediates to sign different end user certificates. Remember that both the root and intermediate have their own certificate revocation lists: the root can revoke intermediates (which means anything signed by them is null and void) and intermediates can revoke server or subordinate intermediate certs.

    As a result of my chained hierarchy, if an intermediate is compromised, I can revoke it, without revoking every single end user / server certificate out there. This gives me finer grained control.

    Now, I said that the root isn't even connected to the internet. The intermediate ideally is not either. Ideally the user / server signing intermediate is behind a set of firewalls, and *pulls* signing requests from frontends, that it then processes and posts the resulting signed certs to. That way if you compromise the front end, you have to the compromise the firewall (which ideally is blocking all inbound connection requests / unconnected sockets / anything that is not communication required for the intermediate server(s) to send pulls to the frontends) in order to get to the intermediate.

    Your flat view of the world is draconian, wrong, uneducated, and probably hurts everyone who reads it by making them a little less educated.

  5. Re:not developed by a responsible team? by Eunuchswear · · Score: 5, Informative

    Oh, and read this: http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse

    In effect at some points OpenSSL does:


            free (rec); ...
            rec = malloc (...);

    and assumes that rec is the same.

    Eeew,

    --
    Watch this Heartland Institute video
  6. Re:not developed by a responsible team? by EvanED · · Score: 5, Informative

    Theo's "rant" isn't brought about by a typical bug in the sense of a mistake in the code. His rant is brought about by the fact that OpenSSL deliberately introduced wrapper functions for malloc/free, making it impossible for a system to provide hardened ones, then made those wrappers default. He further rants about the fact that, because it's default, they later introduced a bug that means you can't turn the wrappers off.

    The heartbeat bug itself was a mistake and a bug in the traditional sense. The "hey let's replace malloc/free" is much closer to "bad decision" than "mistake."