Looks like there are a couple of other functions in the Secure Transport backend that aren't implemented. Pretty irresponsible to put that kind of insecure-default code into a production library. The workaround is to compile Qt to use OpenSSL instead of Secure Transport.
If we do that, we'd be able to make OSX versions of our app instead of having to do some dodgy "validate the cert using direct openssl calls" approach. That definitely sounds workable.
Also, you're using the "verify" function incorrectly. Take a look at the documentation for that function; it doesn't do what you think it does anyway. So even on non-Mac platforms, you weren't verifying the peer certificate.
I'm going to stop looking at that QSsl API. It looks very poorly designed.
Thinking about this more, that's not clear. When you say it doesn't do what we think it does... what are we misunderstanding?
Our desire is to make sure the server we're connecting to is "one of ours". eg to validate the cert provided by the server against a cert chain we've bundled with the client just for this purpose
The docs for the function seem to indicate that what it's for.
Er... suggestions/assistance (etc) on what we should be doing instead are definitely welcome. :)
auto verificationErrors = reply->sslConfiguration().peerCertificate().verify(m_sslConfiguration.caCertificates());
implies that you want to see if "peerCertificate" validates under "m_sslConfiguration.caCertificates()".
That's a reasonable (and necessary) thing to do, but the "verify" function doesn't do that. It's a static function, thus it ignores "peerCertificate". The way you're using it, it simply verifies "m_sslConfiguration.caCertificates" using the system's default CA certificates (I think; the docs are somewhat confusing about this).
Also, further down in that code, you ignore self-signed errors. Well that pretty much negates the point of checking in the first place doesn't it? Because if someone MITM's your connection with a self-signed certificate, your code will say that's fine.
However, according to the docs for "QSslConfiguration::setCaCertificates", those CA certificates are used to verify the peer certificate during the SSL handshake. So do you even need to be doing any kind of verification manually? I'm not a Qt programmer, but it seems to me that since you're using the appropriate "QSslConfiguration::peerVerifyMode", it should verify the server certificate during the handshake using the CA certificates you set (it happens in the Mac code at [1]).
Bottom line: your "RemoteDatabase::gotEncrypted" function can simply be eliminated. This would both provide proper peer verification and eliminate your problem on the Mac platform.
Ahh cool. The code we've written for this bit so far was just an initial concept implementation.
The server side code is taking most of the effort, so we'll return to the client side bits later when we have something more solid (less changing) for it to talk to. :)
Even if you do that, are certificates validated against a meaningful list of valid root certificates? (I can't imagine any being practical other than the operating system's).
He supplies his own. In situations where you control both endpoints, this is far more secure than trusting system CA certificates (which include all manner of foreign government and third-party certificates, including some from companies that have been known to issue intermediate CA certificates to third-parties, a big no-no).
After investigating further, it seems that doing manual verification is unnecessary, since Qt does verification during the handshake so long as the default verification mode is used (or the setting to force both server and client verification is used).
We're creating a "cloud" (will be at https://dbhub.io) for people to share/store/collaborate/publish/etc data in SQLite format. Kind of niche, but it should be really helpful for places needing to version+collaborate on (non huge) reference data sets.
There's a live dev server here if that's of interest:
Note - that page shows the expected look and feel. We have no real front page at the moment - it's just a list of public databases that have been uploaded for now - but that'll change as some other bits are completed. :)
