[Interest] Clarification on network security

Thiago Macieira thiago.macieira at intel.com
Fri Jun 14 01:36:52 CEST 2019

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).


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

More information about the Interest mailing list