[FEATURE] SSL PKI integration for OWS connections

[dakcarto]

Sponsored by Boundless Spatial, US

Adds the following SSL PKI support

• Reusable SSL PKI setup widget (QgsSslCertificateWidget, here inside WMS connection setup dialog):

It does lightweight validation (dates, etc., see QSslCertificate.isValid() )

• SSL certificate settings (QgsSslCertSettings) and utilities (QgsSslUtils) classes

• Configures a local QGIS Store ~/.qgis2/cert_store

  $ ls -l  ~/.qgis2/cert_store
  drwx------  certs     <-- client certificates, e.g. name.pem
  drwx------  issuers  <-- certificate issuers (not in OpenSSL store, allows for self-signed bypass)
  drwx------  private   <-- client certificate private keys

• Add QgsCredentials key passphrase support, with stacked widget to rotate between inputs (username/password or key passphrase).

• Add SSL Certificate widget to new OWS connections (tabbed widget with Authentication).

• Cache key passphrases in QgsNetworkManager singleton, since it did not work with QgsCredentials.

The Good Stuff

• Support for private keys with passphrase-protection.
• Memory-caching of key passphrase, so it only needs input once per session.
• Key passphrase NOT stored in project file.
• Key passphrase can be input by user via GUI, or via console, when projects/layers are loaded, and across provider/GUI threads (via QgsCredentials).
• Support for auto-ignoring self-signed certificate issuer's certificate (per cert or cert chain, but not globally).
• Full Python bindings, where appropriate (e.g. no access to in-memory key passphrase).
• All additions have finally been encapsulated enough to allow for easier addition of different certificate store setups later

Caveats

• Only works for the WMS provider at this time. Need some feedback on whether this approach is sound, before adding PKI for other OWS connections ... should be fairly easy to do this week. ( @jef-n , @mhugent ?)

  NOTE: the other OWS services do show the certificate GUI, but are not yet functional.

• Base security is not so great. Since the QGIS local store is a know location, any plugin running with user-rights can find private keys, so those should always be passphrase-protected. (Important to note in the users guide).

Future Improvements

• Adding additional certificate stores, e.g. the native platform stores (like Apple's keychain), can be done using the robust Qt Cryptographic Architecture (QCA). The cross-platform library does have a couple of issues, though:
  • No stable release that works with post-HeartBleed OpenSSL releases. Current development versions work well, though.
  • QCA adds a significant dependency to QGIS. The build should probably be optional, e.g. a '-D WITH-QCA'. May, or may not, be difficult for QCA to become a core requirement, due to the older systems that QGIS continues to support.
• Better certificate validation, including info dialogs to inspect the cert chain of trust.
• Better SSL hanshake error reporting.
• Add some cert conversion functions to allow users to import certs of other varieties, not just PEM-based. (Still stored locally as PEM)

Testing

You will need an HTTPS web mapping service with user authentication via PKI turned on. See this page for some info on an OpenGeo Suite setup with GeoServer.

[dakcarto]

@mhugent I assigned this to you. If you feel it should be assigned to someone else, e.g. @jef-n, please remove yourself. If you have the time before the feature freeze, I would appreciate a quick review of the technical aspects of the work.

Thanks.

[mhugent]

Since @jef-n has written QgsCredentials, I'm assigning the pull request to him.

[dakcarto]

@jef-n I am refactoring the means of caching the PKI components (cert, key and optional issuer cert), to remove the bits from QgsNetworkManager and reduce recreation of the components. Should be done in a couple of hours. Otherwise, the rest of the implementation remains similar.

[dakcarto]

@jef-n Approach refactored to offer more robust storage of PKI group. More secure manner of dealing with private keys (path and any password are optionally only input when needed, and not stored).

This is pretty solid here with my testing. And, I think the approach is more scalable now.

Just need to add the support to other OWS services today, but I can do that after it is pushed, if that is OK with you.

[dakcarto]

@jef-n @mhugent Closing this in favor of a more robust application-wide solution.