[Interest] Qt 5.9 and OpenSSL 1.1?

Mon Sep 16 20:48:20 CEST 2019

On 16/09/2019 18:51, Roland Hughes wrote:
> 
> 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.

It doesn't work like this. YOU made the claim that SSL is not secure. 
Specifically, that it's as secure as

> hanging a CLOSED sign on the unlocked door to a 
> jewelry store having $20 million in inventory sitting in the cases 
> without an alarm system.

So YOU now have to provide the references to support that claim.

> https://techxplore.com/news/2019-03-cybersecurity-dark-web-exposes-vulnerability.html
> 
> Actual report the article is based on
> 
> https://www.venafi.com/sites/default/files/2019-02/Dark-Web-WP.pdf

This is exclusively about PKIs. It doesn't show any breach whatsoever of 
SSL.

> 
> Here's some historical ones from Cisco. A bit dated but shows just how
> thriving successful attacks have been through SSL.
> 
> https://blogs.cisco.com/security/breach-crime-and-blackhat

This actually puts SSL in a positive light, showing only THREE attacks 
against it. At least RFC 7457 shows more.

> 
> More
> 
> https://www.semrush.com/blog/https-a-modern-false-sense-of-security

And this again just mentions that earlier SSL versions had security 
vulnerabilities. It does not sustain the claim that there is NO version 
which is secure.

(As Thiago has already reminded, we're way past the point where we do 
get to prove mathematically the correctness and the security of our 
code; instead we rely on expert research, responsible disclosure and 
quick fix of any issue that may have been found.)

>>> "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
> email.

Where exactly in the video is "breaching SSL" stated? This is pure 
speculation, and very likely to be false too (you don't need to breach 
SSL to plant malware. You don't even need SSL in the first place!).

>>>>> 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.

So what's the relevance of how such business engines implement their 
network security, and Qt applications, NOT running on any of such 
systems? Such applications WILL be able to create sockets and open ports.

> 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.

More insults.

> The selling point in the world of the Big Dogs is now bullet proof
> security. An [SNIP]

Off-topic trivia.

> 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?
> 
> https://www.udemy.com/course/web-application-ethical-hacking/
> 
> Did you just file it under "buyer beware?"
> 
> No Giuseppe, I'm not going to do even more research for you. 

This not "doing research for me". This is following the rule that 
extraordinary claims require extraordinary proofs and evidence. The 
claim disputed here is "there is no version of SSL which is secure".

> 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
> "secure."

And where exactly did I say anything at all in that regard?

> There is no "one and done" solution for security. 

We are NOT debating this. We are debating this claim:

> Please keep in mind there is no version of SSL which is secure. All you 
> are doing by using it is hanging a CLOSED sign on the unlocked door to a 
> jewelry store having $20 million in inventory sitting in the cases 
> without an alarm system.

Insofar, the evidence brought was that

* earlier SSL versions were vulnerable to attacks, but these 
vulnerabilities have been addressed in later SSL standards;

* that PKI is critical (e.g. if you steal somebody's certificate you can 
impersonate), which has almost zero to do with SSL itself and way more 
with other security operations;

* that the only remaining attacks against SSL can be mitigated via 
server-side configurations (something that 99.99% of Qt users don't even 
care about as they're on the client side);

* that such remaining attacks require massive botnets and state-grade 
actors to be carried.

This sounds to me more like that you have a 6" composite metal door 
protecting your jewelry store, designed by the best specialists in the 
industry, which is quite effective at keeping the thieves out. Provided, 
of course, you remember to lock it; and don't leave the combination 
written on a post-it note that you can read from the window; and get rid 
of the plywood door on the back; and read the letters from the 
manufacturer when it tells you to install a more recent one (and then 
actually doing it); whilst knowing perfectly that it will stop the local 
burglar, but not a M829 sabot fired from the army.

-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20190916/14a0aa41/attachment.bin>