Defect? regarding Session ID's
I noticed a small inconsistency in OpenSSL. According to the OpenSSL documentation, applications that want to resume sessions should call SSL_CTX_set_session_id_context() to provide a unique identifier to be stored with their session caches. However, observing the behavior of OpenSSL and looking at the following code (ssl_sess.c : ssl_get_prev_session): if((s-verify_modeSSL_VERIFY_PEER) (!s-sid_ctx_length || ret-sid_ctx_length != s-sid_ctx_length || memcmp(ret-sid_ctx,s-sid_ctx,ret-sid_ctx_length))) it appears that session id's are not always checked when resuming sessions. For a server implementation, they are only checked if mutual authentication is turned on. The code should really either check the session id anytime it is being reused or ignore it always if it is not set. I'm not sure which is better, but I am sure the code should be consistent. Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of information solutions http://www.novell.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Defect? regarding Session ID's
On Fri, Sep 26, 2003, Verdon Walker wrote: I noticed a small inconsistency in OpenSSL. According to the OpenSSL documentation, applications that want to resume sessions should call SSL_CTX_set_session_id_context() to provide a unique identifier to be stored with their session caches. However, observing the behavior of OpenSSL and looking at the following code (ssl_sess.c : ssl_get_prev_session): if((s-verify_modeSSL_VERIFY_PEER) (!s-sid_ctx_length || ret-sid_ctx_length != s-sid_ctx_length || memcmp(ret-sid_ctx,s-sid_ctx,ret-sid_ctx_length))) it appears that session id's are not always checked when resuming sessions. For a server implementation, they are only checked if mutual authentication is turned on. The code should really either check the session id anytime it is being reused or ignore it always if it is not set. I'm not sure which is better, but I am sure the code should be consistent. This is actually there to protect against a case where a malicious client could resume a session in an inappropriate context. This only affects sessions that enable client authentication so it is only checked in those cases. This was addressed way back in March 1999. For more details see: http://www.mail-archive.com/[EMAIL PROTECTED]/msg1.html Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Defect? regarding Session ID's
Thanks for the information. Verdon Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of information solutions http://www.novell.com [EMAIL PROTECTED] 09/26/03 7:08 PM On Fri, Sep 26, 2003, Verdon Walker wrote: I noticed a small inconsistency in OpenSSL. According to the OpenSSL documentation, applications that want to resume sessions should call SSL_CTX_set_session_id_context() to provide a unique identifier to be stored with their session caches. However, observing the behavior of OpenSSL and looking at the following code (ssl_sess.c : ssl_get_prev_session): if((s-verify_modeSSL_VERIFY_PEER) (!s-sid_ctx_length || ret-sid_ctx_length != s-sid_ctx_length || memcmp(ret-sid_ctx,s-sid_ctx,ret-sid_ctx_length))) it appears that session id's are not always checked when resuming sessions. For a server implementation, they are only checked if mutual authentication is turned on. The code should really either check the session id anytime it is being reused or ignore it always if it is not set. I'm not sure which is better, but I am sure the code should be consistent. This is actually there to protect against a case where a malicious client could resume a session in an inappropriate context. This only affects sessions that enable client authentication so it is only checked in those cases. This was addressed way back in March 1999. For more details see: http://www.mail-archive.com/[EMAIL PROTECTED]/msg1.html Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
