[Interest] Clarification on network security

Konrad Rosenbaum konrad at silmor.de
Sun Jun 16 13:41:05 CEST 2019


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

Wow! This is exactly how much your entire "advice" is worth.


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

More information about the Interest mailing list