[Interest] Qt 5.9 and OpenSSL 1.1?

Roland Hughes roland at logikalsolutions.com
Mon Sep 16 18:51:55 CEST 2019

On 9/16/19 10:41 AM, Giuseppe D'Angelo wrote:
> On 16/09/2019 14:44, Roland Hughes wrote:
>> On 9/16/19 5:00 AM,interest-request at qt-project.org  wrote:
>>> Il 14/09/19 14:53, Roland Hughes ha scritto:
>>>> Please keep in mind there is no version of SSL which is secure.
>>> Do you have any reference/source for this (quite extraordinary) claim?
>> You know, for you it wouldn't matter. It would be a link and you are
>> incapable of actually clicking then reading anything which doesn't
>> support your opinion.
> So, personal insults right off the bat?
Not insults, factual history. You've even flamed about links in messages 
in this very thread.
>> There are numerous packages on the market which
>> cut through SSL like a hot knife through butter.
> Any link to ANY of those?

This is the leg work __you__ should be doing before writing your first 
line of code and before making any claim that SSL is secure.


Actual report the article is based on


Here's some historical ones from Cisco. A bit dated but shows just how 
thriving successful attacks have been through SSL.




>> "60 Minutes" did a
>> piece on the best known and most financially successful one but some
>> sources say there are around a dozen packages playing at the same level.
>> Here's the link which was provided before and I'm sure you didn't bother
>> to follow prior to responding.
>> https://www.cbsnews.com/news/interview-with-ceo-of-nso-group-spyware-maker-fighting-terror-khashoggi-murder-and-saudi-arabia-60-minutes-2019-08-18/
> The link does not talk about breaking SSL. The link is about spyware for
> smartphones. SSL is actually never mentioned, not to mention of course
> breaking it.

One of the primary ways it does it is by breaching SSL which is the 
easiest entry point. The second entry point is via that little 
bot/virus/malware/whatever-called-this-week they attach to the phishing 

> I'll reinstate: where is the evidence supporting the claim that "there
> is no version of SSL which is secure"?
> This is a super-strong claim on a mailing list read by Qt users, who are
> using SSL in their products, who are relying on Qt to do the right thing
> when it comes to security technologies (and Qt offers SSL-related
> facilities).
>>>> Please also keep in mind the big systems are moving towards a TCP/IP
>>>> software appliance within the OS. No application will be able to create
>>>> or open a port. No application will be able to choose/define the
>>>> transport layer security. They will open a logical-resource-handle
>>>> provided by the OS and the systems manager will configure if that
>>>> resource is I, O, or I/O as well as what the transport level protocols
>>>> are. Eventually (within 5 years of adoption) this will be forced out
>>>> into the IoT and lesser devices world as well.
>>> So long for the "backward compatibility is paramount" promise then.
>> That would only be for the hokey code which came from the *nix world.
> And Windows.
which took it from the *nix world if memory serves.
>> For the code which didn't come from a world that did it wrong it is 100%
>> backwardly compatible because that is exactly how we did network
>> communications. In other words all of the software developed_on_  those
>> platforms and_for_  those platforms will be fine. What will be going
>> away are the *nix TCP/IP library functions of C/C++ because they are a
>> massive security nightmare. There was a time when marketing bowed to the
>> pressure from companies which only wanted "free" software on their
>> million plus dollar platform, but that has lead to security catastrophe
>> after security catastrophe. Now they are in the process of locking them
>> back down and just letting people whine an snivel about *nix package not
>> being available on the platform.
> So we're talking about non-Unix, non-Windows, non-Apple platforms. I.e.
> roughly about 0% of the current market share of Qt. What are Qt users
> (the people who read this very mailing list) going to do with this
> useless information?

These are the business engines the embedded systems many of us create in 
the industrial and medical worlds which our devices will have to play 
nice with or some other device will be purchased which isn't written 
with Qt.

Don't be so quick to say non-Unix because that is not correct. Tru64 had 
it and that got rolled into HP-UX as well as into Non-Stop. It was also 
added into AIX at some point. It even existed on the original Windows NT 
before the tiny DOS brains at Microsoft stripped NT back to nothing but DOS.

The selling point in the world of the Big Dogs is now bullet proof 
security. An $80 x86 CPU running a "free" OS on a rack/blade somewhere 
is going to cost you north of $60 million, possibly $425 million


to keep upper management out of prison. Even a Keller MBA can make the 
numbers work on a spreadsheet for a $1 million computer with a centrally 
controlled OS level software "appliance" which creates and administers 
ALL network communications controlling all transport layer security. The 
days of having to scour all of one's data storage to find that elusive 
text script file identifying what ports some piece of software is 
"configured" to use are coming to an end.

One final thought/question. Just how many of the Qt applications which 
you've written using SSL did you sign up to take a course for then 
obtain the tools to perform full security testing?


Did you just file it under "buyer beware?"

No Giuseppe, I'm not going to do even more research for you. You should 
be learning all of this yourself and you should not be telling people 
adding SSL/TLS to their application makes them secure. It's better than 
nothing because it will keep honest people out, but it certainly is not 

There is no "one and done" solution for security. Real security is a lot 
of code and a lot of work. The excuse I hear over and over is "I'm not 
securing nuclear launch codes" and that is simply wrong. That attitude 
makes your app the vulnerability point which gets them to the nuclear 
launch codes or the next mega-million credit card identities.


Oh, scroll down on this to "Transport Layer" list for some more TLS/SSL 
testing tools which need to be run on every system one writes using SSL/TLS.


When it comes to security you don't get to "just check a box." Security 
has to be architected into a system when creating The Four Holy 
Documents up front. AGILE shops try to slough it off as a "user story" 
done in a sprint which means they have little to no security.

Roland Hughes, President
Logikal Solutions


More information about the Interest mailing list