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

[Richard Moore]

Introduction
============

Qt provides a fairly powerful SSL API with support for a wide range of
uses - SSL clients and servers can both be created. It provides
extensive APIs for accessing information in SSL certificates,
information about ciphers etc. In addition to the basics, it also
includes built in support for more advanced features such as client
certificates, server name indication etc.

Since Qt 4.4 the SSL API has been based exclusively on a single
backend implemented using OpenSSL. This has worked well for a long
time, despite some pain caused by the regular source and binary
compatibility breakages that OpenSSL suffers from. The major downside
is that it can prove difficult for some users to install OpenSSL, and
that some platforms (I'm looking at you Apple) only provide old
versions. Unfortunately for legal reasons, the Qt project is unable to
bundle a copy of OpenSSL making it hard to address this weakness.

Recently, there have been some efforts to provide non-OpenSSL based
support for SSL in Qt. Currently, this consists of some minimal
support as a fallback on iOS that allows QNetworkAccessManager (QNAM)
to access HTTPS sites using NSURLConnection (by Morten Sovig), and the
start of some work to implement a real (as-in fully compatible with
the existing API) SSL backend using SecureTransport by Jeremy Laine. A
similar effort will also be required to add support for SSL on WinRT.

The current SSL API Qt offers is powerful but large making
implementing a full backend a significant undertaking. What I hope to
set out here are some ideas of how this can be made easier by
considering a set of modular capabilities that backends could
offer. This would mean that new backends could offer a subset of the
full API but would still be compatible with both each other and with
the current OpenSSL backend.

Use-Cases
=========

- Most apps simply use QNAM.

- Many apps need to handle user exceptions to SSL connections that
  would otherwise error.

- Many applications use client SSL sockets.

- A small but significant number of apps use client certificates.

- A small but significant number of apps use server SSL sockets.

- Very few applications customise the set of ciphersuites used for
  SSL.

- Very few applications use custom trust stores.


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.

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.

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.

Simplifying the Certificate API
===============================

Most applications only need minimal information from certificates - in
fact in many cases the only direct usage is to show the certificate to
the user. We could allow applications to do this by proving a method
to show a certificate dialog given a list of QSslCertificates, this
could either be the platform certificate dialog or one provided by the
Qt backend. If we did this then a backend could simply have stubs for
the current accessors (or we could define a minimal subset they should
provide).

Proposed Capabilities
=====================

* SSL Client

A backend offering this capability must offer the basic client-side
QSslSocket API.

* SSL Server

A backend offering this capability must offer the basic server-side
QSslSocket API.

* Client Certficates

A backend offering this capability must support the various client
cert methods in QSslConfiguration etc.

* Certificate

A backend offering this capability must support the QSslCertificate
API.

* Ciphers

A backend offering this capability must support the using QSslCipher
etc. to set the cipher list.

* Trust Store

A backend offering this capability must allow you to add/remove
etc. the trusted CA certificates.

* Full (ie. the full API)

The backend must be complete.

Run-Time or Compile Time?
=========================

My feeling is that (certainly for now) this should be a build-time
decision.  The OpenSSL backend would still be the recommended one
since it offers the full set of capabilities, but you could build Qt
for your device using a different backend.

Why do This?
============

I'm concerned that if we don't standardise these capabilities in some
form then we're likely to end up with different backends that each
support a random subset of the API.

Some of the other changes I'm suggesting are really independent of all
this, and are probably good ideas anyway (for example providing a
simpler API for ciphers and access to the platform cert dialog).

Risks
=====

One problem with this concept is that we might end up with
fragmentation of the SSL APIs. I think however that this is occurring
already (as the iOS example shows), so what I'm trying to do is manage
this rather than avoid it.

Another problem is that existing applications might not realise that
the backend they're on only offers stubs for some functions. This is a
hard problem, however we could require apps to opt-in to this
proposal, with the fallback being the existing code that dlopens
openssl. Obviously if openssl isn't there then such apps would not
have SSL support, but that's already the case today.

Does This Mean There'll be a Backend For XYZ?
=============================================

I'm not planning to write any new backends. My aim here is purely to
allow people who are doing so to do it without fragmenting the Qt
platform, and in a way that ensures that things are interoperable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140503/3c1438f7/attachment.html>