Hi,
[Congrats Roland: successful flame bait accomplished!]
Bob, you already have really good answers from Elvis and Thiago - please
ignore this thread! In short: use QSslSocket/QSslServer, set the
protocol version to 1.2 or newer, deliver the server cert (not key) with
your client software, authentication depends on your use case. Ask
specific non-Qt questions on https://security.stackexchange.com/ .
[Warning: this mail may contain traces of bad language.]
On 6/16/19 2:16 AM, Roland Hughes wrote:
On 6/14/19 5:00 AM, Bob Hood wrote:
1. By itself, is the implicit use of OpenSSL by the QSslSocket class
on the
server side sufficient to secure data communications between both
endpoints?
The short answer is no. Sadly, it is what you will find in most places.
Neither TLS nor SSL are secure nor can they ever be. They are
architecturally flawed. You can pull down software from The Dark Web
which when run on a hokey little $80 2-in-1 sold by Walmart can, in 15
minutes or less, unpackage anything sent via SSL and caught via most
forms of sniffing. In well under an hour using the same hokey laptop
it can penetrate pretty much any SSL/TLS secured access point.
This is complete and utter bullshit! Unless by "hokey little 2-in-1" you
mean a major compute cluster (like a sizeable portion of the entire AWS
system), by "15 minutes" you mean several days or weeks and by
"anything" you mean encrypted with relatively weak keys on a SSL v3
connection with unfortunate settings.
The real question is what are you securing?
A chat engine? Who cares? People on those things routinely give out
their mother's maiden name, name of their first pet and the closest
relative living farthest from them. In the immortal words of Ron White
"You can't fix stupid."
Also nonsense. Just by communicating via chat doesn't mean you are
stupid. (The presence of A does not prove the absence of B.)
The level of security must go up with the level of value. The flip
side of this is the openness of access must go down.
You cannot have anything called "secure" on the Internet accessible
via a standard browser. This is why many banks and brokerage firms are
moving to 2-stage connection verification and custom browser plug-ins.
Also quite naive, I won't even bother to comment - it would take too long.
Cats have better ideas on cat food than... ;-P
2-stage is really (*^)(*&)ing annoying, but if you have an account
enabled for wire transfer or any other Internet access which could
pull money out, it really is the way to go. The 2-stage is you do your
normal username/password/verification question on each login, then you
prompt them to choose email or phone for an N-digit one time code.
Once they enter it you drop a short life cookie (sometimes one
connection, other times one day, never more than a week) which lets it
work for a little while.
The 2-stage is the industry finally admitting SSL/TLS are
architecturally flawed and can never be made secure.
You do realize that it is called "2nd factor authentication" or "two
factor authentication", not "2-stage" - right?
It has absolutely nothing to do with SSL/TLS.
Moving up in security you create a plug-in for popular browsers
(Firefox/Chrome/Opera) on popular platforms (Linux/Android/forget
about security on Windows). After a user has created an account with
you they must be on a supported platform and install the browser
plug-in to continue.
Also nonsense. No plugin is required for most 2nd factor auth. Even
U2F/WebAuthn is built into major browsers these days.
Honestly, you can make it a plug-in or you can make it a stand alone
app. If all you are using is SSL/TLS it isn't secure, you just
protected their password a touch better.
The plug-in/app works old school, like you are used to. Data is both
shuffled and encrypted before transmission. If you are using only one
encryption method with only one seed for the life of the connection,
consider yourself hacked before they installed the app/plug-in.
You can use standard 3rd party encryption libraries, but what you
cannot have are any two packets encrypted with both the same seed and
encryption method. Yeah, they are going to sniff your packets. Yeah,
there are all kinds of free tools on the Internet to peel that SSL
right off there. After that, they have to start from ground zero with
every packet. The biggest flaw in old school data transmissions was
the single-method-single-key for entire file or comm session. Evil
doers only had to crack one packet for the rest of them to be easy as
knocking over dominoes. Some of the older encryption libraries even
left tell-tale signatures in the encrypted packet so at a glance they
could tell what method was used. Making it an exercise of just finding
the proper seed. When you have a million PC bot-net at your disposal
it generally takes more time to distribute the work than it does to
get the answer.
Still, you are talking nonsense. Your critique sounds like it could
apply to some forms of ancient CBC mode implementations or certain
ancient stream ciphers, but it doesn't really.
Before anyone thinks "Oh, it's only email," think again. In order to
gain access to much larger and more secure companies, hackers are
targeting the emails of their mom & pop service providers.
[crap deleted]
Now you are mixing in social engineering... yay!
Just my 0.002 cents.
[sarcasm]
Wow! This is exactly how much your entire "advice" is worth.
[/sarcasm]
Roland, please keep your hands off security consulting - you'll go
bankrupt or cause someone to do so. (Sorry for the harsh language, but
security is a very harsh business.)
regards, Konrad
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
