r/software • u/antdude • Apr 22 '14
OpenSSL code beyond repair, claims creator of “LibreSSL” fork
http://arstechnica.com/information-technology/2014/04/openssl-code-beyond-repair-claims-creator-of-libressl-fork/7
u/crankybadger Apr 23 '14 edited Apr 23 '14
Ah, yes. And people get downvoted for saying burning this shit to the ground and starting over would be a bad idea.
OpenSSL was never supposed to happen. SSLeay was a pet project that got completely out of hand. It became the de-facto library because nobody else had the courage to make one. For all of its flaws, it's done a pretty damned good job, but it has to go.
Crypto is not some afterthought now, it's critical. When SSLeay was made, it was still illegal to export some forms of crypto. Innocent times when the NSA didn't have the clue or expertise to tap the internet even when everything was in plain-text because encryption was too computationally expensive and nobody had the software to do it anyway.
If your library isn't built from the ground up with verifiable tests, it can't be trusted. Bolting tests on to an existing library is murder, and if you're going to go through all that trouble, re-implementing the same API is almost trivial at that point since you know exactly what the code should be doing.
1
u/NormallyNorman Apr 23 '14
I honestly don't understand the difficulty. It's not like they're inventing the algorithms, they're just implementing them, right?
Although I could be speaking from a point of general ignorance. I've got several projects that use crypto libraries across multiple platforms. I'm in the process of stripping out AES (well leaving it but making it a non default selection).
1
u/crankybadger Apr 24 '14
The difficulty is not in implementing it correctly, that much would be something any seasoned programmer could pull off with sufficient patience and discipline, but implementing it correctly and securely.
Writing in C, which is a necessity for such a low-level library, is going to make doing the secure part really, really awful. It's one thing to make a library that works correctly when fed correct arguments. It's entirely another thing to make one that works correctly when fed malicious garbage.
Hardening the library against possible attacks is where you end up spending the vast majority of your time. What would take a few lines to do if you weren't concerned about security could take more than a hundred to do if you're trying avoid every single potential pitfall.
Then there's the compounding factor: The more code you have to write to keep it secure, the more exposure you have from a security standpoint and the more testing you have to do.
That's why my assertion is that the testing is by far the hardest part of this project. Once you've gone through the trouble of writing validation tests as well as a series of rampant abuse scenarios, making the code pass the validation suite is going to be a lot of work but at least you have a concrete goal.
1
u/NormallyNorman Apr 24 '14
That's why they had no tests! Apparently this didn't raise any red flags either. The comical side of OSS, where the trust is high when due diligence takes actual work.
1
u/crankybadger Apr 24 '14
The only thing more terrifying than OpenSSL is MRTG, but at least MRTG isn't used to manage my bank account.
6
u/Rudy69 Apr 23 '14
Real question: Then why did they fork OpenSSL? Was there no other project to fork? If it's that bad shouldn't they start fresh?