Lessons from the Debian/OpenSSL Fiasco (2008)

I recently spend some time looking into this bug again, because I develop a tool to detect known cryptographic vulnerabilities in public keys called badkeys - <a href="https:&#x2F;&#x2F;badkeys.info&#x2F;" rel="nofollow">https:&#x2F;&#x2F;badkeys.info&#x2F;</a> if you&#x27;re interested.<p>Some notable things I learned:<p>* This affects both OpenSSL and OpenSSH, but the keys are different. I.e. you have a set of vulnerable OpenSSH keys and a set of vulnerable OpenSSL keys. But the key format is the same, yet most of the tools to detect just look for either of these. I found a TLS certificate created with a vulnerable key generated by OpenSSH.<p>* It was &quot;conventional wisdom&quot; that ECDSA was unaffected because some sources said that OpenSSL version did not support ECDSA. However that was wrong, you can generate ECDSA keys with that old version.<p>Generally it seems a lot of the detection tools are incomplete. E.g. github seems to block some vulnerable keys, but only a subset.

Every time this gets brought up, people forget that the patch had been sent to the openssl mailing list and someone said that it looked fine.<p>But here we have all the proponents of &quot;distributions should never do any patch (and thus leave all the security issues open)&quot;. But they live in a fantasy world where all upstream authors reply within 3 minutes, fix issues within 30 minutes and of course backport the fix.

Discussed at the time:<p><i>Lessons from the Debian&#x2F;OpenSSL Fiasco</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=196035" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=196035</a> - May 2008 (2 comments)

&gt; Try not to write clever code. Try to write well-organized code.<p>Decades ago someone wrote an empty loop to do &quot;something&quot; and it looped for a fixed number of times. No one knew why. But seemed that loop depended upon the frequency of the CPU. It was kind of a sleep (I forgot most of the details) that was needed for some reason. When the system was upgraded, things stated breaking.<p>That statement should be a tattoo on everyone&#x27;s hand :)

I looked at the list of take-aways and one big important take away was missing. Testing. If a SSL depends on generating millions of unique keys then there should be an existing test somewhere the ensures that SSL does this before the release into production. The test would have caught the initialization and send the code back for re-work, clarification.

I don&#x27;t quite understand why would Debian keep their own forks of software and don&#x27;t even attempt to upstream the changes. Is it just security backports to ensure &quot;stability&quot; by not actually updating the packages, or do they have other reasons for the changes?

Wonder if any of the lessons got learned? We, as an industry, are absolutely terrible at this, but hope springs eternal...