Tech

Networking Security Part 2: Verifying and Connecting

28. May 2021

Welcome to the second article of a series of three, about the subject of security in networking applications, TLS, certificates, keys, and more.

In the first part, we learnt about TLS/SSL, certificates, CAs and Keys. If you haven’t read it yet, please do so now.

Now that we know all about the pieces of the puzzle, how do they all fit together? Let’s have a closer look!

Issuing Certificates

To begin with, we need to obtain a certificate. The process works something like this:

First, we need a public/private key pair. With it, we can now create a new CSR (short for “Certificate Signing Request”). The CSR contains all the details we want to include in the certificate (the “Subject”) as well as the public key. We then send the CSR to the CA (the “Certificate Authority”).

The CA then verifies the contents of our CSR, and signs it with their own certificate and private key. This results in a new certificate with the details from our CSR, its “Issuer” field set to the “Subject” of the CA’s certificate, and our public key embedded. The CA then sends the new certificate back to us.

And that’s it! We now have a certificate that is signed by the CA, and we have the accompanying private key. We can now install the certificate in our web server.

Establishing Connections

The whole purpose of certificates and keys is to create secure channels through which devices can exchange information, without the risk of snooping by third parties. In other words, security experts call this “being able to send secrets on a postcard”, and all things considered, the analogy is quite appropriate.

So, how do we establish a secure connection with SSL? The following things are required:

  1. A (web) server with:
    • A CA certificate;
    • A server certificate;
    • And a server certificate key (with its corresponding passphrase).
  2. And a client (usually a web browser) with a list of trusted CA certificates.

With all this in place, we can establish a trusted, secure connection between both:

  1. The client opens a TLS connection to the server.
  2. The server responds with its certificate.
  3. The client verifies that the server certificate was indeed signed by a trusted CA.
  4. The client verifies that the server certificate’s CN attribute (part of the “Subject”, remember?) matches the requested URL.
  5. The client verifies that the server certificate is not expired.
  6. The client can optionally check that the server’s certificate has not been revoked, either by using a CRL (a “Certificate Revocation List”), or a mechanism like OCSP (an “Online Certificate Status Protocol”).

After these steps, the client has established an encrypted connection, and verified that the server it is connected to is indeed the one it claims to be.

The client and the server can now exchange data securely with one another, without the risk of a third party being able to read their interactions, or even worse, manipulating them!

Client Certificates

There is however another use case for certificates, and that is Client Authentication. Remember how in the example above the server’s certificate was used to verify its identity? This works the other way around too!

If we have a client certificate that is signed by a CA known to the server, we can establish a mutually trusted, secured connection.

To achieve this, we need the following things:

  1. A server with:
    • A CA certificate;
    • A server certificate;
    • And a server certificate key (with its corresponding passphrase).
  2. A client with:
    • A CA certificate;
    • A client certificate;
    • And a client certificate key (again, with its corresponding passphrase).

Once all the things are in place, a mutually trusted, secured connection can be established:

  1. The client opens a TLS connection to the server, sending its certificate.
  2. The server responds with its own certificate.
  3. The client verifies that the server certificate was indeed signed by a trusted root.
  4. The client verifies that the server certificate’s CN attribute matches the requested URL.
  5. The client verifies that the server certificate is not expired.
  6. The client can optionally ensure the server’s certificate was not revoked.
  7. The server verifies that the client certificate was indeed signed by a trusted root (our CA certificate in this case).
  8. The server verifies that the client certificate is not expired.
  9. The server can optionally ensure the client’s certificate was not revoked.

After these steps, both client and server have established an encrypted connection, one in which both parties are who they claim they are. The server can now read the client’s certificate details (mostly the Subject) to identify the client.

And just like previously, our connection is now fully encrypted and all communications flowing through it are confidential.

Coming Up

In the last part of this series, we are going to talk about some technical details about chains, roots, and intermediates. Stay tuned!

Manuel Hutter

Manuel Hutter is a DevOps engineer in VSHN.

Contact us

Our team of experts is available for you. In case of emergency also 24/7.

Contact us