[Interest] Clarification on network security

Bob Hood bhood2 at comcast.net
Thu Jun 13 19:50:09 CEST 2019

I've specialized in client/server solutions in my career, stretching all the 
way back to System V sockets on real, pre-Linux UN*X system, and culminating 
with today's Qt release.  In that time, I've never really been concerned 
with--nor implemented--anything but internal, home-grown security (e.g., 
encoding/encrypting data at the software layer /before/ passing it to the 
socket).  I looked for "dummy" guides on using SSL-based communications, but 
they all seem to be Apache- and CA-centric in their approaches.  If I may, I'd 
like to call upon the brain trust here to provide some guidance on securing 
communications that don't necessarily fall within the Apache/Web Server solution.

Given the following hypothetical scenario:

    Server: Custom Qt-based back-end linked with the current version of
    OpenSSL using QSslSocket for incoming connections.
    Client: PC or mobile, which may or may not be based on the Qt framework.

I have the following questions:

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?  
In other words, would the QSslSocket challenge from the server be recognized 
and responded to by the client if the client were also using just OpenSSL?

2. If OpenSSL alone is not sufficient, is a CA-based certificate 
required/usable in this kind of scenario?

3. If a certificate is required, and both ends are "owned" by the same 
provider (i.e., I wrote the software at both ends), would a self-signed 
certificate be sufficient for securing communications between the endpoints?

Pardon my ignorance if any of these questions don't make sense. That's why I'm 
asking.  :)

I appreciate any personal insights or edifying links.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20190613/3b706a87/attachment.html>

More information about the Interest mailing list