Oof, this got REALLY long. TL;DR: read the below stuff until you reach the horizontal line. The rest breaks down each of your confusions or misconceptions in sequence, and goes into far more detail.
Short answer: The purpose of the "public key infrastructure" (PKI) where trusted CAs issue certificates is so that you agent X can verify that agent Y is the legitimate owner of a certificate that claims to belong to Y. In particular, PKI lets arbitrary agents X and Y do this, without needing to do something inconvenient and non-scalable (like each X gets all Y's keys ahead of time through some other channel and hard-codes all agent<->key mappings in their software). It also serves other purposes, like providing a channel to revoke compromised certs (and issue new ones that are automatically trusted).
So long as you
- trust the CA to have verified Y's identity and to not issue a fraudulent certificate
- trust Y to not have leaked their private key
- trust your certificate validation code to work correctly
- trust your list of trusted CAs (usually provided by the OS or client software) to not be maliciously tampered with
then you can trust that any certificate which passes validation really does contain the right public key for its identified owner.
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.
No. You don't need CAs for that; even a self-signed certificate reveals tampering (or corruption) of just the public key, subject name, validity, etc. Of course, if the client doesn't know what public key to expect, an attacker could replace the certificate's public key with their own and then replace the (self-)signature with one from their corresponding private key. The certificate signature would once again be valid, just not from a trusted signer (and therefore not really trustworthy). This is why self-signed certificates are generally not accepted.
However, the primary purpose of the CA remains "be a way for an agent (in this case, the client) to trust that the public key in the certificate belongs to the agent (server) identified in the certificate". Obviously as a corollary to this, the method of transmitting this information (the certificate itself) needs to be possible to verify the authenticity of (it wouldn't be any good if the message [certificate] couldn't be verified to have originated at the CA), so that's why the CA signs the certificate with its own private key.
FireFox extracts public key from acme.cert and saves it as acme.pub.
No, although it could. The public key is usually only used once during the handshake, and small enough to easily keep in memory for that time. Once the handshake is done, the key - and the rest of the certificate - can be forgotten (though in practice it won't be so long as the tab is open).
FireFox encrypts all information with acme.pub before sending it to acmecorp.com.
No. Not only would this be catastrophically slow - public key encryption is far, far slower than asymmetric encryption - it would only protect the data going from the client (Firefox) to the server, not the data coming back (the client usually does not present any public key, in or out of a cert, to the server). Besides, some public key algorithms don't even support encryption, only signing!
Instead, the public key is used to authenticate a key exchange, whereby both client and server come to know a random symmetric key (actually a set of them) for algorithms like AES-256, without any way for an eavesdropper to learn them. The simplest such key exchange - but also the least-secure still widely supported, and in fact rapidly becoming unsupported - is for the client to generate a random value, encrypt it with the server's public key (this would be the only time the client actually need's the servers public key), and transmit it; this is how RSA key exchange works. Nearly all key exchanges these days are instead based on ephemeral Diffie-Hellman algorithms (specifically ECDHE, "elliptic-curve Diffie-Hellman ephemeral") which provide a valuable property called "perfect forward secrecy" that RSA exchange lacks. Rather than the client encrypting anything to the public key, the server signs its [ephemeral] public [EC]DH parameter - or, in TLS 1.3, signs the entire handshake - with its private key, and the client uses the public key to verify the signature before transmitting any user data.
The exchanged symmetric keys are used to encrypt (and authenticate) each message, using a cipher such as AES or ChaCha20. Messages are either authenticated using HMACs with SHA2 algorithms (legacy behavior, only up to TLS 1.2) or authenticated encryption (first available in TLS 1.2, required in TLS 1.3). Symmetric encryption/decryption and authentication code generation/verification is vastly faster than asymmetric (public key) encryption/decryption or signing/verification, even for much stronger key strengths. It's also potentially more secure against future attacks such as using quantum computing (though that wouldn't help if the key exchange is compromised).
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.
Correct (aside from all the ways that your understanding of how TLS encryption works are wrong; see above), assuming that Firefox doesn't already know what public key to expect for acmecorp. In practice it almost never does - a very small number of critical sites have "pinned" public keys, but most rely entirely on PKI - so this is correct.
As a side note, there's no reason at all for Hacker to "replace the contents of acme.cert with the contents of hacker.cert", as that implies that Firefox is talking to acmecorp.com at all. Rather, the attacker usually just impersonates the target server, becoming the destination point for the TCP/IP connection over which TLS is used (this is generally possible any time the attacker could instead modify traffic in transit). Hacker then presents its own certificate - which fraudulently identifies itself as acmecorp.com - to Firefox, and (optionally, if needed) can open its own connection as a client to acmecorp.com for relaying the user's data back and forth. This is what's called a "man [or monkey] in the middle" (MITM) attack.
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.
Not really. As mentioned above, the signature alone does that, so long as you know what key to expect signed the certificate and trust that key's owner (which in the usual case is a CA, but in self-signed certificates is the cert owner). The CA provides client applications (and sometimes servers and many other things that consume certificates) the ability to trust that the public key in the certificate belongs to the agent identified in the certificate. Since it does so via the certificate's signature, this also means that the certificate can't be tampered with (even in ways that don't affect the public key or owner) or spoofed.
TLS Creation Process 1. - 4.
Generally correct, though you need not use OpenSSL specifically. At least some browsers actually have the ability to generate key pairs and CSRs built into them, and there's lots of other cryptographic tools that can do it stand-alone or as part of another program.
Also, that's not creating TLS, that's creating a certificate for use in TLS via a certificate authority. Certificates are used for many things besides TLS (and indeed, you can use TLS without certificates). Certificates can also be created without the use of a CA (self-signed certificates; as mentioned above these are not usually trusted because the recipient needs to already know what public key to expect - which largely obviates the point of the certificate - or else trust that the transmission is genuine for some other reason).
- CA does DNS checks to ensure AcmeCorp does own the domain acmecorp.com. If checks fail, then abort process.
That's one way to do it, though it's relatively weak. The domain registrar doesn't necessarily validate your identity when you register a domain name, and sometimes doesn't reveal the domain owner's name anyhow. I probably couldn't get a registrar to believe me that my identity is "Google, subsidiary of Alphabet corp" but you don't want to rely on the registrar to get that right. Besides, what about cases where the domain is "superuser.com" but the owner is "Stack Exchange Inc"? How would the CA know that the latter owns the former?
Instead, there's various other ways of identity validation that CAs use, depending on how careful they're being (and how much money/hassle the requester wants to expend). For example, the CA might give you a random unique string that you're supposed to put in your DNS entry or host on your website at a known location, as proof that you own the domain (and the server at the domain's IP). This is not very strong, but it's easy to automate. Or the CA might require you to submit legal proof of ownership of the domain and legal proof of your own identity and manually verify that those match, perhaps while checking the relevant public records in the process; that's way more effort and can't really be automated the same way, but can't be spoofed by an attacker spoofing the victim site's DNS records or planting a file somewhere via some vulnerability in your server.
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.
Conceptually false but mathematically correct for the specific case of RSA keys. The fact that in RSA, the operation "sign" is the same as the operation "encrypt" just performed with the private key instead of the public key does not mean encryption and signing are the same thing. The security considerations are quite different, and non-RSA algorithms don't even work that way (some don't support encryption at all)! Don't ever think of "encrypt" as a thing you can do with a private key. Note that RSA is slow and requires gigantic key sizes to achieve acceptable levels of security; as a result, it's being slowly phased out. Also, "digest" as a noun in the context of cryptography just means "what you get when you hash (verb) something" or "the output of a hash algorithm"; this is related to the more general concept of a digest (noun) as "a summary of one or more longer messages, with the details removed", see also "gloss" (explanation, paraphrase, or interpretation of a message) or "gist" (the essential part of the message).
TLS verification 1. - 4.
Broadly correct again, though this is specifically only certificate signature validation. For TLS validation, you also have to validate things like "the entity identified in the certificate is the one I expect" (otherwise I could get a perfectly valid cert for cbhacking.com and use it to MitM your connections to Google.com) and "the certificate is allowed to be used for this purpose" (generally Server Identification and Digital Signature). Indeed, this isn't even enough to verify the certificate in general (only its signature), for verifying the validity of a certificate you also need to verify things like "is after the 'valid after' date but not yet expired" and "has not been revoked".
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.
Again, mathematically correct in the specific case of RSA, but conceptually wrong. "Decrypt" is not a thing public keys can do, because "decrypt" means "reveal a secret message" and since anybody is allowed to see a public key and therefore could do this operation, and the "secret message" in this case is a hash of a publicly-available data blob, so it really isn't a "secret" at all, is it?
5.2 FireFox uses the ca.pub to sha256 hash temp-cert.pem of TLS certificate to create another message digest.
Wrong, though close. SHA2-256 is an unkeyed hash function; there is nowhere in the process of using it that the CA's public key (or any other key, except for the one embedded in the rest of the certificate and treated as undifferentiated data) would be used. However, yes, for verifying an RSA signature, the verifier re-hashes the message original with the same hash algorithm.
- 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.
Or just fraudulent to begin with (e.g. the attacker forged it entirely, but of course couldn't generate a valid CA signature because the attacker doesn't have the CA's private key) and being spoofed. MitM attacks sometimes don't involve the client actually interacting with the real server in any way at all!
Again though, this process is just validating the certificate's signature; there's a bunch of other checks that you need to perform to validate a full TLS handshake. Also, if the client (Firefox) didn't know to expect a CA's signature, or if an attacker were able to slip their own public key into the "trust store" (list of trusted CA public keys), then the attacker could potentially have signed the certificate with their own private key and this would be accepted as valid (though in practice, Firefox throws a fit about self-signed server certificates, and rightly so).
Final Questions - Did I mis-understand anything? Specifically: 1. Did I mis-understand the main goal(s) of a Certificate Authority? 2. Did I mis-understand how the Certificate Authority achieves its goals?
You misunderstood a number of things, as mentioned above, including the distinction between what the purpose of the signature on a certificate is in general, the purpose of CAs in the certificate ecosystem (PKI), and the exact process CAs use for identity validation and sometimes the process for signing (though CA certs do often still use RSA keys, since CAs don't rotate the certs very often and RSA used to be the best available algorithm).
Does anything I've said change between TLS1.2 vs. TLS1.3? I think everything I've said so far applies to TLS1.2
Nothing you've said is actually specific to TLS (any version) at all! Well, except for the "server sends its certificate to the client" (correct) and arguably the "client encrypts everything with the server's public key" (which is completely wrong for all TLS versions, and every other use of certificates that I know of). Certificate signature validation is a critical part of the security of TLS, but it's not even sufficient for certificate validation in general, much less certificate validation in the context of TLS, never mind the other security guarantees of TLS!
But no, none of the stuff you got right is different between TLS 1.3 and any earlier version; the creation and use of certificates has not changed between versions (aside from differences between versions regarding ways to use TLS without certificates at all, which TLS used to have a number of insecure options for though thankfully almost nothing allowed them).
public keys in TLS certificates are used for generating symmetric keys in the Diffie-Hellman algorithm as opposed to being used for encrypting information.
Once again, wrong but kiiiind of close. You can't use a public key to generate DH keys/parameters, at least not in any useful way; they're generated from a secure random number generator using an algorithm specific to the key type, same as for any other key pair. Furthermore, both client and server must generate such [EC]DH pairs. In TLS 1.2, the server signs its [EC]DH public key with its private key before transmitting it, and the client verifies the signature on that key (to prove that the server has the corresponding private key, and that a MitM hasn't modified or spoofed the [EC]DH public key) using the server's signature from its certificate. In TLS 1.3, the same general thing holds except the server signs the entire handshake, not just its side of the key exchange; this prevents an attacker from tampering with any portion of the TLS handshake at all.
Additionally, the use of [EC]DH key exchanges isn't new to TLS 1.3, or even to TLS at all; for example, SSL_DHE_DSS_WITH_DES_CBC_SHA is a SSL 3.0 (precursor to TLS 1.0) cipher suite. It uses ephemeral integer (non-EC) DH key exchange, with DSA-SHA1 (Digital Signature Standard) signatures to authenticate the server and key exchange (that is, the server certificate contains a DSA public key, which can't be used for encryption at all, only verifying DSA signatures).
This cipher suite is weak in a number of ways:
- DSS is deprecated (partially because it uses the broken SHA1 and specifies a too-weak key strength for DSA, but integer DSA in general is also deprecated, replaced be ECDSA, EdDSA, and especially Ed25519)
- integer DH is on its way out, replaced by ECDH
- DES is too weak to use for anything anymore, even its upgraded form triple-DES still uses relatively weak keys and dangerously short block sizes, but single-DES keys are now easy to break due to hardware advances since they were standardized; it's been replaced mostly by AES but sometimes other block ciphers, plus various modern stream ciphers
- CBC mode (and other non-authenticated modes) is on its way out, replaced by authenticated encryption ("AEAD", Authenticated Encryption with Associated Data) modes, most commonly GCM though there are others that have some advantages vs. GCM
- SHA1 is broken, and while the specific use here - HMAC-SHA1 - is probably still safe for most purposes, there's just no reason to use it anymore even if for some reason you're still using a non-authenticated encryption mode
plus SSL 3.0 itself is a flawed and obsolete algorithm (among other things, unspecified behaviors meant that compliant implementations could be vulnerable to padding oracle attacks when using block ciphers like DES, 3DES, or AES in modes such as CBC). However, this deeply obsolete cipher suite does at least use ephemeral key exchange to provide perfect forward secrecy!
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.
Basically right, though for the wrong reason. If the certificate's signature was invalid or generated by an untrusted signer, you couldn't be sure what the server's public key was (that being the thing CAs are for). In that scenario, an MitM attacker could present their own [EC]DH public parameters, signed with their own private key, to the client, and the client wouldn't know that they weren't actually the server's public parameters. If the client used the attacker-generated parameters to complete the [EC]DH key exchange, then they would have exchanged symmetric keys with the attacker, not with the server, and the attacker could thus decrypt all messages that the client sent (and encrypt+authenticate responses to the client in the way the client expects).
