<font face="arial" size="2"><p style="margin:0;padding:0;">I'm afraid it's not *just* underfunded.   I reviewed the details of the code involved and the fixes, and my conclusion is that even programmers of security software have not learned how to think about design, testing, etc.  Especially the continuing use of C in a large shared process address space for writing protocols that are by definition in the "security kernel" (according to the original definition) of applications on which the public depends.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">Ever since I was part of the Multics Security Project (which was part of the effort that produced the Orange Book http://csrc.nist.gov/publications/history/dod85.pdf) in the 80's, we've known that security-based code should not be exposed to user code and vice versa.  Yet the SSL libraries are linked in, in userspace, with the application code.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">Also, upgrades/changes to protocols related to security (which always should have been in place on every end-to-end connection) should be reviewed *both at the protocol design level* and also at the *implementation level* because change creates risk.  They should not be adopted blindly without serious examination and pen-testing, yet this change just was casually thrown in in a patch release.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">I suspect that even if it were well funded, the folks who deploy the technology would be slapdash at best. Remember the Y2K issue and the cost of lazy thinking about dates. (I feel a little superior because in 1968 Multics standardized on a 72-bit hardware microsecond-resolution hardware clock because the designers actually thought about long-lived systems (actually only 56 bits of the original clock worked, but the hardware was not expected to last until the remaining bits could be added)).</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">The open source movement, unfortunately, made a monoculture of the SSL source code, so it's much more dangerous and the vulnerable attack surface of deployments is enormous.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">Rant off.  The summary is that good engineering is not applied where it must be for the public interest.  That remains true even if the NSA actually snuck this code into the SSL implementation.</p>
<!--WM_COMPOSE_SIGNATURE_START--><!--WM_COMPOSE_SIGNATURE_END-->
<p style="margin:0;padding:0;"><br /><br />On Friday, April 11, 2014 2:22pm, "Dave Taht" <dave.taht@gmail.com> said:<br /><br /></p>
<div id="SafeStyles1397244434">
<p style="margin:0;padding:0;">> http://www.wired.com/2014/04/heartbleedslesson/<br />> <br />> And Dan Kaminisky writes about "Code in the Age of Cholera"<br />> <br />> http://dankaminsky.com/2014/04/10/heartbleed/<br />> <br />> <br />> <br />> --<br />> Dave Täht<br />> _______________________________________________<br />> Cerowrt-devel mailing list<br />> Cerowrt-devel@lists.bufferbloat.net<br />> https://lists.bufferbloat.net/listinfo/cerowrt-devel<br />></p>
</div></font>