I believe my question will be a continuation of questions such as:
What's the point of the CA?
How does a digital certificate prove authenticity?
In short, I still don't have a firm grasp on why a TLS certificate signed by a reputable and public Certificate Authority (CA) is "better" than one that is not. I feel like I am not "connecting the dots" on this topic because I'm not seeing step-by-step examples of how a hacker can take advantage of TLS certificate that's not been signed by a CA.
EDIT
Actually, I spent a few days thinking through hypothetical situations. My current understanding is the main problem a CA is trying to solve is to ensure TLS certificates are not tampered with
while in-transit between server and client. Is that correct? Please correct me if I am completely missing the point on what CAs are all about.
Here's a more detailed explanation of what I understand. I'll frame my understanding in the form of Problem and Solution and communicate my ideas with step-by-step demonstrations and use of
pseudo-code.
Problem
A TLS certificate contains a public key and the Subject Alt Name (SAN) or Common Name (CN) of the entity the public key is meant to encrypt information for. The public key is susceptible to being altered while in-transit from server (eg. Apache web server) to client (eg. FireFox web browser) in the form of man-in-the-middle attacks. Undesirable ways a TLS can be altered while in-transit are:
an unauthorized entity can intercept transmissions between server and client and inject a fraudulent public key into the TLS certificate. If client uses fraudulent public key to encrypt information and then clients sends this encrypted information to server, the unauthorized entity can intercept transmissions and decrypt the information with the unauthorized entity's corresponding private key.
network connectivity issues could corrupt the TLS certificate, which could corrupt the public key and make the public key unuseable
To demonstrate this problem, I will use an example:
Assume there are 3 players for our example: AcmeCorp, FireFox web browser, and Hacker.
AcmeCorp is a legitimate company and wants to create a website
https://acmecorp.com
. AcmeCorp wants use a TLS certificate on their website
https://acmecorp.com/
. The website uses Apache Webserver. Apache Webserver needs two files to serve
acmecorp.com
over TLS. The two files required will be
acme.cert
and
acme.key
, which are the TLS certificate and private key respectively. The
acme.cert
contains a public key which can be extracted.
FireFox webbrowser is used by a real human customer. FireFox web browser visits
https://acmecorp.com
. FireFox receives
acme.cert
during TLS handshake. FireFox extracts public key from
acme.cert
and saves it as
acme.pub
. FireFox encrypts all information with
acme.pub
before sending it to
acmecorp.com
.
Hacker wants to steal information between FireFox and
https://acmecorp.com
. Hacker has the files
hacker.cert
and
hacker.key
, which are TLS certificate and private key respectively. The
hacker.cert
will have almost identical information to
acme.cert
, except the public key included in the
hacker.cert
is different from the public key
acme.cert
. The
hacker.key
can be used to decrypt information that's been encrypted by the public key in
hacker.cert
. Hacker wants to intercept transmissions from
acmecorp.com
and replace the contents of
acme.cert
with contents of
hacker.cert
.
As it stands now, it is very easy for Hacker to intercept transmissions from
acmecorp.com
to FireFox and replace the contents of
acme.cert
with the contents of
hacker.cert
. There is no way for FireFox to know if such modifications took place while
acme.cert
was in transit. If FireFox uses the public key from
hacker.cert
, then Hacker will be able to decrypt all of FireFox's transmissions using
hacker.key
.
Solution
The goal of a Certificate Authority is to provide client applications the ability to identify whether TLS certificates were tampered with or altered while in-transit from the server to the client application.
AcmeCorp can offer FireFox a way to verify whether the contents of
acme.cert
was modified by having a trusted third party called a Certificate Authority create the
acme.cert
on behalf of AcmeCorp. The TLS certificate creation process for
acmecorp.com
becomes:
TLS Creation Process
- AcmeCorp owns the domain
acmecorp.com
.
- AcmeCorp uses OpenSSL to create a private key and a CSR. The CSR has a public key, a SAN/CN of
acmecorp.com
and all the meta information to create a TLS certificate for the domain acmecorp.com
.
- AcmeCorp gives the CSR to a CA.
- CA sees that the CSR is for the domain
acmecorp.com
.
- CA does DNS checks to ensure AcmeCorp does own the domain
acmecorp.com
. If checks fail, then abort process.
- CA creates a temporary file called
temp-cert.pem
based on the information of the CSR.
- CA creates a TLS certificate file and digitally signs the TLS certificate with a command like
MakeTLSCert(outfile: 'acmecorp.cert', infile:'temp-cert.pem', hash:'sha256', cakey:'ca.key')
. My understanding of this step is weak, but i'm guessing it is broken down into these steps: 7.1. hash the contents of temp-cert.pem
with sha256 and call the result a message digest. 7.2. encrypt the message digest with CA's private key ca.key
and call the result the CA digital signature. 7.3. concatenate the temp-cert.pem
and the CA digital signature and call this the acmecorp.cert
, which is the TLS certificate.
- CA gives
acme.cert
to AcmeCorp.
Now AcmeCorp can use
acme.cert
and
acme.key
with Apache web server to serve
https://acmecorp.com
over TLS.
If a Hacker tries to perform steps 1 to 8, the hacker will fail at step 5. That is, a CA will see that the hacker does not own the DNS records for
acmecorp.com
. Therefore, the CA will not issue a certificate that has the CA's digital signature.
Next, these are the steps that FireFox will use to identify a legitimate TLS certificate, that is, differentiate between
acme.cert
and
hacker.cert
by inspecting the contents:
TLS verification
FireFox comes bundled with the Public Key of reputable CA. Let's say FireFox has the public key of the reputable CA used in the steps above and it has the file name
ca.pub
. When FireFox visits
https://acmecorp.com
, the following happens:
- FireFox receives TLS certificate.
- FireFox extracts public key from TLS certificate.
- FireFox asks if public key can be trusted. The next step and onwards are meant to answer this question.
- FireFox sees a CA digital signature in the TLS certificate.
- In step 6 of the TLS creation process,
temp-cert.pem
is the first half of the TLS certificate, and the digital signature is the second half. Hence: 5.1 FireFox uses the ca.pub
to decrypt the digital signature which yields a message digest (note, only ca.pub
can decrypt information encrypted by ca.key
). We now have the message digest that made by the CA. 5.2 FireFox uses the ca.pub
to sha256 hash temp-cert.pem
of TLS certificate to create another message digest.
- FireFox compares the message digest of step 5.1 and step 5.2 to make sure they are the same. If they are not the same, then it means the TLS certificate was modified while in transit from
acmecorp.com
to Firefox.
Final Questions
Did I mis-understand anything? Specifically:
- Did I mis-understand the main goal(s) of a Certificate Authority?
- Did I mis-understand how the Certificate Authority achieves its goals?
- Does anything I've said change between TLS1.2 vs. TLS1.3? I think everything I've said so far applies to TLS1.2 . If I were to guess how this applies to TLS1.3, it is that public keys in TLS certificates are used for generating symmetric keys in the Diffie-Hellman algorithm as opposed to being used for encrypting information. Hence, the function of CA digital signatures to allow FireFox a way to verify TLS certificates coming from the server were not tampered with still applies...because incorrect public keys means you are generating the wrong symmetric keys which a hacker can exploit. Is that correct?
Login To add answer/comment