How to get access to OpenSSL context?
-
Hi,
I need to do some custom OpenSSL processing and I need the OpenSSL context associated to a QSslSocket. Are there any ways to get to the context? Or also vice versa, If I create an OpenSSL context, is there a way to pass it to a QSslSocket?
The only piece of information I was able to find is https://bugreports.qt-project.org/browse/QTBUG-14983 which talks about an internal QSslContext that will be available in 5.1.0. So it seems to me that, since it is internal, I will not gain a lot from 5.1.0....
Before I dig in the Qt code or build my own Qt 5 off the git repo, anybody has an idea?
thanks :-)
marco.m -
Hey Rich,
I wanted to register a callback with SSL_CTX_set_verify(SSL_CTX *ctx, int mode, int (*verify_callback)(int, X509_STORE_CTX *)). This callback allows you to do custom/additional verification of the peer certificate.After thinking a bit about it, I realized that I can obtain the same by connecting to two QSslSocket signals: sslErrors() (on TLS handshake failure) and encrypted() (on TLS handshake success). A decent workaround I think.
Thanks anyway for your offer to help :-) I assume you are the Rich that wrote a few blog posts on Qt and OpenSSL, right?
There is another feature that is missing I think: validating that a private key and the public key of a certificate match. Today the code does the validation too late, when connecting (client side) or when receiving a connection (server side). Especially on the server side, you want to know upfront that your configuration is wrong, instead of waiting for the first client attempting to connect :-)
I think the cleanest way would be to provide an accessor to the public key from the private key:
QSslKey private(...)
QSslCertificate cert(...)
if (private.publicKey() != cert.publicKey()) {
// wrong key pair...
}what do you think?
-
bq. After thinking a bit about it, I realized that I can obtain the same by connecting to two QSslSocket signals: sslErrors() (on TLS handshake failure) and encrypted() (on TLS handshake success). A decent workaround I think.
Yes, the encrypted() signal happens immediately after the handshake is complete, so you can do additional processing there. I've added the same signal to QNetworkAccessManager in Qt 5.1 to support exactly this use-case.
bq. Thanks anyway for your offer to help :-) I assume you are the Rich that wrote a few blog posts on Qt and OpenSSL, right?
Yes, that's right/
bq. There is another feature that is missing I think: validating that a private key and the public key of a certificate match. Today the code does the validation too late, when connecting (client side) or when receiving a connection (server side). Especially on the server side, you want to know upfront that your configuration is wrong, instead of waiting for the first client attempting to connect :-)
bq. I think the cleanest way would be to provide an accessor to the public key from the private key:
bq. QSslKey private(…)
QSslCertificate cert(…)
if (private.publicKey() != cert.publicKey()) {
// wrong key pair…
}bq. what do you think?
Yes, that seems like a sensible thing to support. Do you think you could file a bug report for it so that it gets added to the todo list (it will avoid it being missed).
-
Done, "QTBUG-31815":https://bugreports.qt-project.org/browse/QTBUG-31815