This article is cross-posted from hammo.io.

Trust is very valuable in today’s world. People trust their data with you and in some cases, this means they trust their lives with you. The internet by design is an open and transparent system used to deliver information. This design competes directly with how we use the modern internet today. That is why it is important to understand TLS and implement it on your websites. TLS isn’t just a piece of software, the underlying social architecture that is embedded into the Root CA system gives a user confidence that when they connect to your website, it is actually your website and that their connection is secure.

What is TLS

TLS is basically the “Cone of Silence” for online transactions. TLS enables transactions between two parties (i.e. “You” and “Your Customer”) to be conducted securely. There are two parts to TLS: Public Key Encryption and TLS Communication. Public Key Encryption is the method that is used to encrypt data used in secure communications and TLS Communication refers to the implementation of Public Key Encryption on web servers.

How does Public Key Encryption work?

Public Key Encryption (PKE) solves the problem of how a party can talk to another party without both parties knowing that the communication ahead of time. This is solved using Asymmetric Encryption, which means that the keys used to encrypt and decrypt are different (i.e. “asymmetric”). The two keys are:

1. Private Key: this is the secret key that can be used to decrypt data. In symmetric encryption, this key is used for both decryption and encryption.
2. Public Key: this is a key that is derived from the Private Key. This key is used to encrypt data to prepare it for sending.

In a PKE scenario, the party wishing to receive communications distributes their key, and the party sending information uses that key to encrypt their message. Once they have encrypted the data they can be sure that the data is sent securely to the recipient, even if it is via an insecure communication medium.

Why should you trust Certificate Authorities?

Root Certificate Authorities (Root CAs) are a small list of companies that have been given the right to be pre-trusted by major Operating Systems and Web Browsers. They earn this right by following policies and procedures set forth by vendors. One of the main policies that Root CAs need to abide by is ensuring that the Private Keys for their Root CA are kept safe. Most Root CAs achieve this by issuing Intermediate CA certificates which have shorter life spans, and can be revoked easily by the vendor.

When a user requests a certificate from a CA, they will have to verify that the domain they are requesting the certificate for is theirs. The usually do this via email or DNS records. Once this is confirmed, the CA issues the certificate to the user. From now on, a person connecting to the server using this issued certificate can be sure that the server is actually owned the domain holder. This surety ensures that users are not susceptible to Man-in-the-Middle attacks or other hacks that try to intercept encrypted communications.

Those responsible for managing the lists of trusted Root CAs can take action when a CA is negligent in the undertakings they agree to. Recently, Google decided to revoke some Root CAs controlled by Symantec because of their negligence. This resulted in users seeing the error below when they browsed to websites with untrusted websites. This was the first large-scale punishment against a CA who did not follow the established rules. This reaction gives us faith in the Root CA system.

Caveats

It is important to note that this system doesn’t necessarily verify who a person is, only that they own the domain you are connecting to. It also does not verify that a server hasn’t been compromised. A trusted certificate alone is not enough to verify that a server should be trusted. Examples of scenarios where a trusted certificate will not help:

1. A hacker has compromised a server and is siphoning information on the server and not interfering with the communications between it and clients.
2. A hacker has purchased a legitimate domain and hosts a legitimate certificate. They use this “legitimate” secure server as a platform to perform spearphishing or host spyware.
3. A company has mishandled their private keys and an untrusted third party has used them to create new certificates that can be used on servers not owned by the domain owner.

So, How do TLS, PKE, and CAs work together?

Now that we understand how PKE and CAs work, let’s look at the process a client and server go through to establish secure communications.

1. A client connects to a server and sends it information about the version of TLS it can use.
2. The server responds with instructions on which protocol, cipher, and other methods the client should use to communicate with the server. The server also includes it’s RSA certificate.
3. The client receives the RSA certificate and validates it against it’s Certification Authority (CA) Root Store. This step establishes Social Trust: a trusted entity (Root CA) has vouched that your server is who it says it is.
4. Once the client is satisfied that your server is trustworthy, it generates a temporary key and sends it back to the server using the certificate’s Public Key.
5. The server responds with it’s own temporary key, which has been signed using it’s private key.
6. The client verifies the temporary key it has received from the server by checking the public key against the signed temporary key.
7. Once all of the keys have been verified, communications are now encrypted.

Once this handshake has taken place, your communications are encrypted and all future messages will be sent using the temporary keys.

Not so complicated after all!

That’s a very brief introduction to PKE, TLS, and Root CAs. While I haven’t covered everything, I hope that you now understand why it should be important to you. Activating TLS on your web servers provides:

• Confidence to users that you are who you say you are.
• Secure communications between you and your users.

The best part of it all? You can implement certificates for free on your servers using either Let’s Encrypt or (if you use AWS) Amazon Certificate Manager. If you’d like to read more articles like this, please check out my blog at hammo.io.

References

• https://www.globalsign.com/en/ssl-information-center/what-is-public-key-cryptography/
• https://en.wikipedia.org/wiki/Transport_Layer_Security
• https://security.stackexchange.com/questions/90195/how-ecdhe-is-signed-by-rsa-in-ecdhe-rsa-cipher
• https://security.stackexchange.com/questions/8034/how-does-the-digital-signature-verification-process-work
• https://docs.microsoft.com/en-us/security/trusted-root/program-requirements
• https://www.chromium.org/Home/chromium-security/root-ca-policy
• https://wiki.mozilla.org/CA
• https://www.darkreading.com/endpoint/google-wont-trust-symantec-and-neither-should-you/a/d-id/1328682
• https://security.googleblog.com/2018/03/distrust-of-symantec-pki-immediate.html