[Development] RFC: Managing the Addition of New SSL Backends
phartmann at blackberry.com
Tue May 6 11:25:33 CEST 2014
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
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
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...
More information about the Development