Problem - Kevin Tafuro

You can use a whitelist in place of normal certificate verification routines. Whitelists
are most often useful in servers that want to authenticate clients, rather than the
other way around, but they can be used either way. In server mode, you can use the
SSL_VERIFY_PEER flag to request a certificate from the client, but remember that the
client does not have to supply a certificate in response to a request. If you want to
require that the client respond, you also need to use the SSL_VERIFY_FAIL_IF_NO_
PEER_CERT flag so that the connection is terminated if the client does not send a certificate.
The downside to using these flags is that OpenSSLwill attempt to verify the certificate
on its own. With a little trickery, we can short-circuit OpenSSL’s certificate verification
routines and do a little post-connection verification of our own. We will do
this by setting up a verify callback function that always returns success. The verify
callback is called for each certificate in the chain when verifying a certificate. It is
called with the X509_STORE_CTX containing everything relevant, as well as a boolean
indicator of whether OpenSSLhas determined the certificate to be valid or not. Typically,
the callback will return the same verification status, but it is not required. The
callback can reverse the decision that OpenSSL has made.
int spc_whitelist_callback(int ok, X509_STORE_CTX *store) {
return 1;
}
Once the connection has been established, we can get a copy of the peer’s certificate,
compute its fingerprint, and compare it against the fingerprints we have in our
list. The list can be stored in memory, in a disk file, on a flash memory card, or on
some other medium. How the list is stored is irrelevant; what is important is the
comparison of fingerprints. The functions shown in the previous code are flexible in
that they allow you to choose any message digest algorithm you like. Note, though,
that if you are always using the same ones, the functions can be simplified, and you
need not keep track of the fingerprint length because you know that a message digest
is a fixed size (MD5 is 16 bytes; SHA1 is 20 bytes). The following snippet of code
roughly demonstrates the work that needs to be done to employ whitelist-based certificate
verification:
int fingerprint_length;
SSL *ssl;
EVP_MD *digest;
SSL_CTX *ctx;
unsigned char fingerprint[EVP_MAX_MD_SIZE];
spc_x509store_t spc_store;
spc_init_x509store(&spc_store);
spc_x509store_setcallback(&spc_store, spc_whitelist_callback);
spc_x509store_setflags(&spc_store, SPC_X509STORE_SSL_VERIFY_PEER |
SPC_X509STORE_SSL_VERIFY_FAIL_IF_NO_PEER_CERT);
ctx = spc_create_sslctx(&spc_store);
/* use the ctx to establish a connection. This will yield an SSL object */
cert = SSL_get_peer_certificate(ssl);
546 | Chapter 10: Public Key Infrastructure
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.