Instructor: In this lesson,
we will learn about certificate validation.
Certificate validation with the public key infrastructure,
or PKI architecture,
ensures that a digital certificate remains trustworthy,
is unexpired and has not been revoked.
Certificate validation concepts
include online certificate status protocol stapling,
the certificate revocation list,
and certificate pinning.
Online certificate status protocol
or OCSP stapling is a method of validation
that requires a server to provide a digitally signed proof
of its certificate's validity directly to the client.
Next, the certificate revocation list
or CRL is a list maintained by a certificate authority
that contains the serial numbers of certificates
that have been revoked before their expiration dates.
Finally, certificate pinning involves storing a known
valid certificate or public key in an application.
Let's learn more
about online certificate status protocol stapling,
the certificate revocation list
and certificate pinning.
First, we have the online certificate status protocol,
or OCSP and OCSP stapling.
The online certificate status protocol
or OCSP is a protocol used
to verify the revocation status
of a digital certificate using its serial number.
Unlike checking the certificate revocation list
or CRL, which is a comprehensive list
of revoked certificates,
OCSP efficiently checks the status
of a specific certificate without needing to download
and parse an entire revocation list.
Instead, the server responsible
for providing this status update
is called the OCSP responder,
and it replies with whether the certificate is valid,
revoked, or unknown.
To demonstrate this, imagine you are visiting a website
and your browser needs to ensure
that the website's security certificate is still valid
and it hasn't been revoked.
Traditionally, it would check a certificate revocation list,
which is essentially a long deny list
of invalid certificates.
However, this approach can be slow
because your browser has to download
and then search through a potentially very large list.
Instead, with OCSP, your browser sends a quick request
to the OCSP responder asking specifically
about the certificate for the website you're visiting.
The OCSP responder checks the certificate status
and responds with whether it is valid, revoked,
or unknown, making the verification process much faster
and more efficient.
Next, OCSP stapling enhances this process
by allowing the server rather than the client browser
to handle the certificate status checks.
Day to day, the web server periodically retrieves
a digitally signed response from the OCSP responder
about the certificate status,
and includes this response
during the secure socket layer transport layer security,
or SSLTLS handshake.
This stapled response improves the security
and speed of the connection setup
by eliminating the need for the client
to make a separate OCSP request.
To demonstrate this,
imagine you're visiting the same website,
but this time with OCSP stapling in use.
Instead of your browser making a separate OCSP request
to the OCSP responder,
the web server hosting the site
takes care of this step in advance.
The server periodically fetches a status update
about its own certificate from the OCSP responder
and obtains a digitally signed response
confirming the certificate's validity.
When you connect to the website,
the server staples this assigned response
to the SSLTLS handshake,
essentially presenting the proof of validity
directly to your browser.
This process means your browser does not need
to make a separate request to verify the certificate status,
speeding up the secure connection setup,
and enhancing privacy,
since the browser isn't making separate calls
that could reveal which sites you are visiting.
Next, HTTP Strict Transport Security or HSTS
is another mechanism used to secure web traffic.
HSTS configures the web server to instruct browsers
to connect only using the secure HTTPS protocol, never HTTP.
When a browser initially connects,
the server responds with a strict transport security header,
specifying that the browser should only use HTTPS
for all future connections to that site
for a set period of time.
This protects against attackers who may attempt
to exploit insecure HTTP connections
through on-path attacks.
Although some websites use a 301 redirect
to transition from HTTP to HTTPS,
this approach is less secure than HSTS.
This is because a 301 redirect
allows an initial HTTP connection,
whereas HSTS directly enforces secure connections
without intermediate steps, providing stronger protection.
Additionally, browsers can maintain an HSTS preload list
of domains that should always be accessed securely,
ensuring these sites are only ever reached out to
via HTTPS enhancing overall security.
Second, we have the certificate revocation list or CRL.
When a digital certificate is issued in the PKI system,
it comes with an expiration date,
just like a driver's license,
which is valid for a certain number of years.
Once your driver's license reaches its expiration date,
it's automatically considered invalid.
But what happens if you get too many speeding tickets
before that date?
Your license could be suspended or revoked,
even though the physical license in your wallet
still shows it's valid until 2029
or whatever the expiration date is.
To handle this,
police don't just check the expiration date
on your license when they pull you over,
instead, they check your license against a central database
to see if it has been suspended or revoked.
If it has, you could be arrested
and your car might be towed,
because you are driving without a valid license.
Digital certificates work in a similar way.
They have a set expiration date,
but they can also be revoked at any time
before that date by the certificate authority
that issued the certificate for various reasons.
For example, if you work for Dion Training
and we issue you a digital certificate,
but then you leave the company for another job,
we would revoke your certificate
because you no longer need access to our systems.
Or if you digital certificate was compromised,
we would also revoke it, but we would issue you a new one.
Common reasons for certificate revocation
include cessation of operation
or the business stops operating,
a certificate authority compromise,
a key compromise, certificates being superseded,
or other reasons.
Also, sometimes instead of fully revoking a certificate,
it could be temporarily suspended.
For example, suppose we issued smart cards to each employee
with their digital certificates embedded into the card.
If an employee reported that their card was lost,
but thought it might just be misplaced at home,
we could suspend their card for let's say 72 hours
to give them time to find it.
During the suspension, the card
and its certificates won't work.
If they find the card within 72 hours,
we would reinstate the certificates
and they could continue working with that card.
If not, we will revoke certificates
and issue new ones along with a new card.
So the key difference between suspension
and revocation is that suspension can be reversed,
but revocation cannot.
To manage revocation
and keep track of certificate statuses,
certificate authorities use a certificate revocation list
or a CRL.
The CRL is an online list
that shows all certificates revoked
by that certificate authority,
whether it was due to compromise, suspension,
or some other reason.
This list is distributed to all subordinate
and intermediate certificate authorities
within the hierarchy.
When your device tries to validate a digital certificate,
it first checks the expiration date of the certificate.
If the certificate has expired,
it's automatically considered invalid.
If it hasn't expired,
the system can check the certificate revocation list
to ensure the certificate is still valid
and hasn't been revoked, assuming of course
that the certificate revocation list is up to date.
Third and last, we have certificate pinning.
Certificate pinning is a security technique used
to protect applications and users from on-path attacks.
Certificate pinning involves
storing a known valid certificate
or public key directly within an application.
When the application tries to establish a connection
with a server, it compares the stored certificate
or key with the one presented by the server.
If they match, the connection is considered safe
and the certificate is accepted.
The key idea behind certificate pinning
is to bypass the usual certificate authority hierarchy
and the standard chain of trust.
Normally, when you connect to a secure website,
your browser or application relies on a chain of trust
involving the server certificate,
intermediate certificates
and a root certificate authorities.
Without pinning,
an attacker could exploit this chain by inserting a fake
but technically valid certificate into the connection
using it on-path or man-in-the-middle attack.
This means that even though your connection appears secure,
an attacker could be listening in
or manipulating the data that's being exchanged.
For example, imagine your connecting to your bank's website.
Normally, your browser checks their website's certificates
against trusted authorities to ensure it's genuine.
However, if an attacker manages to insert a fake certificate
that looks valid, your browser might unknowingly accept it,
allowing the attacker
to intercept your sensitive information like usernames,
passwords, or credit card details.
Certificate pinning was one of the first methods developed
to prevent this
by hard-coding the correct certificate public key
into the application itself.
Next, HTTP Public Key Pinning or HPKP,
is a form of digital certificate pinning
that was used by websites
to tell browsers which public key should be trusted.
The website, which send a list of its trusted public keys
as part of the HTTP header to the client.
If the client's browser then connected to the website
and the presented public key
didn't match any of the stored ones,
the browser would know the connection was compromised
and would alert the user.
This added an extra layer of security
by ensuring that only specific trusted keys
could be used even if a certificate authority
was tricked into issuing a fraudulent certificate.
However, over time, attackers discovered ways
to exploit vulnerabilities
in the HTTP public key pinning process,
and it became clear that this technique
could cause significant problems if misconfigured,
like permanently blocking users from accessing a website
if the pinned keys were lost or rotated incorrectly.
So HPKP has been deprecated.
So remember, certificate validation
in the public key infrastructure system
ensures that digital certificates remain trustworthy,
unexpired, and not revoked.
This involves several techniques
including online certificate, status protocol,
or OCSP stapling,
certificate revocation lists, or CRLs,
and certificate pinning.
OCSP stapling allows a server
to provide a digitally signed proof
of its certificate status directly to the client,
making the validation process faster and more secure.
Next, the certificate revocation list is maintained
by certificate authorities to keep track of certificates
that have been revoked
before their expiration dates,
ensuring that devices can identify
and reject invalid certificates.
And finally, certificate pinning enhances security
by storing a known valid certificate
or public key within an application.
So, directly comparing it to the one presented
during a connection, a browser can prevent on-path attacks.