Support OpenSSL Providers #13115
Support OpenSSL Providers #13115
Conversation
|
Thanks for this PR, however it's not going to be possible to accept in this form. First, our usage of cffi is long-term deprecated, and thus we're not adding any new bindings. However, more fundamentally we think that the providers APIs in OpenSSL are mis-designed and thus any APIs that we want to expose really need to be more generic ways for interacting with keys that don't live in memory. If you're interested in this area, I'd encourage you to file an issue and start a discussion, because this is a big area. |
|
@alex I'd be interested in helping. I have a decent amount of experience with pkcs11 which seems to probably be the most broad and best supported standard for mediating this kind of indirect access. I understand that pyca/cryptography is much broader than just integrating with OpenSSL, but it does seem odd that all of the FFI bindings is in this project for pyopenSSL, a project which is specifically a wrapper around OpenSSL. So to me it seems perfectly fair to say that this doesn't belong in THIS project, but to say it doesn't belong is pyOpenSSL does seem pretty confusing to me, though I get the two seem pretty well intertwined now it leaves me to wonder what pyopenSSL is intended for if it's just never going to expose any new APIs from the library is wraps. So to some extent this is just frustrating, because yes I understand that you might have different designs intentions, but that's now limiting the ability to really support a wide range of OpenSSL functionality in the pyOpenSSL project. From a pragmatic standpoint, OpenSSL has this and it works, and I'd like to just use it as is. It would be nice if pyopenSSL could implement this and this project could solve the problem in a way it finds more suitable. Alas, apparently that cannot be done. Is there conversation on removing this as a dependency or pyopenssl if this project is deprecating CFFI bindings? Or does everything now need to move through rust and 2 separate compiler tool chains just to land in pyopenssl? |
|
Our current focus is on deprecating legacy APIs in pyOpenSSL (pyca/pyopenssl#1321), removing unsafe behaviors (pyca/pyopenssl#1429), and then we intend to migrate pyopenssl to Rust for maintainability (#12378). |
|
@alex would the goal be to support something like PKCS#11 in a way that does not really on OpenSSL at all? Or to just abstract some kind of OpenSSL provider interactions? Is PKCS#11 support in line with the overall design goal? Or would it be some broader support akin to OpenSSL providers? I'm not really sure what kind of ticket to open or what kind of conversation to start. It seems like there's a lot of design goals that I'm not exactly clued into or have any real strong opinions on. |
|
From my perspective there's two reasonable directions: 1) is PKCS#11
support, 2) is extending pyOpenSSL to support the cryptography key
interfaces
https://cryptography.io/en/latest/hazmat/primitives/asymmetric/cloudhsm/
…On Thu, Jun 26, 2025 at 10:37 PM Travis Sturzl ***@***.***> wrote:
*tsturzl* left a comment (pyca/cryptography#13115)
<#13115 (comment)>
@alex <https://github.com/alex> would the goal be to support something
like PKCS#11 in a way that does not really on OpenSSL at all? Or to just
abstract some kind of OpenSSL provider interactions? Is PKCS#11 support in
line with the overall design goal? Or would it be some broader support akin
to OpenSSL providers? I'm not really sure what kind of ticket to open or
what kind of conversation to start. It seems like there's a lot of design
goals that I'm not exactly clued into or have any real strong opinions on.
—
Reply to this email directly, view it on GitHub
<#13115 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAAGBG2HIMEO6FRUP3HA5D3FTKCXAVCNFSM6AAAAACAHN3FRGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMJRG4ZTOMRRGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
All that is necessary for evil to succeed is for good people to do nothing.
|
We've been trying to use pyOpenSSL to leverage private keys stored in a TPM or PKCS#11 store, however this project doesn't currently support the ability to load a provider. To load a provider you must create an
OSSL_LIB_CTXwhich can then be used withOSSL_PROVIDER_load. Once you have theOSSL_LIB_CTXwith the provider loaded in, you can then pass that context intoSSL_CTX_new_exto create an SSL Context with that provider, and you can also load objects with the provider using the OSSL_STORE API using theOSSL_STORE_open_exfunction.I've only added in functions that are available in OpenSSL 3.0 to keep support simple, as that seems to be the minimally supported version for this project. My hope is that by adding this support that I can implement some basic provider support in pyOpenSSL, which can then be used to establish TLS connections utilizing HMS/TPM secured keys and certificates.
I've tested manually, but if you'd like I can add some basic unit tests it just doesn't seem like many of these CFFI bindings currently are being tested.