On Thursday, 13 June 2019 14:39:48 PDT Steve Atkins wrote: > 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).
Right. There are three factors to security: authentication, authorisation and encryption. TLS by itself performs the encryption for you and QSslSocket will default to high security, leaving it to OpenSSL to negotiate which cipher to use. The only thing I recommend about encryption is to make sure your OpenSSL installation does not enable weak ciphers. Or you can change the cipher list in your server application too. But encryption alone isn't sufficient. Encryption prevents snooping by third parties and secures the communication between you and the end point. You need authentication to guarantee that the end point is who it says it is. Usually, servers authenticate themselves to clients -- that's how you know that yourbank.com is your bank, not a phishing scam. Client authentication, like Steve says, is rare, but you may want to do that if you need to ensure that only trusted clients are allowed to continue. A client certificate may replace a password. Authorisation is the verificatiton that the peer is allowed to perform the action that they are requesting to add. This is up to your application. > 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. You *can* do TLS without certificates on the server, but it's really weird. As I said above, you want to authenticate one or both sides. Self-signed certificates are fine, no MITM attacks, provided that the other side has that certificate to compare to. After all, self-signed is like a CA depth of 0 and you need the CA to certificate for verification anyway. What you can't do is ignoreSslErrors(). > 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. I recommend EasyRSA to manage this: https://github.com/OpenVPN/easy-rsa That's what I use for my OpenVPN, as my laptops and my phones have clients to connect back to my router. This uses a mutual authentication support (both client and server certificates). > 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). Good point. Requiring your users to install your CA certificate system-wide is a security risk because if your CA files are compromised, the attacker can impersonate any website and the clients will trust that. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
