Yet another intro to TLS

,
1

TLS is a protocol for secure communications over a computer network (Wikipedia).

The core problem that TLS is addressing is:

How can two distant, total strangers immediately start exchanging private information securely, over a public, insecure network?

Unfortunately, the answer is, they cannot:

  • They first need to share some information (secret password) to be able to encrypt/decrypt their messages.
  • But they are total strangers who “just met”, so they do not share any information.
  • They cannot derive the secret password from common knowledge: the secret must be knowable only to the two parties. Otherwise, anyone could derive the secret just as well.
  • They cannot generate a random password and share with each other “just once at the beginning” because someone could be listening all along.

Fortunately, if they do have some previous information in common, then they certainly could start communicating securely.

After years of R&D and production use, the information strangers now have in common in order to be able to have secure communication is digital certificates, issues by certificate authorities that everyone trusts and respects.

As time goes by and more and more sophisticated tools become available for attackers, more and more sophistication is introduced to authentication processes in order to guarantee communications remain secure.

Authentication processes are complex in order to circumvent known attacks.

How is a so-called “certificate” of any help?

Certificates, signatures, SSH keys and many other things, rely on a brilliant invention called public-key cryptography.

In public-key cryptography we have means to quickly generate a “key pair” - a “private” key and a “public” key.

  • When we generate a key pair, either one could be the private/public. We arbitrarily choose one of them to become the private and the other the public.
  • A 1:1 match between the two keys is guaranteed mathematically.
  • It is practically impossible to calculate one key from the other, i.e. by knowing a public key it is practically impossible (with the tools we currently have) to figure out the private key.
  • Common tooling generates a key and a key.pub files. The .pub file is the public key. The other file contains both the private and the public key, but is simply called the “private key”.

If you keep your private key safe (i.e. no one but you has access to it), then you can share your public key with the world, and they can use it to send you encrypted message that only you can decrypt. In other words, there is an inherent asymmetry in the abilities the public key holders and the private key holder have:

  • Holders of your public key can encrypt, but once encrypted, it is impossible for them to decrypt. Anyone can freely download your public key and use it to encrypt sensitive information before sending it to you, and no one in the world but you would be able to decrypt it.
  • Only the other key in the key pair (the private key) can decrypt the message.
  • If you encrypt your reply with the private key, only your public key could decrypt it. Sending out messages encrypted with your private key does not compromise the private key.

The above, on its own, is not sufficient: an eavesdropper could still decrypt everything the private key holder (server) sends out to its clients, because the public key is publicly available, and can decrypt messages that were encrypted by the private key.

For this reason, the client too must use a key pair:

  1. The client generates a key pair.
  2. The client encrypts their public key with the server’s public key, and sends it to the server. (We call the new key the client sends to the server “public”, but it is not shared with anyone but the server.)
  3. The server decrypt the message with its private key and thus obtains the client’s “public” key.
  4. The server can now encrypt any follow-up messages with the client’s public key.
  5. The client decrypt the message from the server using the server’s public key, thus obtaining a second encrypted message, which they now decrypt with their own private key.

However, the process described above – asymmetric encryption – is too heavy computationally to be used for each and every message. Instead, the client and the server only initiate a secure channel using the asymmetric encryption described above. During the initiation – the TLS handshake – they exchange a newly generated symmetric password that is known only to them.

Currently, the state-of-the-art is to use an asymmetric key (computationally heavy) to exchange a symmetric key (less heavy computationally).

But, the above, on its own, is not sufficient: in a machine-in-the-middle (MITM) attack, an impersonator could eavesdrop by piping all communications through their own set of keys. And that’s where certificates come into play.

  1. Globally trusted “certificate authorities” (CA) publish their public keys in a special format that is called a self-signed “root” certificates.
  2. Operating systems and browsers are shipped with those public keys (certs, really) baked-in.
  3. Servers officially register with a certificate authority. This allows the server to obtain a globally-recognized “certificate”, signed by a certificate authority. The certificate is the server’s public key, encrypted with the CA’s private key. (Encrypting with one’s private key is called signing.)
  4. The client, having CA certs (public keys) statically available, verifies the certificate sent by the server by attempting to decrypt it.

A MITM attack is prevented because no eavesdropper has the CA’s private key. Without the CA’s private key, they cannot sign (encrypt) their own impersonating key as a MITM substitute for the original (server’s) key.

Examples

Generate an elliptic curve P-256 key pair

# https://smallstep.com/blog/everything-pki/
openssl ecparam -name prime256v1 -genkey -out k.prv
openssl ec -in k.prv -pubout -out k.pub

curl --insecure

curl --insecure is needed when:

  • remote server uses a self-signed certificate; or
  • you did not install a CA cert store; or
  • the server uses a certificate signed by a CA that is not included in the store you use; or
  • the remote host is an impostor impersonating your favorite site

(Source: SSL Certificate Verification, curl.se)

Download the CA cert of a particular server

openssl s_client -showcerts \
  -servername charmhub.io -connect charmhub.io:443 \
  | openssl x509 -text

Partial list of lightweight certificate authorities

References

10 Likes