[Development] TLS extensions and supplemental data

[Scott Deboy]

I've pushed a review to Gerrit providing support for TLS supplemental data and TLS extensions via a new pair of classes and APIs added to QSslSocket (six new setters/accessors and four new signals). 

Review available here:
https://codereview.qt-project.org/#q,54364,n,z

Wiki topic updated to describe the API and new classes:
http://qt-project.org/wiki/Improving_TLS_handshake_support

My next task is to find a way to make these new APIs accessible to apps using QWebView.  As QWebView leverages pooled connections and QNetworkAccessManager (QNAM), and doesn't directly expose the QSslSocket, some plumbing is needed to give applications a path to set the TLS extensions and supplemental data.

I could add these APIs directly to QNAM, but the additional signals and methods would seem to bloat the QNAM API significantly for something not frequently used.  QNAM currently exposes some SSL capabilities (encrypted signal, SSLErrors), and the supplemental data signal and ability to trigger an SSL error during handshake are not TLS auth specific, but the other signals and setters/accessors are tls auth specific.  The only TLS extension currently supported is SNI, and it doesn't need to be changed at the moment to take advantage of this mechanism, although it could be (particulary to notify the client that the requested server name was available).

Any suggestions for how to plumb this capability?  Add the APIs and signals to QSslConfiguration?  A new class?  QNAM?

Thanks,

Scott
On Mar 13, 2013, at 3:33 AM, Peter Hartmann <phartmann at blackberry.com> wrote:

> Looks good!
> 
> Some comments / questions:
> 
> - Do you have examples of supplemental data? It seems to me like TLS extensions are more important here, as they are used everywhere already.
> 
> - re. API:
> 
> What comes to my mind are the following options:
> a) generic class QTlsExtension similar to QSslCertificateExtension with name() and QVariant value() and getter "QList<QTlsExtension> QSslConfiguration::tlsExtensions()" (+ respective setter). Depends on whether it is worth to introduce a new class.
> 
> b) enum in QSslConfiguration (e.g. "QSslConfiguration::TlsExtensionServerName") and getter "QVariant QSslConfiguration::tlsExtension(QSslConfiguration::TlsExtension)" (+ respective setter). Might be better because of less API than a)
> 
> c) individual getters / setters like "QVariant tlsExtensionServerName()"; that looks like cluttering the API.
> 
> 
> 
> - re. "On which object should extensions be set/retrieved?":
> 
> Maybe QSslConfiguration would be the place to set/get extensions, instead of QSslSocket? At least this is where we store things like the session cipher, certificate chain etc. IMO the API is a bit cluttered between those two classes, so I think we should have all of that in QSslConfiguration.
> 
> 
> 
> - re. "How are the extensions to be set and exposed?":
> 
> If "There is a requirement to be able to retrieve the far side extension prior to setting extensions", then this sounds like we need a new signal for QSslSocket (and probably later the same one in QNetworkReply). Rich was working on an "encrypted" signal which would be fired after the handshake and before application data was sent, but I guess this would be too late for some extensions then.
> 
> 
> - re. "One-shot setter supporting a set of extensions, or ability to call addExtension multiple times prior to the extended hello being sent?"
> 
> I think we could combine it, by having an addExtension taking one single extension and maybe an overload which takes a QList or so.
> 
> 
> Regards,
> 
> Peter
> 
> 
> On 03/08/2013 08:09 PM, Scott Deboy wrote:
>> I wanted to give folks a heads-up that I'm starting work on defining an API which will give Qt the ability to retrieve and set TLS extension data sent in OpenSSL's extended hello.
>> 
>> I will also be adding support for the ability to send and retrieve supplemental data messages.
>> 
>> A Wiki topic has been created to work through the process of defining the API - please feel free to update/add questions or contribute to the discussion:
>> 
>> http://qt-project.org/wiki/Improving_TLS_handshake_support
>> 
>> Thanks much,
>> 
>> Scott
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>> 
> 
> 
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.