Improving TLS handshake support: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
=Update= | [[Category:Developing Qt::Network]]<br />[[Category:Developing Qt::Bugs]] | ||
[toc align_right="yes&quot; depth="3&quot;] | |||
= Update = | |||
Code submitted for review: https://codereview.qt.io/#q,54364,n,z | Code submitted for review: https://codereview.qt.io/#q,54364,n,z | ||
The | 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). | 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 | 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 | The review also includes autotests added to the ssl socket suite: tlsAuth and tlsAuthWithError | ||
=Remaining outstanding work= | = Remaining outstanding work = | ||
The | 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 | '''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 | = Improving Qt's TLS Handshake Support = | ||
Work is starting on support for | 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. | 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. | ||
| Line 27: | Line 31: | ||
Bugs filed: | Bugs filed: | ||
* | * TLS extensions: https://bugreports.qt.io/browse/QTBUG-30095 | ||
* Supplemental data: https://bugreports.qt.io/browse/QTBUG-30093 | * Supplemental data: https://bugreports.qt.io/browse/QTBUG-30093 | ||
Revision as of 11:20, 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