search

openssl / openssl

TLS/SSL and crypto library
https://www.openssl.org
Apache License 2.0
25.41k stars 10.05k forks source link

Improve overall OpenSSL library structure #13440

Open DDvO opened 3 years ago

DDvO commented 3 years ago

[This topic has been discussed to some extent already at various other occasions such as PR #4992. It is certainly not something to be tackled before the 3.0 release; I just file this as an issue in order to keep track.]

The OpenSSL code has essentially a three-level structure with a stack of two libraries and a command-line application at the top:

where the apps/ directory contains various potentially generally useful code for handling crypto-related files and messages, HTTP and TLS client/server and CA functionality, support for higher-level protocols like S/MIME, CRL fetching, OCSP, CMP, and certainly more to come. Meanwhile there is some form of internal library for that code in apps/lib/.

While this code serves as a model for using the crypto and ssl libraries and can be used in a limited way by invoking the openssl application(s) at CLI level, it cannot be re-used directly. Other applications that need similar functionality need to copy and generalize or re-implement portions of that code and then maintain it.

On the other hand, for historical reasons the crypto library contains some code that is actually too high-level there, for instance the HTTP client and OCSP and CMP client and server application logic (while low-level code such as OCSP and CMP ASN.1 structure handling likely needs to be done within the crypto lib since they make use of internal functions).

So it would be very helpful to introduce a further level in the hierarchy containing a more application-oriented library:

Then all more high-level and application support functionality can go there. This would make much of the generally useful code that so far resides in apps/ directly accessible to other applications at the programming level, i.e., in the form of a library/API, with all the re-usability advantages that this brings. It would also relieve libcrypto from more high-level (non-crypto) topics. This library would also form an ideal condensation point for further higher-level uses of crypto and TLS that may in the future get integrated with OpenSSL.

Of course, implementing this would be a major effort because it would require lots of re-structuring but also API design, implementation, and maintenance. On the other had, it should bring an enormous boost on the programming-level usability of OpenSSL.

richsalz commented 3 years ago

Other things to consider:

levitte commented 3 years ago

Re HTTP, OCSP, CMP et all, I always found I baffling that they all ended up in libcrypto. My perspective is that they implement diverse protocols, and should really have their own libraries, alongside libssl.

As for duplicating other APIs, I can't understand why. For example, if people prefer NaCl, then let them!

richsalz commented 3 years ago

You provide other API's so that folks don't have to go elsewhere and so that OpenSSL remains widely used as a crypto toolkit. Shrug if the project doesn't think that's important. But it's the same reason for the QUIC implementation.

DDvO commented 3 years ago

Good point @richsalz that there was already an issue for that, namely #6986, which I had forgotten about. Anyway l had slightly updated the proposal when filing this new one, where my aim was to convert PR #4992 into an issue. I've just set the triaged:feature label here since that was already present in the strongly related issue #6986.

pprindeville commented 2 years ago

Also implementing libx509 to handle various common PKI operations (OCSP lookups, certificate stapling, CSR generation, etc.).

nhorman commented 3 months ago

seems like this got lost/abandoned, seems like a fine idea, but something that needs a feature branch and alot of time to develop, which we don't really have for 4.0 at this point, unless someone is picking up the work.

marking as inactive, to be closed at the end of 3.4 dev, barring further input

pprindeville commented 3 months ago

It doesn't have to be monolithic. It's something that could be chipped away at a little bit at a time.

nhorman commented 3 months ago

Yes, I agree with that, but to seems the work of identifying what the pieces are here hasn't been done yet, and that seems a prerequisite to making forward progress.

@pprindeville are you interested in taking on that task? I'm happy to assign this to you as a community effort

nhorman commented 1 month ago

no response, marking as inactive

pprindeville commented 1 month ago

Actually I started the PR and it looks good, just wanted to check that I’ve not missed any places before submitting.

nhorman commented 1 month ago

oh, perfect, I'll assign this issue to you then, thank you!