Re: SSLeay equivalent...

1999-11-11 Thread Geoff Thorpe 

hi there,

 I am attempting to write an application which can be built using
 either openSSL or SSLeay (latest releases) and I would like to 
 take advantage of session caching. From the (limited ;-)) online
 docs it seems that for this to work, using openSSL, I need to
 call SSL_CTX_set_session_id_context first. This is fine. However, 
 I am having trouble determining if session caching is working 
 properly. Is there an equivalent call that must be made when
 using SSLeay that you know of?

I believe this was to fix a virtual-hosting related bug in SSLeay and
earlier versions of OpenSSL too - namely that when implementing a session
cache used by more than one SSL_CTX object, it was possible for sessions
cached by one SSL_CTX to be reused by other SSL_CTXs. This is bad for lots
of reasons - you can get access to one SSL_CTX that has tight validation
rules (eg you must have a client cert and it must be signed by "this" CA
cert, etc) by first negotiating a reusable session with an SSL_CTX with
much looser restrictions (eg it may not need a client cert at all).

So, if SSL_CTX_set_session_id_context doesn't exist then that's probably
because it hadn't been introduced at that point and isn't needed. I belive
this issue only applies to session caches you implement yourself via
callbacks - a default session cache is contained within each SSL_CTX and
they are not shared unless you implement some mechanism to do it.

To see how the cache is functioning, take a look at the variables in the
"stats" structure of SSL_CTX. There are probably API functions to access
these cleanly but I can't recall off-hand. Anyway, these stats will let
you know if sessions are being resumed and other cache information.

Cheers,
Geoff


--
Geoff ThorpeEmail: [EMAIL PROTECTED]
Cryptographic Software Engineer, C2Net Europehttp://www.int.c2.net
--
May I just take this opportunity to say that of all the people I have
EVER emailed, you are definitely one of them.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SSLeay equivalent...

1999-11-11 Thread Bodo Moeller 

On Thu, Nov 11, 1999 at 03:36:01PM +, Geoff Thorpe wrote:

[...]
 So, if SSL_CTX_set_session_id_context doesn't exist then that's probably
 because it hadn't been introduced at that point and isn't needed. I belive
 this issue only applies to session caches you implement yourself via
 callbacks - a default session cache is contained within each SSL_CTX and
 they are not shared unless you implement some mechanism to do it.

Correct, but note that SSL_CTX_set_session_id_context must be set
anyway in these cases.  The rationale is that if we did not look at a
session context for objects that come from the internal session cache,
we'd likely see programs where much effort is put in implementing an
external cache but where this cache is totally disfunctional because
during testing only the internal cache was ever used, any items stored
in the external cache being refused.  Always insisting on a session ID
context makes such errors obvious because you will never get a reused
session.

To check whether an SSL *ssl has a reused session, look at
SSL_session_reused(ssl).  If you have a debug logfile, you definitely
should log this.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]