Problem - Kevin Tafuro

• Provide the user with some way to add the CA’s certificate to a list of trusted certificates.
This is certainly a good idea, and any program that verifies certificates
should support this capability.
• Prompt the user, asking if the certificate is acceptable. If the user answers yes,
the certificate should be remembered, and the user is never prompted again.
This approach could conceivably be something of an automated way of performing
the first solution. In this way, the user need not go looking for the certificate
and add it manually. It is not necessarily the most secure of solutions, but for
many applications, the risk is acceptable.
Prompting the user works for other things besides certificates. Public keys are a good
example of another type of identifying information that works well; in fact, public
keys are employed by many SSH clients. When connecting to an SSH server for the
first time, many SSH clients present the user with the fingerprint of the server’s key
and ask whether to terminate the connection, remember the key for future connections,
or allow it for use only this one time. Often, the key is associated with the
server’s IP address, so if the key is remembered and the same server ever presents a
different key, the user is notified that the key has changed, and that there is some
possibility that the server has been compromised.
Be aware that the security provided by this recipe is not as strong as that provided by
using a PKI (described in Chapter 10). There still exists the possibility that an
attacker might mount a man-in-the-middle attack, particularly if the client has never
connected to the server before and has no record of the server’s credentials. Even if
the client has the server’s credentials, and they do not match, the client may opt to
continue anyway, thinking that perhaps the server has regenerated its certificate or
public key. The most common scenario, though, is that the user will not understand
the warnings presented and the implications of proceeding when a change in server
credentials is detected.
All of the work required for this recipe is on the client side. First, some kind of store
is required to remember the information that is being presented by the server. Typically,
this would be some kind of file on disk. For this recipe, we are going to concentrate
on certificates and keys.
For certificates, we will store the entire certificate in Privacy Enhanced Mail (PEM)
format (see Recipe 7.17). We will put one certificate in one file, and name that file in
such a manner that OpenSSLcan use it in a directory lookup. This entails computing
the hash of the certificate’s subject name and using it for the filename. You will
generally want to provide a verify callback function in an spc_x509store_t object (see
Recipe 10.5) that will ask the user whether to accept the certificate if OpenSSLhas
failed to verify it. The user could be presented with an option to reject the certificate,
accept it this once, or accept and remember it. In the latter case, we’ll save the certificate
in an spc_x509store_t object in the directory identified in the call to spc_
x509store_setcapath( ).
Minimizing the Window of Vulnerability When Authenticating Without a PKI | 439
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.