The Role of Certificates

Sean Wright

This guest blog is part of a series and was created in partnership with F5.

CSR, PEM, DER, X509… it’s no wonder that certificates are often seen as some type of magic.

The very first time that I had to get a certificate working, I had no idea what I was doing! I aimlessly copied a bunch of commands and hoped that they worked. But when it comes to security, expecting someone to blindly copy commands is a risky thing to do. None more so than certificates.

Certificates are the cornerstone of TLS (and most commonly HTTPS, which utilises TLS) connections. Get this wrong, and you open yourself up to the risk of the connection being intercepted by an attacker (effectively negating the protection that the TLS connection provides).

This blog is part of a series that will uncover the role of certificates and especially certificate management. In the first part, we will explore the purpose of certificates and why they play an important role in securing connections (namely TLS connections).

Guaranteeing confidentiality and establishing integrity

When a client connects to a server there are two security principles that we need to consider.

The first is confidentiality. This is critical so the data transmitted to and from the client is not visible to anyone outside of that traffic. A login page is a good example. We want to ensure that the username and password that you enter are not visible to anyone when they are transported with the server that you are trying to log in to. It is also worth noting that confidentiality plays into the privacy aspect as well, preventing prying eyes from looking into what actions or information you are viewing.

The second principle is integrity. This is one that many people forget or are not aware of when it comes to TLS. By integrity, we mean that no one can tamper with the data that is being transmitted to and from the client. Even if the resource is public, we still want to ensure the integrity of this data.

Consider a publicly accessible news site. We aren’t too concerned about the confidentiality aspect (apart from privacy, but for this example let’s put that to the side) since this page is publicly available. However, we want to make sure that the data sent to the client (a user’s browser) from the server has not been manipulated. Without considering the integrity of a server, an attacker could edit the content of a news article (think fake news), or inject malicious content onto the page, such as a Browser Exploitation Framework hook.

The importance of certificates

So, where do certificates play a role in all of this? When a client connects to a server, they need to ensure that it is first connecting to the intended server. Not a server that an attacker has mimicked. We also want to guarantee that the connection is encrypted end-to-end. By this, we mean that the connection hasn’t been terminated somewhere to allow for traffic inspection and modification, and forwarded on to the original server. This is referred to as a machine-in-the-middle attack.

Now to be clear, there are valid use cases for this, especially in a corporate environment where internet traffic is often inspected to help improve the security of the organisation. This is where certificates come into the picture. When a client connects to a server of TLS, the server will have to provide its (server) certificate to the client. The client will then validate this certificate to ensure that it belongs to the correct server that the client was originally attempting to connect to. Once this has been established—a part of the TLS handshake—communications between the client and server can commence.

In the next part of this series I’ll continue exploring this topic on my own blog. There, we will cover the process of validating certificates. This is where we will delve into the human side to certificate management and its importance.

Until then, I highly recommend please that you check out an informative F5 myForum session (Be Prepared for the Changing SSL Landscape) from David Warburton and Nigel Ashworth. It's a great overview of the continually evolving SSL and TLS landscapes, and is well worth your time.

Sean Wright is an experienced application security engineer who started out as a software developer. He is primarily focused on web-based application security, with a special interest in TLS and supply chain-related subjects. Sean is also experienced in providing technical leadership in relation to application security, as well as engaging with teams to improve the security of systems and applications that they develop and maintain. You can read his blog here.

About the Author

Sean Wright

More blogs by Sean Wright