[cryptography] anyone got a "how not to use OpenSSL" list?

Stephen Farrell stephen.farrell at cs.tcd.ie
Thu Oct 11 06:34:47 EDT 2012

One I've seen in deployed code with Java crypto but might
also happen with openssl is use of PBKDF when the secret is
only used locally (e.g. to MAC/encrypt a cookie) and doesn't
even need to be a user memorable string. That's a great way
to consume CPU uselessly and was probably caused because
the developer saw there was an API that took a string as
input for a secret.


On 10/11/2012 11:02 AM, Ryan Sleevi wrote:
> On Wed, October 10, 2012 10:34 am,
> travis+ml-rbcryptography at subspacefield.org wrote:
>>  I want to find common improper usages of OpenSSL library for SSL/TLS.
>>  Can be reverse-engineered from a "how to properly use OpenSSL" FAQ,
>>  probably, but would prefer information to the first point rather than
>>  its complement.
>>  --
> Depends on what you mean by improper - improper in that it introduces
> security-relevant issues, or just general improper cargo-cult usage of
> OpenSSL that leads to buggy behaviour.
> Here's a quick list off the top of my head from having poked around
> various languages' bindings (Python, Perl, PHP, etc), from having seen
> various "rebranded" OpenSSL-using products, and from various "I just want
> to do HTTPS"
> 1) Assuming that an ASN1_STRING contains a null-terminated string - eg:
> using ASN1_STRING_data directly, without checking ASN1_STRING_length as
> well. Moxie's embedded NULL in the CN (BlackHat 09) trick was enough to
> get most popular language bindings to check the length, but a depressing
> number of samples and third-party libraries continue to assume
> ASN1_STRING_data == C string.
> 2) Assume that OpenSSL performs RFC 2818/6125 name validation, and thus
> fail to implement it themselves. As a result of no name checking,
> www.paypal.com can be trivially redirected to www.evil.com as long as it
> chains to a configured trust anchor. OpenSSL 1.1.0 (not yet released)
> finally adds some helpers for this, but otherwise everyone has been left
> implementing their own - if at all (generally, not at all).
> 3) Using the Mozilla Root Certificate data (
> http://mxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt?raw=1
> ) and directly exporting all the certificates, without considering the
> trust bits. You know, the bits in NSS that says "In no circumstances
> should you ever, ever trust this certificate?", which authors and
> libraries happily interpret as "I can totally trust this certificate!" Be
> smart, use something like https://github.com/agl/extract-nss-root-certs
> 4) Back on the topic of validation, assume that OpenSSL "out of the box"
> is performing RFC 3280/5280 validation, or, in a similar token, that the
> results are equivalent to what a browser would give when using HTTPS. This
> ranges from online revocation checking to trust anchor equivalence to
> assuming that OpenSSL supports multiple certification paths. You could
> argue that this is not an improper usage in itself, just a
> misunderstanding, but I'd argue that using OpenSSL with the assumption
> it's going to do all the 'magic' for you is still a bug.
> 5) Failure to properly handle results from functions.
> eg: EVP_VerifyFinal returns 1 on success, 0 on failure, -1 on fatal error.
> However, code may check "if (EVP_VerifyFinal(...))" / "if
> (!EVP_VerifyFinal(...))" . Even OpenSSL itself was guilty of this.
> 6) While not quite a security failure, many distros still ship OpenSSL
> with defaults to PrintableString-or-BMPString (or worse, TeletexString)
> for string encodings for certificates, requests, etc, rather than using
> UTF8String. This, despite the recommendations from RFC 3280 to use
> UTF8String for the past decade.
> 7) When using the SSL/TLS layer, failing to handle empty fragments or
> split records (eg: as done by BEAST). Generally, this can be summed as the
> assumption that SSL_read will return "all" of the data in a single call.
> 8) Assuming that an ASN1_TIME can always be represented by a time_t - or
> converting to a time_t to perform comparisons. This really comes up on
> 32-bit systems that suffer from the Y2038 bug. OpenSSL 1.0.0 added a set
> of useful helper functions, but still a number of codebasis exist that
> presume somebody out there wants to compile with OpenSSL 0.9.6/0.9.7, and
> so they have all sorts of crazy bugs.
> 10) SSL_OP_NO_SSLv2 (or more specifically, the lack of it)
> 11) Generating new DH parameters every time tmp_dh_callback is called (And
> then complaining that "SSL is slow")
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography

More information about the cryptography mailing list