QSslSocket Behaviour Linux vs macOS (possibly LibreSSL incompatibilities?)

SGaist

Might be a silly question but did you explicitly select the OpenSSL backend when compiling Qt ? Also, did you linked to OpenSSL or load at runtime ?

Markus M.

@SGaist There are no silly questions - just maybe silly answers :-)

1: yes, I set the OpenSSL backend when compiling.
2: I linked.

That said this is also something to look into; I am not fully clear how Qt handles SSL and if I did it correctly. Assuming its an SSL issue I wonder why my Mac client can connect to the Linux server without issues.
But in general I agree, this might be the root cause. Unfortunately the error messages are not exactly verbose - it just says "internal SSL error"... could be anything

SGaist

Can you check with otool -L the resulting QtNetwork framework ? Just to ensure that it indeed used your version of OpenSSL and not the one from the system.

Are you using a custom made certificate ?

Markus M.

@SGaist Here's the otool output:

@rpath/QtNetwork.framework/Versions/5/QtNetwork (compatibility version 5.10.0, current version 5.10.0)

Yes, I use self signed certificates. That is, a self signed CA certificate which in turn have been used to sign the server cert. According to the KeyChain app the certs are ok (ie trusted)

SGaist

It looks incomplete. That looks like just the library id.

I get:

@rpath/QtNetwork.framework/Versions/5/QtNetwork (compatibility version 5.10.0, current version 5.10.1)
@rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.10.0, current version 5.10.1)
/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 58286.31.2)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1450.15.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 822.19.0)
/System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 963.30.1)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
/System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork (compatibility version 1.0.0, current version 893.13.1)

Markus M.

@SGaist Silly me; I only pasted the one line affecting QtNetwork. Sorry for that. Here we go:

@rpath/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 5.10.0, current version 5.10.0)
@rpath/QtGui.framework/Versions/5/QtGui (compatibility version 5.10.0, current version 5.10.0)
@rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.10.0, current version 5.10.0)
/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
@rpath/QtNetwork.framework/Versions/5/QtNetwork (compatibility version 5.10.0, current version 5.10.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)

fyi: I reverted back to the standard Qt version, ie not using the self compiled one for now. Hence the output above might not be what you expected.

For now, I try to figure out a couple of things (e.g why my peerValidName etc are not set on the socket) and how to load ssl at runtime

SGaist

Indeed, it was the one from your self-compiled Qt that is of interest.

As for loading at run time, you pass the -openssl-runtime option.

Markus M.

@SGaist Thank you for now... appreciated.

I am about to re-compile Qt which will take a couple of hours (about 4 to 5 hours yesterday) on a 2017 MBP 15...

Will keep you advised on my efforts

SGaist

Don't compile all of Qt. For your testing you likely only need qtbase. If more, then build only the modules you need after qtbase (or pass a list of -skip options for all modules you don't use in your application).

Markus M.

@SGaist I am aware, thank you. That is exactly what I am researching right now - what modules to compile. Don't want to be too restrictive though 'cause if successful I'll use this version for my client and other apps, too.

SGaist

What modules are you using for it currently ?

Markus M.

@SGaist

core, widgets and network. This is only for the server, the client also requires gui.

Its just crazy, just "make clean" takes forever

SGaist

So qtbase is enough.

Use out of source builds, so if you want to start from scratch you only have to nuke the build folder and the sources stay clean.

Markus M.

@SGaist edit: after hours of investigation I got it to configure/compile. I had to manually point/symlink the openssl files located in /usr/local/lib and /usr/local/include, respectively, to the directory where openssl actually sits.

As it seems configure bails out for openssl versions north of 1.1.0. For some reason (no idea how this came about) I had openssl 1.1.1-pre-something installed.

Follow up: the private Key is indeed set; however, something is wrong with it because Qt marks it "isNull". That is, I can qDebug it and at first glance it looks fine. Same on Linux.

Follow up 2: I used the code as posted in
https://forum.qt.io/topic/45728/generating-cert-key-during-run-time-for-qsslsocket/7

Again - as @Pradeep-P-N reported, the code crashes in the final step (setPrivateKey); that is, the privateKey is null. The said is true on macOS using openssl 1.0.2n

Follow up 3: Under Linux, a valid key is indeed created. However, the key does not seem to be relayed to the server. Keep digging...

Follow up 4: Have not managed to create a key via openssl that could be loaded from disk - neither on Linux nor on the Mac. Not sure what's going on, the private Key just is always null (have tried various formats...). For now solely the code as posted in the linked thread above works under Linux.

For now I suspect main the problem has to do with the linked openssl version on the Mac: Building gives lots of warnings: object file (libcrypto.a) ws built for newer OSX version (10.13) than being linked (10.10).

If I get that correctly this means the openssl lib used to generate the keys was built on 10.13 whereas Qt's version was build on 10.10?

SGaist

OpenSSL 1.1 broke API and ABI compatibility with the 1.0 series.

Up to Qt 5.10, only 1.0 was supported. Since 5.10, you can build the 1.1 backend but Qt is still delivered with 1.0 currently.

IIRC, Qt is built with the latest version of Xcode at the time and has a run target of "Current release" -3 (the same number of versions that Apple still supports) following Apple's policy of "build with the latest version of Xcode".

Markus M.

@SGaist Hi. Happy to be able to report that part of the experienced issues are solved using Qt compiled from source (linked against OpenSSL 1.0.2n). More specifically, the server part now accepts connections, the socket errors (20, 21) are gone.
The code segment posted in mentioned thread above now works on the Mac as well, i.e. i can generate private keys in code now.

That said, the QSslKey loading problem still exists. In particular, its still fails to set a private key loaded from file. I wonder whats the root cause - to me it seems like its a bug in Qt. All the samples I found online do not seem to work...

SGaist

Would it possible for you to provide a small client/server project(s) that allows to test that behaviour ?

Markus M.

@SGaist I could provide the client code - which should be ok for testing this?

SGaist

In the absolute, having also a test server would be nice (doesn't need to be C++ for that part) as it would allow to be sure that a failing connection can properly be made.

Markus M.

@SGaist I understand; still its kind of difficult to just give out the sources since some of the tech used there (unrelated to connecting) is under heavy confidentiality requirements.

That said, a server you could connect to is available via DynDNS (edit: tested - working)