Renegotiations in 0.9.7 IO on SSL Connections

141 code fragment from Example 5-18 goes here. the new session is made post_connection_checkssl, host; if everything is error-free, we have properly authenticated the client The code in Example 5-18 realizes the solution to the problem we laid out earlier for upgrading client authentication. By changing the session context ID to admin_user , we allow clients previously verified as admin users to resume connections, but no others. This is effective at keeping resumed sessions from being mistaken as privileged sessions. In addition, we set the verify options for the SSL object explicitly, forcing the renegotiation to demand a client certificate or fail. After renegotiation is complete, we call the post-connection check function. In some cases, we may want to tailor the post-connection function to meet application-specific needs.

5.2.3.2 Renegotiations in 0.9.7

Overall, renegotiation in Version 0.9.6 is inferior to the functions and simplicity that Version 0.9.7 promises. A new function has been added, SSL_regenotiate_pending . This function will return nonzero if a request is sent, but the handshake hasnt been finished. It will return zero once the handshake is complete. Using this function, we can eliminate most of the ugliness associated with renegotiations in 0.9.6. Before looking at forced renegotiations, well briefly return to passive renegotiations. In most applications, renegotiations for changing the session key rather than upgrading client authentication are started by byte transfer thresholds. In other words, once our connection has transferred a certain number of bytes, we will renegotiate. Because of this new function, we can simply call SSL_renegotiate when the byte limit is reached. Then we periodically check the value of SSL_renegotiate_pending to determine if the renegotiation completed. Doing this, we can programmatically fail if the handshake isnt completed in a certain amount of time after the request. Furthermore, a new SSL option to aid us has been added in Version 0.9.7. By setting SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION with a call to SSL_CTX_set_options , we can automatically prevent clients from being able to resume sessions when we ask for renegotiations, regardless of the session ID context. When our goal is to refresh session keys, this option is invaluable. Using these two new additions will also allow us to make a much cleaner forced renegotiation for client authentication. We can call SSL_renegotiate to set the flag and make a single call to SSL_do_handshake to send the request out. Instead of setting internal state of the SSL object, we can now just call SSL_do_handshake until we either programmatically timeout or SSL_renegotiate_pending returns zero. If the latter condition is met, our renegotiation completed successfully. Ideally, we want to leave the session ID context changing and not set the new SSL option when performing renegotiation for client authentication. This is better because it allows authenticated users to resume authenticated sessions rather than always perform the full handshake.

5.2.3.3 Further notes