The Beginning:

If you were around for the early days of the internet, you can remember the awe of navigating through dozens of websites and chatrooms. Getting recommended new sites from friends you just made and having the ability to connect with dozens, if not hundreds of new individuals daily. While amazing, the early days definitely had some glaring flaws, there were no standards for websites and user security was almost non-existent.

The Solutions:

Transport Layer Security (TLS) utilizes public-key cryptography, also known as asymmetric cryptography, a method of encrypting data using a public key that can only be decrypted with its corresponding private key. Holding a public-private key pair allows you to securely communicate with others by distributing your public key. With the exclusive possession of the private key, it is ensured that only you can decrypt messages encrypted with your public key. If a message or file is cryptographically signed with your private key, the user can verify with the corresponding public key that it originated from you.

SSL/TLS offers three essential security functions:

  1. Encryption – Protecting information or data.
  2. Integrity – Verification that the data has not been forged/altered.
  3. Authentication – Enabling one or both parties to confirm their identity.

PKI (Public Key Infrastructure) is a framework that consists of policies and procedures that are used to manage digital certificates and public key encryption.

Let’s take a look at some of the main components of PKI:

  • Certificate Authority (CA): A trusted and highly reputable entity that issues, signs, and stores digital certificates. Digital certificates can only be revoked by their original CA.
  • Registration Authority (RA): An authority within the network that verifies the identity of the entity requesting a digital certificate. Sometimes the CA can act as the RA.
  • Certificate Database: All certificates issued by the CA is stored in here, this includes the metadata within the certificates and how long they’re valid for.
  • Central Directory: All public keys are stored here and indexed.
  • Certificate Policy: Policy outlines of the PKI procedures, used to determine the PKI’s level of trustworthiness.

You can read more about PKI HERE.

What is an SSL/TLS Certificate and how does it work?

They are a form of digital certificate that websites use to establish secure connections between the user and website using the SSL/TLS protocol. This happens through something called the TLS/SSL Handshake:

  1. The client sends a “Client Hello” message to the server, which contains their SSL/TLS versions and cipher suites.
  2. The server responds with a “Server Hello” message to the client, this contains their SSL/TLS versions and a selected cipher suite from the client.
  3. The server will then send its SSL/TLS certificate to the client.
  4. The client validates the server’s certificate and will then generate a pre-master secret, encrypting it with the server’s public key and sends it back.
  5. The server will then decrypt it with its own private key and generates a session key for the user, thus authenticating and establishing a secure connection.

What’s contained within an SSL/TLS Certificate?

  • Public Key
  • Domain Name
  • SSL/TLS Version
  • Issued Date and Expiration Date
  • Certificate Authority Name & Signature

It sounds great, but what are the downsides?

While SSL/TLS certificates are the gold standard when it comes to security and data integrity, it’s not without its pitfalls. There are a number of common vulnerabilities that you’ll need to look for:

  • Certificate Name Mismatch: When the common name which is assigned to the certificate doesn’t match the name displayed in the URL bar.
  • Internal/Alternatives Names: Certificates should not contain any internal network information; this is considered a leak, and internal names cannot be externally verified.
  • Monitoring: Certificates do have an expiration date and need to be monitored and renewed on time.
  • Misconfigured Fields: Certificates with empty or missing fields and values.
  • Outdated SSL/TLS Version: There should not be any SSL use or TLS 1.1 – 1.2, certificates ideally should use TLS 1.3.

So now what?

Now that we have a general understanding of how SSL/TLS certificates work, we can look into exploiting these vulnerabilities. I will be posting a new blog next month going over sslyze and its capabilities.