OpenSSL To Undergo Massive Security Audit
rjmarvin writes Now that its codebase is finally viewed as stable, OpenSSL is getting a good top-to-bottom once-over in the form of a sweeping audit. As part of the Linux Foundation's Core Infrastructure Initiative, the foundation and the Open Crypto Audit Project are sponsoring and organizing what may arguably be the highest-profile audit of a piece of open-source software in history. The audit itself will be conducted by the information assurance organization NCC Group, and its security research arm, Cryptography Services, will carry out the code review of OpenSSL's 447,247 line codebase over the next several months.
Code cannot be claimed to be secure unless it has been designed with secure design patterns - patterns for which there is an "assurance argument". If the code was "coded" instead of designed, then there is no hope of creating assurance arguments after the fact. In that case, the audit will be very difficult and untrustworthy.
A team with leadship in the realm of secure software already did that, starting about 11 months ago. The OpenSSL code didn't just need audited, it need large swaths of code thrown in the trash, and code refactored for security, readability, and ease of debugging. And fixes made. Which is being done. http://www.libressl.org/
Why bother with a security audit of the whole OpenSSL as-is, right here, right now, when the LibreSSL fork has been doing a lot of work
Presumably the audit was bid fixed-cost. Presumably these guys already built into the cost that they are going to build upon the work the LibreSSL team has done (it would be stupid not to).
LibreSSL is a great project, but they ripped out portability along the way. A fair argument can be made that it's easier to add portability back after all the crap is ripped out, but fixing OpenSSL and leaving portability intact is another valid strategy. That's far more work, but these guys were hired to do it (well,the first step of it) and somebody thinks it's valuable enough that they threw money at the problem.
There's plenty of appreciation to be spread around here for all the teams working to secure our communications.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
I don't think it is possible to secure 447,247 lines of code. I thought there was a chance before I saw that number.
Here's the best part: they can audit the security of nearly a half a million lines of code in "several months".
Oh, really? A trainwreck?
Explain this, then: [Source is here]
The following CVEs were fixed in earlier LibreSSL releases:
CVE-2015-0206 - Memory leak handling repeated DLTS records
CVE-2014-3510 - Flaw handling DTLS anonymous EC(DH) ciphersuites.
The following CVEs did not apply to LibreSSL:
CVE-2014-3571 - DTLS segmentation fault in dtls1_get_record
CVE-2014-3569 - no-ssl3 configuration sets method to NULL
CVE-2015-0204 - RSA silently downgrades to EXPORT_RSA
Let's see... 5 CVE were either fixed in LibreSSL or did not apply to it. That's not too bad for a "trainwreck".
And what about that little dig at NetBSD? Hmmmm... You mean some people take stuff from OpenBSD and make it less secure? The plot thickens.
Oh, and by the way, that OpenSSH thingie? Yup, it came from the last "open source" version of SSH, the commercial software. In other words, OpenBSD devs took something already existing and made it better. Hmmm... I think you just don't know what you are talking about...
Listen, you can find OpenBSD programmers annoying and even call them "masturbating monkeys", but they know their stuff. Period. Calling what they do a "trainwreck" is hyperbole at best and just plain untrue at worst.
This being said, to get back on topic, auditing OpenSSL is not a bad idea. Far from it.
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)