Improving TLS handshake support
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