[Development] RFC: Managing the Addition of New SSL Backends

Oliver Wolff oliver.wolff at digia.com
Tue May 6 08:34:06 CEST 2014

On 06/05/2014 08:11, Jeremy Lainé wrote:
> Thanks Richard for taking the time to write up your summary, as the subject is pretty vast.
> On 05/03/2014 11:23 PM, Richard Moore wrote:
>> Support for QNAM
>> ================
>> It's obvious that to be useful, a backend must allow QNAM to make SSL
>> requests. It need not support the more advanced features such as
>> client certs, custom CAs, custom cipher suites etc.
>> In order to handle user exceptions, we need a way to signal the
>> errors. This means that QSslError would be required. Another option
>> might be to offer some pre-built UI component for this, but that has
>> the issue that a single component would probably not be a good fit to
>> many UIs.
> Who is looking into WinRT, as I'd be interested in hearing what the WinRT API offers in
> terms of error reporting?
As covered in in [1] there should be at least enough error reporting to 
implement a minimal SSL subset
for WinRT.

> On the iOS / Secure Transport front, QSslError support is not going to be as detailed as
> the OpenSSL backend as the API offers very little detail about "what went wrong"
> establishing a secure connection.
>> Another issue is displaying the certificate to the user. The
>> QSslCertificate API is large, and whilst I think most backends would
>> be able to provide most (if not all) of the facilities this is still a
>> significant barrier. Instead, how about we allow QSslCertificate to be
>> used as an opaque type for most apps?  This could be done by providing
>> access to the platform native (or a Qt provided) certificate
>> dialog. This would reduce the requirements for the backend
>> substantially.
> Can you explain your thinking in more detail on this point? For iOS / Secure Transport
> there is a clean separation between the SSL code and anything GUI related - to my
> knowledge there is no "native dialog" to handle accepting certificates.
I don't think that there is that kind of dialog for WinRT either or at 
least I haven't seen anything like that.
So to have all that cross platform and not have to implement it again 
and again we should probably offer
a Qt dialog which has the most important certificate properties inside?
> On the other hand:
> - you can get access to the raw DER data for the certificate (SecSecurityGetData [1])
> - you can create a certificate instance from the raw DER data
> (SecCertificateCreateWithData [2])
> I have therefore written some code to parse just enough ASN.1 to extract the certificate
> details:
> https://qt.gitorious.org/qt/sharkys-qtbase/source/ec189e6994b331e0e6662440a4a6fba3366277ec:src/network/ssl/qsslcertificate_ios.cpp
> Does WinRT provide access to the DER data?
Yes see [2]
>> Simplifying the Cipher API
>> ==========================
>> Currently, the QSslCipher API is pretty large. It's not simply the
>> code in the QSslCipher class itself, but also all the stuff in the
>> QSslConfiguration that defines the preferences. Instead, we could
>> offer a simplified API that all backends must offer. So, for example
>> we could have something as simple as High, Medium and Low! After all,
>> most people (including developers) don't know the trade-offs of the
>> different cipher suites anyway. We could also have a flag for perfect
>> forward secrecy since that is independent of the strength. It would
>> also be possible to have a setting like FIPS for people who care about
>> that.
> I haven't looked into what iOS offers here yet.
> Cheers,
> Jeremy
> [1]
> https://developer.apple.com/library/ios/documentation/Security/Reference/certifkeytrustservices/Reference/reference.html#//apple_ref/c/func/SecCertificateCopyData
> [2]
> https://developer.apple.com/library/ios/documentation/Security/Reference/certifkeytrustservices/Reference/reference.html#//apple_ref/c/func/SecCertificateCreateWithData
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development




More information about the Development mailing list