#
Using wolfSSL, is there a way to "tell" it to try and reuse recently negotiated Session ID?

I am noticing (on the server side, tomcat) that a lot of SessionID objects are cached but never actually reused. When I am doing the same with a standard browser, I notice that the same SessionID objects are reused.

Thanks!
#
touskaProject Admin

[Avatar]
2007-11-20 17:42:43 UTC
Yes, wolfSSL can reuse SessionIDs. The keys are SSL_get_session() and SSL_set_session(), see client.c in wolfSSL Home/examples/client.c, specifically the code under TEST_RESUME idfefs to see usage.

#
yuvalperlov

[Avatar]
2007-11-26 10:39:24 UTC
I am not so clear about the life cycle of the SESSION_ID pointer...

When is it freed? Is it safe to use forever? If I am connecting to many servers or to one server that looses the cached server id from time to time, will memory consumption grow infinitly?

Yuval
#
touskaProject Admin

[Avatar]
2007-11-26 21:02:51 UTC
Sessions are valid for 500 seconds. They are not freed until they are asked for when expired or when the context is freed. You can turn the session cache off by calling SSL_CTX_set_session_cache_mode() with a mode of SSL_SESS_CACHE_OFF.

I'll add SSL_flush_sessions(), which you can call to remove stale sessions.
#
yuvalperlov

[Avatar]
2007-11-27 07:31:41 UTC
Makes sense. However, wouldn't it be best if all this was hidden from me and you would cache the host:port->sessionid internally and try to reuse it within the 500 second limit? I am guessing most if not all users will implement an extremly similar mechanism.
This would also give you more control over freeing them up since you will not have to worry about users keeping a pointer to your internal objects.

Yuval
#
touskaProject Admin

[Avatar]
2007-11-27 20:14:25 UTC
I can see that point. I started trying to push the yaSSL API initially but everyone wanted to use the OpenSSL API as it's become the de facto standard, and they expect similar behavior as well. So with wolfSSL that's the only API I went with. No sure why the design is this way except that maybe the user has a better idea about whether resumption will be necessary, and not all users want to pay for getpeername(), locking the session cache, searching for the match, and comparing the time. That said, I could implement that behavior if the user turns it on, maybe something like SSL_try_resume() before a call to SSL_connect(). Would that be useful?
#
yuvalperlov

[Avatar]
2007-11-27 22:11:22 UTC
I believe the time scale of getting an SSL handshake going, is in an order of magnitude that makes the local function calls and contention negligible. I believe you are right though in making sure the default behavior is as openssl-like as possible. Java has this feature turned on by default and the downside I perceive is that you can't control the cache size and if you have many concurrent clients it can grow to some scary numbers.

Anyway, adding an explicit set-option function to get this behavior will be extremly useful and will result in less wrapper code on our side.

Thanks!
Yuval
#
yuvalperlov

[Avatar]
2007-12-19 10:05:59 UTC
Is there a target version/date for this feature?
#
touskaProject Admin

[Avatar]
2008-01-07 21:47:55 UTC
It's on our list for the next release, approx. Jan 21st.
#
touskaProject Admin

[Avatar]
2008-02-06 18:05:12 UTC
Well, I started implementing a host:port hash table for session IDs until I ran into a problem. A client can, and often does, have multiple connections to the same server (and port). Not only that, but if the client has only one connection at a time but has connected multiple times which session is trying to be resumed. The standard also mentions using session IDs as the key for resumption and I'm not so sure handing these out on a host:port request isn't a security problem.

Any ideas?
#
yuvalperlov

[Avatar]
2008-02-06 21:27:15 UTC
When I am running in "implicit cache mode", how can there be more than one session id? In other words I don't see how the question "which one am I trying to resume" is valid - there is only one session per host:prot no matter how many times I reconnect (provided they are within the cache time).

For concurrent sessions, there seems to be a need to protect the cache with a mutex and arrange it so if two threads are connecting at the same time to the same host:port, one will wait to use the id the other negotiates. However, I think it is good enough to have one override the other for the sake of simplicitly on your side. The cost of one more negotiation in this rare occurance is neglectable (of course the whole cache should be mutexed to avoid memory corruption).

I don't see how this could be a security issue - until you implement this in the library, your users have to implement the exact same mechanism in wrapper code, with the exact same logic - there is no other "key" I can use except the host:port because all other information is opaque for me.
#
touskaProject Admin

[Avatar]
2008-02-06 22:29:32 UTC
Are you saying that concurrent connections always use the same session ID? A web browser with multiple windows, tabs, etc., is going to have several sessions going to the same site from the what I've seen. Same with routers, databases, and set tops, at least as our clients are using it.

I agree that concurrency itself isn't a problem as a mutex will be used.

There may not be a security issue, I don't know. I was just hesitant to include it without more research since the standard recommends using the session ID as the key. This key serves as verification of having gone through the security of the initial connection, without it, we may be opening some hole. I'll look into it some more and see what others have done.

Thanks for the input.
#
yuvalperlov

[Avatar]
2008-12-03 09:11:23 UTC
Does SSL_get_session increment the use count for the session?

If not, how is the SSL_SESSION not freed as part of SSL_free?
Once I reuse it, is it freed up or do I need to free it again?

I didn't notice any indication in client.c for handling this one way or the other.
(Noticed that in openssl there are two versions for this, one that increments the other doesn't)

If the session was not reused, will the connection still succeed or do I have to retry without calling SSL_set_session?
#
yuvalperlov

[Avatar]
2008-12-03 13:13:51 UTC
More on the subject - if I restart the server (Tomcat) between two consecutive hits while trying to reuse the session, it fails and what's more it takes a full minute (exactly 60 seconds) before I get back an error (SOCKET ERROR 208).

Can anyone shed some light on the matter?

Yuval Perlov
#
yuvalperlov

[Avatar]
2008-12-03 13:21:01 UTC
Also, very sorry for repeating the life cycle question ... please disregard
#
touskaProject Admin

[Avatar]
2008-12-03 19:11:24 UTC
There is no use count in wolfSSL's implementation. When a match is found the SESSION pointer's data is copied locally. In wolfSSL 0.9.9x the SESSION pointers are stored on a static list, they aren't freed until they expire, they're flushed, or by calling FreeCyaSSL(). You can reuse them as many times as you like within the timeout.

In wolfSSL 1.0+, not quite ready for release yet, SESSIONS are stored in a compile time fixed size table. They can also be turned off altogether at compile time.

In either version, if the resumption attempt fails, normal connection semantics are automatically employed by the protocol. No action is needed from the user.
#
elsevers

[Avatar]
2009-11-16 01:15:09 UTC
"In either version, if the resumption attempt fails, normal connection semantics are automatically employed by the protocol. No action is needed from the user." Does this mean that if wolfSSL is behaving as a client resuming a session to a server (who has flushed out the session due to a time expiration), that the wolfSSL client (whose cached SSL session is still believed to have not expired) will successfully negotiate the connection without any effort from the user? I am trying to speed up connections to a server that claims to cache sessions for up to 24 hours. However, I have been hesitant to change the value of DEFAULT\_TIMEOUT to reflect this because I do not want to impair my wolfSSL client's ability to connect to other servers that do not have this extended cached-session life. From what you say above, it sounds like I can go ahead and change DEFAULT\_TIMEOUT to 24 hours and I will not notice any ill effects?