Stunnels up to version 3.8 failed to properly attempt to select an SSL session ID before making the SSL connection, thus no session ID reuse was possible. This patch forces stunnel in client mode to offer the most recent SSL session ID (presumably the most recent used is the most valid) to the remote SSL server in hopes that they can speed up the SSL handshake. Again, since an Stunnel client can only connect to one SSL server, it always uses the most recently added SSL session ID, which is the one most likely to still be accepted (not timed out, etc) by the server.