[Interest] Clarification on network security

[Konrad Rosenbaum]

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