Prabhu S wrote:
On 2/20/08, *David Schwartz* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
> But, the application code tries to clear out/shutdown existing
> SSL session with orderly bi-directional alerts. Once shutdown it
> creates a new SSL object 'ssl' [ssl = SSL_new (ctx)]
> for the next session in persistent connection..
This is nearly impossible to do. It's possible that you did it
correctly,
but very unlikely. The basic problem is this -- when you call 'read'
to get
the last message of the first session, how do you make sure you also
don't
get all or part of the first message of the second session?
I do not think it is very difficult. The application initiates SSL
sessions sequentially in a established socket connection.One cycle of
SSL_connect - DataExchange-SSL_shutdown is followed by another cycle of
SSL_connect - DataExchange-SSL_shutdown. As such there shouldn't be
issue of session mix up.At least that is what is observed with say
400-500 clients connecting to server simultaneously.
Isn't it possible you got lucky under just the 'right' conditions? Can
you guarantee it will always work?
> When the app simulates limited clients , say, 100, each client makes
> hundreds of unique SSL sessions successfully in persistent
connection.
> It is under stress of ~800 clients , that I run into issues.
> Also, the bi-directional alerts do not happen always under
> high stress..could this be the reason? a possible session data
mix up?
Either your code properly separates the sessions or it doesn't. My
bet is
that it doesn't because this is very hard to do right.
Yes. I believe so..I am able to establish hundreds of cycles of new
sessions in persistent connection. The trouble is under high stress
sessions fail as indicated by ethereal trace.Sometimes server complains
of Bad_MAC error on receiving Finished message from client.
Why do you do things this way? It's just plain wrong. Either layer
on top of
SSL or don't, but splitting the difference and "sort of" layering
between
SSL and TCP is just plain crazy.
Multiple sessions are tried in a single TCP connect to reduce the
overhead of TCP handshake and termination if the client wishes to do
multiple 'new' SSL connects to server.
Have you quantified this overhead? What percentage of session
establishment is TCP handshake overhead?
Thanks,
Prabhu. S
Good luck!
-jb
--
I used to think I was indecisive, but now I'm not so sure.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]