21.03.2013 Views

Problem - Kevin Tafuro

Problem - Kevin Tafuro

Problem - Kevin Tafuro

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

• Provide the user with some way to add the CA’s certificate to a list of trusted certificates.<br />

This is certainly a good idea, and any program that verifies certificates<br />

should support this capability.<br />

• Prompt the user, asking if the certificate is acceptable. If the user answers yes,<br />

the certificate should be remembered, and the user is never prompted again.<br />

This approach could conceivably be something of an automated way of performing<br />

the first solution. In this way, the user need not go looking for the certificate<br />

and add it manually. It is not necessarily the most secure of solutions, but for<br />

many applications, the risk is acceptable.<br />

Prompting the user works for other things besides certificates. Public keys are a good<br />

example of another type of identifying information that works well; in fact, public<br />

keys are employed by many SSH clients. When connecting to an SSH server for the<br />

first time, many SSH clients present the user with the fingerprint of the server’s key<br />

and ask whether to terminate the connection, remember the key for future connections,<br />

or allow it for use only this one time. Often, the key is associated with the<br />

server’s IP address, so if the key is remembered and the same server ever presents a<br />

different key, the user is notified that the key has changed, and that there is some<br />

possibility that the server has been compromised.<br />

Be aware that the security provided by this recipe is not as strong as that provided by<br />

using a PKI (described in Chapter 10). There still exists the possibility that an<br />

attacker might mount a man-in-the-middle attack, particularly if the client has never<br />

connected to the server before and has no record of the server’s credentials. Even if<br />

the client has the server’s credentials, and they do not match, the client may opt to<br />

continue anyway, thinking that perhaps the server has regenerated its certificate or<br />

public key. The most common scenario, though, is that the user will not understand<br />

the warnings presented and the implications of proceeding when a change in server<br />

credentials is detected.<br />

All of the work required for this recipe is on the client side. First, some kind of store<br />

is required to remember the information that is being presented by the server. Typically,<br />

this would be some kind of file on disk. For this recipe, we are going to concentrate<br />

on certificates and keys.<br />

For certificates, we will store the entire certificate in Privacy Enhanced Mail (PEM)<br />

format (see Recipe 7.17). We will put one certificate in one file, and name that file in<br />

such a manner that OpenSSLcan use it in a directory lookup. This entails computing<br />

the hash of the certificate’s subject name and using it for the filename. You will<br />

generally want to provide a verify callback function in an spc_x509store_t object (see<br />

Recipe 10.5) that will ask the user whether to accept the certificate if OpenSSLhas<br />

failed to verify it. The user could be presented with an option to reject the certificate,<br />

accept it this once, or accept and remember it. In the latter case, we’ll save the certificate<br />

in an spc_x509store_t object in the directory identified in the call to spc_<br />

x509store_setcapath( ).<br />

Minimizing the Window of Vulnerability When Authenticating Without a PKI | 439<br />

This is the Title of the Book, eMatter Edition<br />

Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!