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

[Konrad Rosenbaum]

On Saturday 03 May 2014, 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.

A pre-built dialog to show certificates (like QFileDialog does for 
directories/files) would be great!

BUT: please do not remove the QSslError API!! Don't even consider replacing 
it with a default dialog or otherwise making it optional! Many applications 
need to be able to store SSL-Exceptions in their configuration and NEVER 
prompt the user about them.

For example one of my bigger projects is a point-of-sales application for 
theaters that communicates with an HTTPS server. Explaining to my users that 
the name of their spouses did not make a good password - even if they don't 
tell anyone - was so exhausting and unsuccessful that I had to add another 
layer of security to the program to limit the potential damage. I shudder to 
think about explaining SSL certificates and possible error conditions to 
them!

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

The very least you need from it is the acceptable domains (subject 
(alternative) names) and the fingerprint. Otherwise you won't be able to 
distinguish them. It would also be quite helpful to get the issuer cert 
somehow for scenarios that care more about the CA than the cert itself.

To make things really workable you'd need to be able to store the cert 
somehow.

In short: I don't think you can reduce the API much without making it 
useless.

> 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 hope you realize that there are several levels of FIPS. And to give you a 
distincly non-American perspective: there are several levels of German, 
Japanese, Russian, etc. standards - all with differing requirements and 
their own sets of ciphers...

Do you really want to go there?

Create flags for practical features, like:
* disabling insecure and obsolete ciphers (RC4, DES, 3DES, IDEA, MD5)
* enforcing Forward Secrecy
* enforcing newer versions of TLS (some apps may need TLS 1.2, while most
  web servers still use TLS 1.0)

If this is done right the flags could be quite opaque and easy to extend 
without changing the app.

If the backend supports it leave the users the freedom to select their own 
cipher suites - if they feel the need to do so, they'll have a standard 
printout lying next to them that tells them which ciphers to chose. 

If you want to include lists of ciphers required by specific standards, 
you'll be trapped in a support hell - there are dozens of standards and they 
constantly change.

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

I like the idea of having a default dialog to show certificates (it was a 
major pain to come up with one myself). But a minimal subset of cert 
information is mandatory or you can't interact with them without involving a 
probably clueless user. 

(And why should a user have a clue about this arcane stuff in the first 
place? If any of my users - except for admins - is ever forced to see a 
certificate then I obviously did not do my job properly!)

> Proposed Capabilities
> =====================

* All of them

A way to ask the backend (from app code) what features it supports and 
whether it even was able to find its libraries or OS features.

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

Including a very basic version of QSslError please! (Error type + 
fingerprint)

[...]





	Konrad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140504/591d0b18/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140504/591d0b18/attachment.sig>