openssl: Missing struct field access or object access methods

Porting my v1.0.x OpenSSL code to v1.1.x, I was able to replace most ssl or ctx pointer field access with the new available functions, methods or “accessors.”

However, when it came to X509_LOOKUP_METHOD, I had to create an internal header similar to what was done for “include\internal\bio.h” So now I have a “include\internal\x509_lookup.h” header.

I have a set of virtual BIO I/O methods for our RPC client/server platform. The RPC clients can access the “wc:\ssl” files. Our “wcBIO” functions will use our wcSDK/API if a file has a "wc:" prefix and so on. I was able to recompile the BIO_METHOD by reference “internal\bio.h” in my code.

Well, I needed to repeat this with the X509_LOOKUP_METHOD struct using the wcBIO functions by creating include\internal\x509_lookup.h:

// Created SSI.HLS 03/23/19 11:44 am
// Support wcBIO/wcX509 functions

#include <openssl/x509.h>

struct x509_lookup_method_st {
    char *name;
    int (*new_item) (X509_LOOKUP *ctx);
    void (*free) (X509_LOOKUP *ctx);
    int (*init) (X509_LOOKUP *ctx);
    int (*shutdown) (X509_LOOKUP *ctx);
    int (*ctrl) (X509_LOOKUP *ctx, int cmd, const char *argc, long argl,
                 char **ret);
    int (*get_by_subject) (X509_LOOKUP *ctx, X509_LOOKUP_TYPE type,
                           X509_NAME *name, X509_OBJECT *ret);
    int (*get_by_issuer_serial) (X509_LOOKUP *ctx, X509_LOOKUP_TYPE type,
                                 X509_NAME *name, ASN1_INTEGER *serial,
                                 X509_OBJECT *ret);
    int (*get_by_fingerprint) (X509_LOOKUP *ctx, X509_LOOKUP_TYPE type,
                               const unsigned char *bytes, int len,
                               X509_OBJECT *ret);
    int (*get_by_alias) (X509_LOOKUP *ctx, X509_LOOKUP_TYPE type,
                         const char *str, int len, X509_OBJECT *ret);
};

/* This is the functions plus an instance of the local variables. */
struct x509_lookup_st {
    int init;                   /* have we been started */
    int skip;                   /* don't use us. */
    X509_LOOKUP_METHOD *method; /* the functions */
    void *method_data;          /* method data */
    X509_STORE *store_ctx;      /* who owns us */
};

And this worked to get pass the initial X509_LOOKUP_METHOD setup compilation, but moving along, I now come across the need to access the SSL_CTX to access the “ctx->cert_store” field.

Before creating a “include\internal\ssl.h”, I decided to stop here because I have to be missing something. Did this fall under the proverbial crack? It is hard to imagine that such 1.0.x compatibility has been lost and the need to add “internal” headers to fix “things.” Its getting kind of “kludgy” even with the new Openssl v1.1 model.

I must be missing something with the BIO_METHOD and X509_LOOKUP_METHOD functionality to create your own private set of BIO/X509 I/O virtual functions.

Thanks for any input you can provide

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 18 (9 by maintainers)

Commits related to this issue

meson: Skip opusfile with OpenSSL 1.1.x See: - https://github.com/openssl/openssl/issues/8562 - https://github.com/microsoft/vcpkg/issues/29582 — committed to dragonCodecs/opusfile by amyspark a year ago

Most upvoted comments

Overall, IMO, the goal should be compatibility with a clean port, no need for kludges, etc. I will venture OpenSSL has not even touch based with the majority of legacy and established OpenSSL implementors who are not keen with a major change idea when there was really no need for it for a stable production system . TLS v1.3 is the most important only real business reason. But with a major API change, Open v1.1.1 need to be stabilized for portability asap.

I can understand your frustration seeing how you are struggling with the conversion from 1.0.2 to 1.1.1, (#8551, #8556, #8575, #8577). But this does not justify your ranting against the community, here in this thread and in https://github.com/openssl/openssl/issues/8577#issuecomment-476445280.

After all, that’s what Open Source is about: You are free to take it and use it, and nobody requires you to pay money for it. But you can’t just use it for 20+ years without participating or contributing anything to the community and then demand that the software meets all your requirements and needs. And with “contributing” I don’t even mean writing some code, but just to speak up and share your needs and opinions. Why doesn’t OpenSSL have these compatibility wrappers for 1.0.2 you are missing? Because nobody took the time and went through the effort to implement and share them. Where were you when the job needed to be done? Whom do you intend to blame?

Implementors only have 5-6 months for conversion and foremost, testing. Openssl may have a conflict holding to its EOL 2019 goal for v1.0.x.

Sorry to say it, but you are very late to the game. OpenSSL 1.1.0, which introduced the opaque structures, was released in August 2016 which is a lot more than 5-6 months ago. If you are now running out of time because of the EOL for 1.0.2 you should probably blame yourself.

And finally, in reply to https://github.com/openssl/openssl/issues/8577#issuecomment-476445280:

20 years? Openssl is about that old.

It was used to import IIS Cert/Keys when customers (of all scales; hobbyist, small biz to enterprise) switch from IIS to our Wildcat! platform … You can’t make decisions like this for folks like this by pulling stuff out especially after 20 years without a workaround or perhaps by moving the code to a legacy set of API that is still part of the package. Something, you just don’t pull code like this… That’s not cool.

Sometimes it is necessary to cut off old braids, because a lot of the 20+ year old cryptography (not everything, fortunately) has become hopelessly insecure. Reading the Wikipedia article pointed out by @mlindner I see that SGC became obsolete at the beginning of the millennium.

Internet Explorer supported SGC starting with patched versions of Internet Explorer 3. SGC became obsolete when Internet Explorer 5.01 SP1 and Internet Explorer 5.5 started supporting strong encryption without the need for a separate high encryption pack (except on Windows 2000, which needs its own high encryption pack that was included in Service Pack 2 and later).[3]

The support for RSA_NET was removed in commit 0bc2f365558ed5980ce87d6b2704ca8649ca2a4a in 2015. Where were you in all these years to report it missing? Everybody would have told you that it does not make sense to support obsolete and insecure cryptography forever. You shouldn’t add it back into the upcoming release of your software. (After all, it’s Open Source; nobody prevents you from adding it back in from 1.0.2.) Everybody still using IE 5 will probably also be still using a 20+ year old version of your Wildcat software, so he won’t be affected by this incompatibility anyway. But he will certainly have severe security issues.

mspncp on Mar 26, 2019