Cryptography Reference
In-Depth Information
code in the signature won't match the hash code of the contents of the certifi cate,
and the client rejects it on this basis.
So, at a bare minimum, in order to protect yourself against man-in-the-middle
attacks, you need a trusted CA and a certifi cate format that includes the domain
name, the public key and a digital signature issued by the CA. Now, imagine
that a few years go by, and the administrator of the server fi gures that it's time
to reissue the certifi cate. After all, technology changes, and certifi cate security
holes are found from time to time. And who knows? Some hacker could have
broken into the system and stolen the private key without the administrator's
knowledge.
Unfortunately, the administrator can't reissue the certifi cate. Assuming that
there's a problem with the certifi cate — the private key has been compromised
or the certifi cate technology is outdated and includes a security fl aw — and the
server installs a new certifi cate, the man in the middle strikes again. When the
client tries to connect, the attacker substitutes the old, and presumably weaker,
certifi cate for the new one. The client has no way to authenticate this certifi cate;
the domain is correct, and so is the issuer's digital signature.
To partially guard against this, certifi cates also include a validity period :a not
before date and a not after date. It's the responsibility of the client to check that
the certifi cate's not after date does not fall in the past. If the date is in the past,
the client should not connect to the server.
As you can imagine, this is really only half a solution. Imagine that the pri-
vate key has been compromised and the server administrator knows that the
private key been compromised. He should immediately stop allowing use of
the compromised certifi cate. The validity period guarantees that clients stop
using the certifi cate at some point in the future, but you really want a way to
accelerate that date. Again, that can't be forced, because a man in the middle
can just replace any new certifi cate with an old one, right up until the end of
the validity period.
To fi ght against this, CAs are responsible for keeping a list of revoked certifi cates
that is called a certifi cate revocation list (CRL). The client periodically checks this
list. But wait — checks it for what? How can you uniquely identify a certifi cate?
As they've been specifi ed so far, you can't; you need one more fi eld in the cer-
tifi cate format, the serial ID . This is a number, unique within a CA, assigned to
each certifi cate. When a certifi cate is known or believed to be compromised,
its serial number is added to the CRL. If the man in the middle tries to replace
a new certifi cate with an old one, the client recognizes that the serial number
has been revoked and rejects the connection.
Finally, it's unlikely that everybody on the Internet will use a single CA. That
means that the client, when presented with a certifi cate, needs some way to know
whose public key to use to verify the signature. As such, each certifi cate also
includes an issuer that uniquely identifi es the CA. The client decides whether
or not to trust the issuer dynamically.
Search WWH ::




Custom Search