We all use SSL or TLS every day. But how does it work and what infrastructure is involved? For the rest of the article, I will be referencing both SSL and TLS but will be using the blanket term “TLS” to refer to both.

Certificate Infrastructure

Root CAs

Trusted root CAs are organizations that have protocols in place to issue certificates at different levels. They are audited regularly and comply to ISO standards. A list of all root CAs that have completed these requirements are provided and updated regularly by most operating systems:

Intermediate CAs

More often than not, certificates used on the internet are not issued by a root CA, but instead from an intermediate CA. One of the many reasons is that if the intermediate CA were to be compromised, the root CA can issue out a revocation that tells clients not to trust any certificate by that intermediate CA. There can be multiple levels of intermediate CA’s underneath a root CA.

Issuing CAs

Just as root CAs generally don’t issue client certificates, intermediate CAs don’t have to issue client certificates either. When a CA starts issuing certificates to clients, it is called an issuing CA.

CDPs and CRLs

The CDP (CRL distribution point) is a network location that is stamped on to a certificate when it is issued from a CA. It contains one or many CRLs (certificate revocation list). A CRL is a file that the client reads to see if any issued certificates have been revoked. CRLs in the CDP are usually updated automatically by the CA software itself. The exception to this are root CAs, which are generally kept offline. This CRL needs to be updated manually and transferred from the airgapped system to the CDP accessible by clients on the internet (or network, if it is LAN CA). There can be a CRL and multiple delta CRLs, which contain changes in between CRL refresh periods. This helps to keep download sizes minimal.

OCSP

OCSP (Online Certificate Status Protocol) is a great alternative to CRLs. The OCSP responder server URI is stamped on to the certicate when it is issued from the CA. When the client needs to check the status of a certificate, it sends the serial number of the certificate to the OCSP responder to check if it is still valid. The server then responds with the status. It uses much less bandwidth than a CDP with CRLs and delta CRLs.

Microsoft AD CA Infrastructure

Best practice guidance from Microsoft suggests the following infrastructure:

  1. A non-domain joined standalone root CA. Once it has issued a certificate to the intermediate CA, it is to be shut down and only powered back on to update its CRL.
  2. A domain-joined intermediate CA. This is integrated with Active Directory and issues certificates from certificate templates. It can also act as a CDP and OCSP responder for all clients, but it is generally better to split these roles out to other servers. Usually the CA stores the CDP data in AD as well as a file share and website, for maximum availability.

Certificate types

There are three different types of certificates, each with different levels of trust and verification.

Domain Validated certificates

This is the base type of certificate. All that is usually needed to verify ownership of the domain is to add a TXT record, or click on a link sent to admin@domain.com. Whilst the encryption being used can be the same as the higher certificates, the level of trust may be low.

Organization Validated certificates

This certificate type requires further verification. Normally it requires an exchange of physical documents to prove ownership of the business that the domain name is representing.

Extended Validation certificates

This certificate has the highest level of trust. When applied to a website, users’ web browsers show a green bar. It has the following requirements:

  1. Establish the legal identity as well as the operational and physical presence of website owner.
  2. Establish that the applicant is the domain name owner or has exclusive control over the domain name.
  3. Confirm the identity and authority of the individuals acting for the website owner, and that documents pertaining to legal obligations are signed by an authorised officer.

It is not currently possible to get a wildcard EV certificate - it is just for the domains in the certificate request.

Certificate structure

A certificate contains the following information:

  • Serial number - This is unique to the CA and is used to tracl revocation information.
  • Subject - The entity that the certificate belongs to. This can be a user, device, or organization.
  • Issuer - The issuer of the certificate, who verified the information within.
  • Not Before - The earliest time at which the certificate can be considered valid.
  • Not After - The latest time at which the certificate can be considered valid.
  • Key Usage - The valid cryptographic uses of the certificate’s public key. This can include digital signature validation, key encipherment, etc.
  • Extended Key Usage - The applications the certificate can be used for. This can include code signing, email signing, etc.
  • Public Key - The public key for the certificate subject.
  • Signature Algorithm - The algorithm used to sign the public key certificate.
  • Signature - A signature of the certificate body by the issuer’s private key.

Encryption types

Symmetric

Symmetric encryption is used when both parties have the same encryption key.

Asymmetric

Asymmetric encryption is used when both parties have different encryption keys. This is more commonly called public/private key encryption. The keys are generated at the same time. Anything encrypted with the private key can be decrypted by the public key, and vice-versa.

Anatomy of a TLS handshake

TLS uses a combination of both asymmetric and symmetric encryption whilst communicating.

Negotiation

  1. The client sends a ClientHello message to the server, which specifies the highest TLS protocol it supports, a random number, a list of ciphers it supports and a list of compression methods it supports.
  2. The server sends a ServerHello message to the client, containing the TLS protocol, compression method and cipher from the lists sent from the user, as well as a random number. The server may also send a session ID, however this is not mandatory.
  3. The server may also send both a Certificate (which contains the public key of the server, and is verified by a third-party) and a ServerKeyExchange message, depending on the cipher suite. The server can also send a CertificateRequest message if mutual certificate authentication is being used.
  4. The server sends a ServerHelloDone message, to show it is done with handshake negotiation.
  5. The client sends a Certificate message (if mutual certificate authentication is being used).
  6. The client sends a ClientKeyExchange message, which contains either a PreMasterSecret, public key, or nothing. It is encrypted with the public key of the server certificate.
  7. The client sends a CertificateVerify message, which is a signature for the previous client handshake messages and is generated using the client private key. It can be verified with the client public key.
  8. The client and server use the shared random numbers and PreMasterSecret to generate a common shared secret. This is called the master secret. All future data is encrypted with this secret and a psudorandom function.

ChangeCipherSpec

  1. The client sends a ChangeCipherSpec message. This lets the server know that the cient will only talk in that cipher for the rest of the session.
  2. The client sends a Finished message that contains a hash of all the previous handshake messages. If this fails at the server end, the TLS connection is not considered valid and will be torn down.
  3. The server sends a ChangeCipherSpec message. This lets the client know that the server will only talk in that server for the rest of the session.
  4. The server sends a Finished message that contains a hash of all the previous handshake messages. If this fails at the client end, the TLS connection is not considered valid and will be torn down.

The handshake is now complete and now that both ends have the same master secret, they can switch to symmetric encryption, which is computationally much less expensive.

TLS Versions

TLS versions and ciphers are independent of certificates, and can be changed at any time on the server. This may have implications with client support, however nearly all modern clients have support for TLS 1.2 (the latest version as of this blog post).

  • SSL 3.0

SSL 3.0 was first introducted in 1996. It has been depreciated by the IETF since 2015 and is not considered secure. It should no longer be used, as it has been broken due to multiple vulnerabilities (POODLE, DROWN, etc).

  • TLS 1.0

TLS 1.0 supports downgrade negitiation, allowing an attacker to bring the server back down to SSL 3.0, and therefore bringing the vulnerabilities with it. It should also no longer be used. It does however allow the use of better ciphers than SSL 3.0

  • TLS 1.1

TLS 1.1 should be considered the bare minimum for TLS-protected communications. No protocol-level vulnerabilities have been found so far. It provides protection against padding errors (the basis of the POODLE attack).

  • TLS 1.2

TLS 1.2 is the newest TLS protocol, introduced in 2008. It is currently the strongest TLS protocol.

  • TLS 1.3

TLS 1.3 is currently a working draft with the IETF and is not released for general use yet.

Ciphers

Along with the TLS protocol version, the client and server also negotiate a cipher to communicate with. The ciphers considered secure change as cracking technology progresses and vulnerabilities are found.

I’ve found that https://cipherli.st/ is a great resource for server cipher list configuration, and https://www.ssllabs.com/ssltest/ is great for testing your site.