Vulnerabilities in OpenSSL's cryptographic functions?

[NotATether]

I have heard that the implementation of OpenSSL's cryptographic algorithms is very messy and consequentially they should be treated as not secure since people can hardly read it.

i believe you are referring to usage of OpenSSL library in early versions of bitcoin core by Satoshi. i wouldn't call replacing that with a self written code "reinventing the wheel". in fact using OpenSSL is the source of some of the mess we have in bitcoin's code for example involving signatures and their encoding, the implementation both prevents bugs coming from that library and improves speed.

right. From what I have read, using the OpenSSL library is a risky proposition for software that actually requires a high standard of cryptographic security, as the code is incredibly difficult to review. I am a little surprised that less was made of the multiple serious vulnerabilities found in OpenSSL throughout the mid 2010's (I've replaced it with LibreSSL where I can easily do so)

I'm fairly well convinced these days that where cryptography is well specified/defined, and the new code has good reviewers, that re-implementing some algorithms to replace known-bad implementations is better than using those known-bad implementations.

What makes alternative cryptography libraries more readable and thus have more eyes detecting and squashing security bugs? And what kind of OpenSSL vulnerabilities are obscured by poorly written code? In other words, what is the security advantage of using another SSL library over OpenSSL?

[pooya87]

did you read replies posted by @gmaxwell in that topic?

[NotATether]

did you read replies posted by @gmaxwell in that topic?

Yes I did but I want to know if altrenate SSL implementations (referring to LibreSSL and BoringSSL specifically) have better ASN.1 parsers. That was what I was referring to.

All types of parsers are inherently difficult to  write securely since you primarily read arbitrary user input. And there could be surprise behavior when reading edge cases of input because usually these are not throroughly tested. For example here's a memory corruption bug in OpenSSL's ASN.1's parser from 2003: https://www.openssl.org/news/secadv/20030930.txt

And here's a memory leak from 2016: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2109

Some more memory corruption vulnerabilities:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2108
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0739

There are probably more vulnerabilities in OpenSSL's parser that we don't about yet.

So I think that for parsers, better code readability, especially for the people most responsible for maintaining it, can help avoid these types of bugs in the first place.

Because it's unlikely OpenSSL would accept a restructuring of its ASN.1 parser I was hoping that forks would do that.

I hope my question is more clear.

[pooya87]

i don't think there is any way of eliminating these types of bugs from OpenSSL or any other library for that matter. better readability and overall a better code and more importantly better tests would reduce the chances of such bugs but they will always happen nonetheless.
at this point i don't think anything about OpenSSL regarding its readability and its parsers can change because it would require a big refactoring which is tedious work and there isn't enough incentive to do it.

[Carlton Banks]

I have heard that the implementation of OpenSSL's cryptographic algorithms is very messy and consequentially they should be treated as not secure since people can hardly read it.

I heard that too, and you heard it from me:

i believe you are referring to usage of OpenSSL library in early versions of bitcoin core by Satoshi. i wouldn't call replacing that with a self written code "reinventing the wheel". in fact using OpenSSL is the source of some of the mess we have in bitcoin's code for example involving signatures and their encoding, the implementation both prevents bugs coming from that library and improves speed.

right. From what I have read, using the OpenSSL library is a risky proposition for software that actually requires a high standard of cryptographic security, as the code is incredibly difficult to review. I am a little surprised that less was made of the multiple serious vulnerabilities found in OpenSSL throughout the mid 2010's (I've replaced it with LibreSSL where I can easily do so)

I'm fairly well convinced these days that where cryptography is well specified/defined, and the new code has good reviewers, that re-implementing some algorithms to replace known-bad implementations is better than using those known-bad implementations.

but I also made it more explicit in next reply that I haven't read the OpenSSL code to confirm this:

review of the OpenSSL codebase hasn't always been easy (apparently, I have not tried to read the code myself).

gmaxwell's reply was definitely useful, he has way, way more experience/aptitude with making judgements about these things.


To clarify further, I'm using LibreSSL in place of OpenSSL where that option is easy for me (on Gentoo linux). But I have other computers running either Debian and Fedora, where OpenSSL is installed.