Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Development Tools >

Construct secure networked applications with certificates, Part 4

Authenticate clients and servers, and verify certificate chains

By Todd Sundsted, JavaWorld.com, 04/13/01

  • Print
  • Feedback
.

Page 2 of 5

For a client to authenticate a server, the server must complete a task that only it can complete, and the client must be able to verify that operation. To do that, both the client and the server use the public-key cryptography operations that I discussed in Part 1.

After a client connects to a server, it sends a block of data to the server and asks the server to digitally sign the data with its private key -- an operation that only the server should be able to do -- assuming that its private key hasn't been compromised. The server responds with the digital signature, and the client, using the public key stored in the server's certificate, verifies the server's digital signature. Authentication is complete.

Not quite. In many situations it's possible that the client and server have not been introduced previously, and therefore, the client won't have the server's certificate in its possession. If this is likely to be a common scenario, the server can return its own certificate along with the signature in its response.

If the server supplies a copy of its certificate to the client, the application becomes susceptible to what is known as a man-in-the-middle attack. In this attack, a malicious third party sits between two communicating parties and, to each party, masquerades as the other party. To defend against this attack, you must verify that the supplied certificate belongs to the party to which you intend to communicate.

In no event should the server be allowed to sign data it generates itself and then return both the data and the signature to the client for verification. While not obvious, that approach is susceptible to what is known as a replay attack: a malicious third party intercepts the data and the signature and subsequently uses them to authenticate itself as the original server.

Let's talk about how to verify the supplied certificate in order to protect against these attacks.

Certificate verification

The most obvious way to verify a certificate is to compare the name in the certificate (the DN, or distinguished name, in X.509 -- although sometimes the subjectAltName extension is used as well) with the name of the party with which you intend to communicate. Unfortunately, this simple approach features a snag: anyone can generate a certificate that contains a public key and an arbitrary name. How do you verify that the public key in the certificate actually belongs to the entity named in the certificate?

A certificate contains at least three pieces of information:

  • A name
  • A public key purportedly belonging to that name
  • A third party's signature indicating that the third party believes the certificate's information to be truthful


Therefore, to verify the certificate, you must validate the third-party signature on the certificate.

But what's to prevent the unknown server from impersonating a third party and signing the certificate? Nothing. However, you can reject certificates signed by anyone but a small group of trusted entities known as certificate authorities, or CAs (see Part 1). If you know the CA's public key -- because you have a copy of its certificate -- you can verify the CA's signature on the certificate and gain some assurance of its accuracy.

  • Print
  • Feedback

Resources