On Wed, Feb 21, 2001 at 07:06:29PM +0100, [EMAIL PROTECTED] wrote:
> Log:
> This change allows a callback to be used to override the generation of
> SSL/TLS session IDs in a server. According to RFC2246, the session ID is an
> arbitrary value chosen by the server. It can be useful to have some control
> over this "arbitrary value" so as to choose it in ways that can aid in
> things like external session caching and balancing (eg. clustering). The
> default session ID generation is to fill the ID with random data.
>
> The callback used by default is built in to ssl_sess.c, but registering a
> callback in an SSL_CTX or in a particular SSL overrides this. BTW: SSL
> callbacks will override SSL_CTX callbacks, and a new SSL structure inherits
> any callback set in its 'parent' SSL_CTX. The header comments describe how
> this mechanism ticks, and source code comments describe (hopefully) why it
> ticks the way it does.
[...]
> int ssl_get_new_session(SSL *s, int session)
> {
> /* This gets used by clients and servers. */
>
> + unsigned int tmp;
> SSL_SESSION *ss=NULL;
> + GEN_SESSION_CB cb = def_generate_session_id;
>
> if ((ss=SSL_SESSION_new()) == NULL) return(0);
>
> @@ -173,25 +207,46 @@
> SSL_SESSION_free(ss);
> return(0);
> }
> -
> - for (;;)
> + /* Choose which callback will set the session ID */
> + CRYPTO_r_lock(CRYPTO_LOCK_SSL_CTX);
> + if(s->generate_session_id)
> + cb = s->generate_session_id;
> + else if(s->ctx->generate_session_id)
> + cb = s->ctx->generate_session_id;
> + CRYPTO_r_unlock(CRYPTO_LOCK_SSL_CTX);
For other callbacks and parameters that exist both in SSL_CTX and in
SSL structures, we copy the SSL_CTX default to the SSL structure in
SSL_new and don't look at the SSL_CTX value later. IMO, we should do
that here too for consistency.
> + /* Finally, check for a conflict */
> + if(SSL_CTX_has_matching_session_id(s->ctx, ss->session_id,
> + ss->session_id_length))
> + {
> + SSLerr(SSL_F_SSL_GET_NEW_SESSION,
> + SSL_R_SSL_SESSION_ID_CONFLICT);
> + SSL_SESSION_free(ss);
> + return(0);
This has the same race condition as the previous code (there's a time
window between checking for a conflict and adding the session to the
session cache), except that now we can't reason that the PRNG is
extremely unlikely to ever generate a collision of that length.
Previously the race condition did not matter because we had control
over the generation of session IDs, but now the application takes over
responsibility for this. Also we'd have to query the external cache
for conflicts. (With the current API for external session caches, we
can't avoid the race condition, so the API would have to be extended.)
The previous conflict-checking code was not really functional;
it was just there mostly as a reminder that session IDs must
be unique (and maybe as a sanity check for PRNG output).
Now that the session ID generation becomes more complicated,
we should either fix these problems or declare that applications
are solely responsible for ensuring uniqueness of session IDs;
in the latter case, we could delete the conflict checks
to keep the code clean.
--
Bodo Möller <[EMAIL PROTECTED]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
