21.03.2013 Views

Problem - Kevin Tafuro

Problem - Kevin Tafuro

Problem - Kevin Tafuro

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

ent mode, you should always be verifying the server’s certificate. When<br />

operating in server mode, you may not have any use for a client certificate, and<br />

requesting one may cause confusion for users. For example, if an SSL-enabled<br />

web site requests a certificate from a client, the user’s browser may ask the user<br />

for a certificate to send to the server.<br />

SSL_VERIFY_PEER<br />

When the SSL_CTX object is being used in server mode, a request for a certificate<br />

will be sent to the client. The client may opt to ignore the request, but if a certificate<br />

is sent back, it will be verified. If the verification fails, the handshake will be<br />

terminated immediately.<br />

When the SSL_CTX object is being used in client mode, if the server sends a certificate,<br />

it will be verified. If the verification fails, the handshake will be terminated<br />

immediately. The only time that a server would not send a certificate is when an<br />

anonymous cipher is in use. Anonymous ciphers are disabled by default. Any<br />

other flags combined with this one in client mode are ignored.<br />

SSL_VERIFY_FAIL_IF_NO_PEER_CERT<br />

If the SSL_CTX object is not being used in server mode or if SSL_VERIFY_PEER is not<br />

set, this flag is ignored. Use of this flag will cause the handshake to terminate<br />

immediately if the client provides no certificate.<br />

SSL_VERIFY_CLIENT_ONCE<br />

If the SSL_CTX object is not being used in server mode, or if SSL_VERIFY_PEER is<br />

not set, this flag is ignored. Use of this flag will prevent the server from requesting<br />

a certificate from the client in the case of a renegotiation. A certificate will<br />

still be requested during the initial handshake.<br />

Using this knowledge of SSL_CTX_set_verify( ) and the code from Recipe 10.5, we’ll<br />

build a new function, spc_create_sslctx( ), that will create an SSL_CTX object and<br />

initialize it with secure settings. In addition to calling SSL_CTX_set_verify( ), we’ll<br />

disable the SSLv2 protocol, leaving only SSLv3 and TLSv1 enabled. We want to disable<br />

SSLv2 because it is well known to be insecure. It was the first publicly released<br />

version of the protocol and was not designed or adequately reviewed by security<br />

experts before its deployment. SSLv3 was designed and reviewed by security experts,<br />

and it corrects all of the known problems in SSLv2. Finally, we’ll call SSL_CTX_set_<br />

cipher_list( ) to ensure that only secure ciphers will be used.<br />

Before we can build spc_create_sslctx( ), we need to extend and complete the<br />

implementation of the spc_x509store_t object introduced in Recipe 10.5. Some additional<br />

flags are necessary for spc_create_sslctx( ), so we’ll define those first:<br />

SPC_X509STORE_USE_CERTIFICATE<br />

If this flag is set, an SSL_CTX created by spc_create_sslctx( ) will be loaded with<br />

a private key and certificates to be sent to the peer if they’re requested. This<br />

should always be set for a server context, but it may also be set for a client context.<br />

536 | Chapter 10: Public Key Infrastructure<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!