> On Jun 13, 2019, at 6:50 PM, Bob Hood <bho...@comcast.net> wrote: > > 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?
It's all TLS (nee SSL), so it'll all interoperate. You do need to care about what version of TLS it is - higher is better, and you want at least TLS 1.2. QSslSocket is just a Qt-ish wrapper around the protocol and doesn't change anything other than making it (a bit) easier to use with Qt. > > 2. If OpenSSL alone is not sufficient, is a CA-based certificate > required/usable in this kind of scenario? Required on the server side, pretty much, yes. > > 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? Self-signed, no. Signed by a private CA owned by the provider, yes. > > Pardon my ignorance if any of these questions don't make sense. That's why > I'm asking. :) Certificates allow you to know that you're talking to who you think you're talking to. For most uses a server certificate (from a real certificate authority) is what you want so that your client can know that it's talking to the host it thinks it is. Client certificates are much rarer, and are typically only used as a form of authentication (e.g. replacing a username/password pair to identify the client). You can't really do TLS without certificates on the server side, but you can use fake, self-signed certificates. If you do that then TLS will protect the data in transit - but you could be man-in-the-middled by someone, and they could sniff or modify your traffic. That server certificate can come from a regular certificate authority (e.g. letsencrypt) or, if you control both the server and client, you can set up your own certificate authority to issue certificates to your server and arrange for your client to recognize it as a valid CA (and possibly _only_ connect to servers with certs from that private CA). That's reasonably simple to set up, at it's simplest it can be done with a few lines of shell scripts and openssl. Private CAs let you do some nice things in closed systems that communicate across untrusted networks, but you do need to read up on how it works to avoid some security flaws (e.g. putting the certificate for your private CA in the system-wide trust store of your users opens them up to some horrible attacks by anyone with access to your CA, including you). Cheers, Steve _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
