ELI5: If SSL encrypts traffic, why does it expire?

Question

SSL, nowadays TLS, encrypts traffic between the server and client. However, the certificate is only valid for a certain period of time until its expiration.

What I don't understand is, why does TLS even expire in the first place? Its purpose is to encrypt traffic. If I had a Domain named example.com with SSL/TLS set up, the secure connection is first initialised using a TLS handshake. Once the keys have been exchanged, the connection is encrypted and sensible information can be transmitted. Cant this behavior been achieved without global CAs? Why do certificates even need to be trusted/validated when only a key exchange between X & Y is desired/required for transmitting encrypted data.

Is validation and expiration required due of man in the middle attacks or DNS hijacking? I cant find proper, easy to underetand and transparent answers on the web. It seems like SSL/TLS developed that way "AS IS" without a background to why expiration and CAs exist.

Answer 1

Certificate expiration is a security feature.

Over time, domains can change ownership, private keys can be compromised and certificates can be fraudulently issued. These events mean that we no longer want the certificate to be recognised as valid.

Historically, certificate revocation processes have been weak, although OCSP stapling has improved this.

For these reasons, having relatively short validity periods is helpful. The usual recommendation is 90 days.

As to why we need CA's, this is for authentication purposes.

Without a CA, you can have a key exchange process, but you don't know who you completed the key exchange with. It could be the legitimate site, or a MITM hacker. The certificate proves that you completed the key exchange with the valid owner of the domain.

Answer 2

Your confusion is likely due to a misunderstanding (or at least, incomplete understanding) of what certificates are for. Yes TLS encrypts traffic between you and the server, but you can do that with just raw keys; you don't need the extra info in a certificate.

A certificate is an assertion from a trusted third party that that the holder really is who they say they are. For instance, this site presents a certificate from Let's Encrypt that says that the holder of its corresponding private key really does control the stackexchange.com domain. You (or at least your browser or OS vendor) trust Let's Encrypt to only issue certificates to the real owner of a domain (and they have strict compliance and auditing requirements to maintain that trust), and so you can trust that anyone who has a certificate for stackexchange.com really is the owner of that domain.

But just because that's the case now doesn't mean it always will be. StackExchange could be breached and the private key stolen. Or they could go bankrupt and not be able to continue paying for the domain registration. In those cases we would want the certificate to become invalid somehow since its assertion that the holder of its private key owns stackexchange.com is no longer true. There are ways to revoke a certificate, but they rely on someone taking explicit action.

But what if the private key leaks and the owner doesn't find out about it? Or a domain registration lapses and the new owner doesn't know what certificates were obtained by the old owner? In those cases, you need some mechanism for the old certificates to automatically become invalid. That's where having an expiration date helps. A private key that was stolen by a bad actor or simply retained by a previous owner automatically becomes useless after some time.

Answer 3

Basically it's so that certificate revocation lists don't grow forever.

When a certificate is compromised it is put on a revocation list so that the compromised cetificate can't be used, in particular so that it can't be used to impersonate the owner.

If certificates lasted forever then the revocation list would grow forever and put an increasing burden on user's systems.

By expiring certificates there is no need to retain the revocation list entries forever, they only need to be remembered until the certificate expires.

Answer 4

CAs and certificates aren't strictly necessary for TLS. They're by far the most common approach, but there are indeed alternatives.

When you perform a TLS handshake to set up a secure connection with example.com, then you generally want to make sure that the cryptographic parameters you're receiving (e.g., for a Diffie-Hellman key exchange) do in fact come from example.com. If you don't ensure this, then you still end up with a secure connection, but you have no idea if you're actually communicating with example.com. It might as well be a man-in-the-middle attacker who just pretended to be this website, injected her own parameters and can now read every request meant for example.com.

So an anonymous key exchange isn't very helpful. You need to make sure that the parameters actually belong to example.com and not a man-in-the-middle attacker.

The typical way to achieve this is to use a CA as a trusted third party. The server generates a key pair, sends the public key to the CA and proves that it controls the server behind example.com (or the domain itself). In return, the CA issues a signed certificate which cryptographically binds the public key to the domain name example.com. It's now possible for the server to sign their cryptographic parameters, and the client can verify the signature with the public key in the certificate.

The reasons for keeping certificates short-lived have already been explained by paj28, so I'm not going to repeat them.

However, as already mentioned in the beginning, certificates and CAs aren't strictly necessary. There are several other options.

• If you can establish keys before the TLS connection, then you could use pre-shared keys or raw public keys. Neither require a certificate or a CA.
• Public keys can be distributed through the Domain Name System, e.g., using DNS-based Authentication of Named Entities (DANE). Note that current browsers don't implement DANE (and probably won't in the near future).
• You could use the trust-on-first-use approach (TOFU). When you initially connect to a server, you could simply accept the (raw) public key you get back and trust this key from now on. Of course this means the initial connection will be vulnerable to man-in-the-middle attacks, and it's your responsibility to keep the key up to date in case it's compromised or changed for other reasons.

Plenty of other approaches have been proposed, but those are mostly experimental and haven't gained too much attraction.

Answer 5

Why Do SSL/TLS Certificates Expire?

1. Replaces compromised certificates If an attacker has gotten access to the certificate, then they can keep using it to MITM or for DNS Hijacking. But when the certificate expires, and a new one is used, the attacker can no longer do these malicious things, because they don’t have the new certificate.
2. Implementing new cryptographic updates If a new cryptographic update is needed, then the only way to do this is to get a new, updated certificate. And to do this, the first one needs to expire.

This is quite an important point, and I think it is important that

Why do SSL/TLS Certificates need CA validation?

The role of CAs for SSL/TLS is vital. According to the official SSL website above, a CA’s digital certificate provides:

“Integrity of documents signed with the certificate so that they cannot be altered by a third party in transit.”

This is one of the main reasons that Cas are needed so bad. CAs are an independent party, who won’t be biased so therefore won’t modify the certificate in transit.

It would not be in a CA’s best interests to tamper, because they would face legal penalties, and lose business.

Although, it’s important to note, that not all big CAs can be trusted, also depending on your country of residence.

Powerful governments have been known to use CAs of their jurisdiction for bad.

Answer 6

Firstly, it's misleading to describe a certificate as “its purpose is to encrypt traffic”. Its purpose is to protect traffic, but not by being the key used to encrypt it.

A certificate comprises (among other things) an asymmetric key pair. Using this key pair to encrypt & decrypt network traffic would be awkward for a variety of technical reasons, but if you managed to jury-rig things to use one of the keys in a certificate to encrypt traffic, you would run up against a more fundamental problem: to be useful as a certificate, one half of its key pair has to be made public, and the other half must never be.

As a result, your jury-rigged encryption would only be useful in one direction:

• traffic encrypted with a public key would only be readable by the end holding the corresponding private key; and conversely
• encrypting traffic with a private key would be pointless (anyone holding the corresponding public key could read it).

You could of course work around this shortcoming by having a separate key pair for each direction, but nobody does that in practice, mostly because asymmetric encryption algorithms are far more costly than symmetric ones.

Rather, traffic is exchanged over a session protected by a symmetric cipher, whose key is ephemeral - it exists only for the duration of that session.

The certificate comes into play when proving the identify of (one of) the endpoints; in doing so it offers a secondary proof against a MITM attack.

As for why certificates expire: any certificate should have a limited lifetime because:

1. over time there is an ever-increasing (cumulative) risk that the devices holding a private key may be compromised (and you can't use a compromised key to distribute its own replacement);
2. they may be weakened (or completely defeated) by advances in cryptanalysis;
3. an attacker might just get lucky and guess the key; and
4. they will eventually be threatened by Moore's Law.

A certificate's lifetime is set such that there's an extremely small chance of any of these happening before it expires.

The same arguments for key apoptosis apply equally to symmetric encryption key and private keys, but ephemeral symmetric encryption keys generally have lifetimes that are many orders of magnitude shorter than certificates, so a more significant worry is that encrypted streams might be recorded by an eavesdropped and then decrypted using new cryptanalysis techniques possibly many years later.

Answer 7

In a nutshell, SSL provides both encryption and authentication. The expiry is not related to or caused by the encryption, but rather the authentication.