8 ms·

I've done quite a bit of programming with the OpenSSL library and this article is only scratching the surface of the awfulness. Documentation is horrible to no

by agwa 13y ago

I've done quite a bit of programming with the OpenSSL library and this article is only scratching the surface of the awfulness. Documentation is horrible to non-existent, you really do need to go spelunking into the source to figure out how things work, and the code really is that horrible. The worst thing is that error reporting is not consistent - sometimes -1 means error, other times 0 means error, other times 0 means success, and sometimes it's a combination. This is really, really bad for a crypto library since properly detecting errors is usually critical to security.

conformal 13y ago
well, i appreciate mr dipropyl tryptamine having linked this. anyone who has looked at openssl source knows the score. to quote one of our devs (davec) on the topic of openssl: "funding openssl won't stop it from happening again... openssl is largely unmaintainable is the problem" the ifdefs alone in the source make it nigh unreadable, much less the inconsistent variable naming, inconsistent indentation/nesting and inconsistent overall style.
keule 13y ago
So I only have a basic/intermediate understanding of SSL and X509, but I am curious about your opinion: Is the awful code design just a flaw in that particular implementation, or are the standards involved so hard to implement correctly?
- rst 13y ago
  While the core parts of the crypto algorithms are, to some extent, intrinsically messy, that doesn't have much to do with the specific complaints here: inconsistent error return codes, pseudorandom indentation, #ifdef and if(0) stuff which deeply obscures control flow, and so forth. All of that is just bad style.
- agwa 13y ago
  I think it's largely a problem with OpenSSL itself. It's true that TLS and X.509 are quite complicated and I think it would be a challenge for anyone to implement them correctly, but that doesn't explain even half of OpenSSL's awfulness. Having consistent naming and error handling conventions should be possible regardless of how complicated the standards are. Plus, their crypto library is awful too, despite not having to deal with TLS or X.509.
- betterunix 13y ago
  OpenSSL is a mess on its own. Other libraries are better organized and better documented, so I doubt that it is the fault of TLS or x509.
- lmm 13y ago
  I understand that a lot of OpenSSL features were implemented by or because a company sponsored a specific feature, but was only interested in getting that specific feature done rather than any wholesale refactoring of the code. So it's had a bunch of different projects glommed onto it with no overall structure.
mrtksn 13y ago
O.K. This is probably a stupid question but if it was apparent to many that the code of OpenSSL was horrible why people kept using it and nobody tried to re-factor it? How it is possible that such a popular and critical piece of opensource software survived the years without a complete face-lift and nobody wrote thorogh documentation?
- betterunix 13y ago
  1. Other libraries do exist -- NSS, GnuTLS, etc. 2. Do you have time for a rewrite? What makes you think anyone else would? 3. The (generally correct) mindset is don't implement your own crypto. This is particularly true of something like TLS, which is complicated and has subtle requirements that are easy to screw up. Unfortunately, this means that even people who have time are discouraged from doing an OpenSSL rewrite.
  - deleted 13y ago
    [deleted]
  - mlieberman85 13y ago
    If there's alternatives then why do so many pieces of software (nginx, Apache, etc.) use OpenSSL as opposed one of these alternatives?
    - betterunix 13y ago
      Today there are alternatives. Once upon a time those alternatives were either not written, not stable, or not free. Now it is just a matter of convincing an enormous number of developers to carefully rewrite large parts of their systems to use a different library instead of new features (or ironically, security fixes).
    - awda 13y ago
      Historically, the alternatives are incomplete, solve only part of the problem, or are even worse (GnuTLS?).
    - 13y ago
yp_master 13y ago
Have you ever tried axssl or polarssl? I am just curious; I make no endorsement of either.
userbinator 13y ago
> you really do need to go spelunking into the source to figure out how things work What are the chances that this is how a lot of the vulnerabilities were discovered (including heartbleed)? The more people forced to look through the source, the better? (That is, unless they keep that discovery to themselves.) Edit: maybe they've improved it since the article was written; around 2 years ago I wrote an SSL MITM'ing HTTP(S) proxy, complete with CA certificate generation + signing, in a little over 24h of work.
stygiansonic 13y ago
Seems like GnuTLS suffers from the same inconsistent error reporting: http://blog.existentialize.com/the-story-of-the-gnutls-bug.html http://blog.existentialize.com/the-story-of-the-gnutls-bug.h...

by agwa 13y ago

conformal 13y ago

well, i appreciate mr dipropyl tryptamine having linked this. anyone who has looked at openssl source knows the score. to quote one of our devs (davec) on the topic of openssl: "funding openssl won't stop it from happening again... openssl is largely unmaintainable is the problem" the ifdefs alone in the source make it nigh unreadable, much less the inconsistent variable naming, inconsistent indentation/nesting and inconsistent overall style.

keule 13y ago

So I only have a basic/intermediate understanding of SSL and X509, but I am curious about your opinion: Is the awful code design just a flaw in that particular implementation, or are the standards involved so hard to implement correctly?

rst 13y ago
While the core parts of the crypto algorithms are, to some extent, intrinsically messy, that doesn't have much to do with the specific complaints here: inconsistent error return codes, pseudorandom indentation, #ifdef and if(0) stuff which deeply obscures control flow, and so forth. All of that is just bad style.
agwa 13y ago
I think it's largely a problem with OpenSSL itself. It's true that TLS and X.509 are quite complicated and I think it would be a challenge for anyone to implement them correctly, but that doesn't explain even half of OpenSSL's awfulness. Having consistent naming and error handling conventions should be possible regardless of how complicated the standards are. Plus, their crypto library is awful too, despite not having to deal with TLS or X.509.
betterunix 13y ago
OpenSSL is a mess on its own. Other libraries are better organized and better documented, so I doubt that it is the fault of TLS or x509.
lmm 13y ago
I understand that a lot of OpenSSL features were implemented by or because a company sponsored a specific feature, but was only interested in getting that specific feature done rather than any wholesale refactoring of the code. So it's had a bunch of different projects glommed onto it with no overall structure.

mrtksn 13y ago

O.K. This is probably a stupid question but if it was apparent to many that the code of OpenSSL was horrible why people kept using it and nobody tried to re-factor it? How it is possible that such a popular and critical piece of opensource software survived the years without a complete face-lift and nobody wrote thorogh documentation?

betterunix 13y ago
1. Other libraries do exist -- NSS, GnuTLS, etc. 2. Do you have time for a rewrite? What makes you think anyone else would? 3. The (generally correct) mindset is don't implement your own crypto. This is particularly true of something like TLS, which is complicated and has subtle requirements that are easy to screw up. Unfortunately, this means that even people who have time are discouraged from doing an OpenSSL rewrite.
- deleted 13y ago
  [deleted]
- mlieberman85 13y ago
  If there's alternatives then why do so many pieces of software (nginx, Apache, etc.) use OpenSSL as opposed one of these alternatives?
  - betterunix 13y ago
    Today there are alternatives. Once upon a time those alternatives were either not written, not stable, or not free. Now it is just a matter of convincing an enormous number of developers to carefully rewrite large parts of their systems to use a different library instead of new features (or ironically, security fixes).
  - awda 13y ago
    Historically, the alternatives are incomplete, solve only part of the problem, or are even worse (GnuTLS?).
  - 13y ago

yp_master 13y ago

Have you ever tried axssl or polarssl? I am just curious; I make no endorsement of either.

userbinator 13y ago

> you really do need to go spelunking into the source to figure out how things work What are the chances that this is how a lot of the vulnerabilities were discovered (including heartbleed)? The more people forced to look through the source, the better? (That is, unless they keep that discovery to themselves.) Edit: maybe they've improved it since the article was written; around 2 years ago I wrote an SSL MITM'ing HTTP(S) proxy, complete with CA certificate generation + signing, in a little over 24h of work.

stygiansonic 13y ago

Seems like GnuTLS suffers from the same inconsistent error reporting: http://blog.existentialize.com/the-story-of-the-gnutls-bug.html http://blog.existentialize.com/the-story-of-the-gnutls-bug.h...