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-requ...@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.dang...@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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
