Details
-
Suggestion
-
Resolution: Unresolved
-
P3: Somewhat important
-
5.13.0
-
None
-
-
21
-
Qt6_Foundation_ Sprint 2
Description
Hello,
Problem
Using QSslSocket for server-side encryption does not take advantage of session resumption, whether it be session ID's or session tickets.
What is happening
After digging, this is due to the OpenSSL context being recreated each time a new SSL socket is setup. As a result, the session ticket private key is not known upon reconnection and thus the session resumption is ignored. See for relevant code: https://github.com/qt/qtbase/blob/5.12/src/network/ssl/qsslcontext_openssl.cpp#L85**
Use case
I have a HTTP server written around QTcpServer that I was hoping to utilize session resumption for. In addition, there is a WIP qtlabs project that would benefit from session resumption as well: https://bugreports.qt.io/browse/QTBUG-60105. I imagine there are other performance advantages to reusing the SSL context.
Current approach
I've attached a patch with some rough proof-of-concept code that demonstrates that reusing the context allows session resumption to work.
I've used Qt for awhile now but I'm new to the Qt-development world. I'm happy to submit a patch for this issue, but I would like to discuss the best method of reusing the OpenSSL context.
I save the QSslContext (private class) in QSslConfigurationPrivate as a shared pointer. I would set this shared data pointer and that should keep the context alive so long as the configuration is saved. However, QSslConfiguration performs a deep-copy when QSslSocket::setSslConfiguration is called, so the context ends up being deleted once the socket is closed. My hack was to remove the deep-copying but I don't think this is a good idea since QSslConfiguration::sessionCipher is dependent on the QSslSocket and so shallow-copying means this will change whenever the configuration is passed to a new socket.
Note: To quickly see the important changes in my patch, go to line 1029.
Alternatives:
- Original implementation of QSslContext made mention of making it public eventually, could do this and then have the user save a copy of the context as a shared pointer
What is the best course of action?