[Interest] libeay32.dll - The Ordinal 4369 could not be located
Bo Thorsen
bthorsen at ics.com
Mon Jan 27 16:15:26 CET 2014
Hi Till,
It looks to me like the discussion you are bringing up here has several
different questions:
1) How can we protect a Qt binary from picking up a bad ssl library -
for example a wrong version?
2) How can we protect a Qt binary against an attack with a hacked ssl
library?
3) What is the correct procedure when scanning for the ssl library?
To me this looks like the correct answers depend a lot on the answer to
number 2. As we will not have a statically linked OpenSSL with
commercial Qt apps, currently we have no choice but to deliver the two
dll files. That means the question no longer can be a security issue,
since we can't solve that.
So number 3 and 1 becomes one question. My argument that we should
recompile Qt without ssl support is the proper solution to avoid a Qt
app, that we didn't intend to use ssl, picking up the library anyway.
But it would be nice if qt.conf had a "disallow ssl" option. Then it's
easy to avoid a crash from a bad ssl library picked up from somewhere else.
It would be great if we could have trusted plugins that are
cryptographically signed so my application could be shipped with a
public key and check plugins. This would solve the security problem as
well. It should be possible to create one that links statically to
OpenSSL and ship that. I think. The license of OpenSSL is pretty annoying.
Bo.
--
Bo Thorsen, European Engineering Manager, ICS
Integrated Computer Solutions. Delivering World-Class Applications
http://ics.com/services
More information about the Interest
mailing list