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.
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
