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.
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
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
More
https://www.semrush.com/blog/https-a-modern-false-sense-of-security
"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.
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
https://www.ftc.gov/enforcement/cases-proceedings/refunds/equifax-data-breach-settlement
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?
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. 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."
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.
https://krebsonsecurity.com/2014/02/target-hackers-broke-in-via-hvac-company/
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.
https://thehackernews.co/complete-penetration-testing-hacking-tools-list/
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
(630)-205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
