[Development] RFC: Managing the Addition of New SSL Backends
jeremy.laine at m4x.org
Tue May 6 08:11:43 CEST 2014
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?
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
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.
On the other hand:
- you can get access to the raw DER data for the certificate (SecSecurityGetData )
- you can create a certificate instance from the raw DER data
I have therefore written some code to parse just enough ASN.1 to extract the certificate
Does WinRT provide access to the DER data?
> 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
I haven't looked into what iOS offers here yet.
More information about the Development