Qt wiki will be updated on October 12th 2023 starting at 11:30 AM (EEST) and the maintenance will last around 2-3 hours. During the maintenance the site will be unavailable.
Improving TLS handshake support: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
[[Category:Developing Qt::Network]]<br />[[Category:Developing Qt::Bugs]] | [[Category:Developing Qt::Network]]<br />[[Category:Developing Qt::Bugs]] | ||
[toc align_right= | [toc align_right="yes" depth="3"] | ||
= Update = | = Update = | ||
Revision as of 14:34, 24 February 2015
[toc align_right="yes" depth="3"]
Update
Code submitted for review: https://codereview.qt.io/#q,54364,n,z
The APIs are all generic - supporting send and receive of custom TLS extension data and supplemental data.
Please note, the add* methods on QSslSocket must be called from the slot registered direct with the associated signals (call setTLSAuthClientExtension from the slot connected to the readyForTLSAuthClientExtension signal, for example).
The review includes code providing a simple demo application - available from qtbase/examples/network/tlsauthextensions, which leverages the generic TLS extension and supplemental data features to support RFC 5878 (TLS auth extensions)
The review also includes autotests added to the ssl socket suite: tlsAuth and tlsAuthWithError
Remaining outstanding work
The TLS extension APIs and signals need to be accessible to applications using QWebView, which leverages a pool of QSslSockets and does not expose the sockets directly, as requests may be served from any of the sockets in the pool.
Question: Should APIs be exposed on QNetworkAccessManager and plumbed through to QSslSocket (this would bloat the QNAM API significantly), or should this logic be moved to somewhere more SSL-specific? (something new? QSslConfiguration?)
Improving Qt's TLS Handshake Support
Work is starting on support for TLS extensions (http://www.ietf.org/rfc/rfc5246.txt) as well as support for the supplemental data handshake message (http://tools.ietf.org/html/rfc4680). This page is intended to be used to work through implementation issues and API design considerations.
Support for double handshake/renegotiation may also be considered here, as it is common to use the double handshake technique to require the initial supplemental data sent by the server to be sent encrypted.
A bug was found in the client-side support for renegotiation. A patch was submitted:
https://codereview.qt.io/#change,61661
Bugs filed:
- TLS extensions: https://bugreports.qt.io/browse/QTBUG-30095
- Supplemental data: https://bugreports.qt.io/browse/QTBUG-30093