On 09/07/01 08:59 PM, Lutz Jaenicke sat at the `puter and typed:
> I'll be very careful with my answer, as I don't program with threads myself.
> SSL_get1_session() will increment the reference counter, so that when
> the session would be removed otherwise, it will stay available.
> If you call SSL_set_session(ssl, session), the reference count for session
> is also incremented. If the session is not reused, or its use is finished,
> it will be decremented again automatically.
> So I actually would expect, that a session once obtained with
> SSL_get1_session() will stay available with just the right reference count,
> whatever you are going to do, until you explicitely SSL_SESSION_free() it.
Ok, I'll bounce this one off my brain a bit more.
> SSL_session_reused() should be available since 0.9.1...
Correct. I assumed it would follow the more general convention of
capitalization - it is there.
Now I have another problem. In trying to call
SSL_CTX_flush_sessions(ssl_ctx, time(0));
I am being blessed with a core dump.
Here is what I get when looking at ssl_ctx:
(gdb) p *ssl_ctx
$2 = {
method = 0x11da50,
options = 67108864,
mode = 0,
cipher_list = 0x1da1c8,
cipher_list_by_id = 0x1da188,
cert_store = 0x1d8db0,
sessions = 0x1dbde0,
session_cache_size = 20480,
session_cache_head = 0x258b30,
session_cache_tail = 0x258c30,
session_cache_mode = 129,
session_timeout = 3600,
new_session_cb = 0,
remove_session_cb = 0,
get_session_cb = 0,
stats = {
sess_connect = 2,
sess_connect_renegotiate = 0,
sess_connect_good = 2,
sess_accept = 0,
sess_accept_renegotiate = 0,
sess_accept_good = 0,
sess_miss = 0,
sess_timeout = 0,
sess_cache_full = 0,
sess_hit = 0,
sess_cb_hit = 0
},
references = 2,
info_callback = 0,
app_verify_callback = 0,
app_verify_arg = 0x0,
cert = 0x1dbd88,
read_ahead = 0,
verify_mode = 1,
verify_depth = 2,
sid_ctx_length = 0,
sid_ctx = '\000' <repeats 31 times>,
default_verify_callback = 0x3f2dc <verify_callback>,
purpose = 0,
trust = 0,
default_passwd_callback = 0,
default_passwd_callback_userdata = 0x0,
client_cert_cb = 0,
client_CA = 0x1da1a8,
quiet_shutdown = 0,
ex_data = {
sk = 0x0,
dummy = 0
},
rsa_md5 = 0x11af38,
md5 = 0x11af38,
sha1 = 0x11afb0,
extra_certs = 0x0,
comp_methods = 0x0
}
Obviously, ssl_ctx->sessions is a valid pointer:
(gdb) p *ssl_ctx->sessions
$3 = {
b = 0x1dbe48,
comp = 0x5f040 <SSL_SESSION_cmp>,
hash = 0x5f000 <SSL_SESSION_hash>,
num_nodes = 8,
num_alloc_nodes = 16,
p = 0,
pmax = 8,
up_load = 512,
down_load = 0,
num_items = 2,
num_expands = 0,
num_expand_reallocs = 0,
num_contracts = 0,
num_contract_reallocs = 0,
num_hash_calls = 3,
num_comp_calls = 0,
num_insert = 2,
num_replace = 0,
num_delete = 0,
num_no_delete = 1,
num_retrieve = 0,
num_retrieve_miss = 0,
num_hash_comps = 0,
error = 0
}
First, I don't understand all implications of this printout, but I am
guessing that ssl_ctx->sessions.num_items shows that there are 2
sessions cached. I guess I still don't have everything ironed out -
that should be just one session.
Anyway, here is what the sessions look like:
(gdb) p *ssl_ctx->session_cache_head
$6 = {
ssl_version = 768,
key_arg_length = 0,
key_arg = "\000\000\000\000\000\000\000",
master_key_length = 48,
master_key =
"v½Õ¦|Åþvï8mÿÉ\034Ów\234x\226\207\025u!Sa\031þ\025ø\221<\234®\177/ÇmüýhG\206\\\227 \037 Y",
session_id_length = 32,
session_id =
"Á\232\003$B\233\r}èu\fÍ\022,:\023|ifí\021ñ³¥\037#\177ºÐ[\217",
sid_ctx_length = 0,
sid_ctx = '\000' <repeats 31 times>,
not_resumable = 0,
sess_cert = 0x1eacf0,
peer = 0x223790,
verify_result = 0,
references = 2,
timeout = 3600,
time = 999896879,
compress_meth = 0,
cipher = 0x113be0,
cipher_id = 0,
ciphers = 0x0,
ex_data = {
sk = 0x0,
dummy = 0
},
prev = 0x1dbcb8,
next = 0x258c30
}
(gdb) p *ssl_ctx->session_cache_tail
$7 = {
ssl_version = 1130600,
key_arg_length = 0,
key_arg = "\000\000\000\000\000\000\000\001",
master_key_length = 0,
master_key = '\000' <repeats 11 times>, "\016", '\000' <repeats 15 times>,
"\001\000\000\027<\000\000\001Å", '\000' <repeats 11 times>, "\201",
session_id_length = 0,
session_id = "C\203¯\006Õk!Võþ: \232\216\237Îá\036\b\200h\224LVµ,ý3\231Ñ`þ",
sid_ctx_length = 4010013418,
sid_ctx = "»iÉÎÚÏ8²ï\001@ v\230À;¨\230@!\025eaü\200ÜÑ-¶j4\001",
not_resumable = 1188459826,
sess_cert = 0x28593dae,
peer = 0x7da60e7c,
verify_result = 476049035,
references = 351029985,
timeout = -1366346612,
time = 1929255041,
compress_meth = 12958976,
cipher = 0xacc32ca7,
cipher_id = 3197845400,
ciphers = 0xfffad7c0,
ex_data = {
sk = 0x5bb86781,
dummy = 2053017233
},
prev = 0x258b30,
next = 0x9103136e
}
I could be wrong, but I think that negative value on the timeout is a
bad thing. Anyone with some idea how that happened? It'd be a pain
in the neck to have to set the timeout on each individual SSL struct,
when I am using only one SSL_CTX configuration to create them all, so
what is the process when a connection is created from a context? Am I
misunderstanding something here, or does this look like a problem?
Now, look back at the ssl_ctx printout. session_timeout is set to
3600. I am specifically setting this myself to 5 minutes (300 sec)
for testing purposes, with SSL_CTX_set_timeout(ssl_ctx, SSLTimeout);
So why is this resetting to 1 hour?
Sorry for the looong data dump, but I'm really confused as to what
this means. I'll dupe this directory so I can make more traces as
needed for debugging/feedback, etc. so feel free to ask questions that
might shed some light.
Thanks to anyone who can help with this.
Lou
--
Louis LeBlanc [EMAIL PROTECTED]
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
http://acadia.ne.mediaone.net Ô¿Ô¬
If I had only known, I would have been a locksmith.
-- Albert Einstein
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
