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

[Peter Hartmann]

Hello,

TL;DR: I think we can accept new backends if they support some minmal 
client-side API, i.e. they succeed connecting when there are no errors 
and fail if something goes wrong.
The big problem IMO is how to advertise to the developer what parts of 
the API are supported and what not.


Some inline comments:

On 05/03/2014 11:23 PM, Richard Moore wrote:
> (...)
> - Very few applications use custom trust stores.

I would actually hope that this number increases for security reasons 
("certificate pinning"), but most servers do not provide more 
information there currently...

> (...)
> 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.

I wonder whether the use case is that important; it would be beneficial 
to have a way to display a certificate to a user, but apart from 
browsers I usually don't see many apps using this feature (i.e. most 
apps just correctly abort and display "SSL error", and some just proceed 
anyway, which is bad security-wise).

>
> 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.

Yes it sounds like a good idea to have something simpler for developers, 
as probably nobody knows whether "ECDHE-ECDSA-AES256-GCM-SHA384" is 
secure or not.
But yeah I think this is a separate discussion, as long as new SSL 
backends have secure defaults.

> Proposed Capabilities
> =====================
>
> * SSL Client
>
> A backend offering this capability must offer the basic client-side
> QSslSocket API.

yes, so it should succeed connecting if everything is fine, and must 
fail if something is wrong (e.g. untrusted certificate).
The problem is e.g. when somebody wants to trust only a specific 
certificate or so and that part of the API is not supported.

I think all we can do here is to try to document this as good as 
possible and issue run-time warnings for not supported methods. Also the 
categories suggested below would help...


Peter