New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement #48073
Comments
SSLSocket() and ssl.wrap_socket() accept private keys only as paths to In other words, the new ssl module's API prevents its use in servers If SSLSocket() and ssl.wrap_socket() were updated to accept private keys |
This problem also exists in the add-on ssl module for python < 2.6: |
I've dug around in the code a bit and the keyfile, certfile and ca_certs The options I see are:
The current situation in _ssl.c:
One could use SSL_CTX_set_cert_store(...) to register callbacks (and All this comes with the proviso that I just started digging into the I can probably find time to create a patch with tests once we have a @forest: If you have an details on how non-Python servers go about |
Thanks, Simon. I remember digging through all this last year, and finally deciding It almost sounds like we'd need to create Key and Certificate objects |
Both M2Crypto and pyOpenSSL expose certificate and key objects and have |
Sure -- but the point of the SSL module was to do something |
I'm just suggesting that if the ssl module *is* going to gain |
Simon: I wish I could offer guidance here, but I'm afraid that I too am I agree that writing to a temporary file would be bad. Accepting file-like objects from python code would be nice, but isn't
That's encouraging. From the openssl docs I've read so far, it looks like certificates and In order to keep compatibility with socket.ssl, perhaps any new |
You can load a private key from a string by creating a memory BIO and This is how pyOpenSSL implements its load_privatekey API. You can see |
Any update about this issue? |
There's a patch in bpo-8550 to expose SSL contexts as first-class objects. It allows you to create first your context object(s) and load certificates, then drop privileges, then create sockets using this/these contexts. |
I take it this is out for 2.7, will it be in 3.2? |
The patch for bpo-8550 has been committed. The SSLContext API should solve this issue: If it doesn't, please explain why. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: