[Interest] Clarification on network security
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
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