..I mentioned overhead not in terms of data bytes, but the time. Considering that in the system each session should not last not more than 3-4 seconds, and client wanting to make multiple SSL session with server, persistence can offer performance improvement.
Also each client that the application simulates would pick up a unique IP address, [ virtual address are configured in the system]. Each thread would have a unique socket connection with server. These threads would be working parallel in communicating the sevrer. Would there still be issues of TCP stream getting mixed up across threads ? Thanks, Prabhu. S On Fri, Feb 22, 2008 at 3:32 AM, Saju Paul <[EMAIL PROTECTED]> wrote: > TCP Connection: (4 bytes) > SYN > SYN/ACK > ACK > > TCP TearDown: (3 bytes) > FIN/ACK > ACK > > 7 bytes were considered overhead and optimized on a channel that needs an > SSL session. > > seems hardly worth it...IMO > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of David Schwartz > Sent: Thursday, February 21, 2008 1:31 PM > To: openssl-users@openssl.org > Subject: RE: SSL connections in persistent TCP 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. > > It is either designed properly or it's not. You can't validate a design by > testing. > > What makes sure that the last 'read' for the first session doesn't get > some > of the data for the second session? Either something makes absolutely sure > this can't happen, or it can happen, and your design is broken. > > > 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. > > Right, but they serve a vital purpose. They make absolutely sure that the > end of the first session can't be confused with the beginning of the > second. > If you remove this "overhead", you have to provide this same assurance > with > some other mechanism. It sounds like you don't. > > Do you understand the issue I'm talking about? TCP is a byte-stream that > doesn't preserve message boundaries. Nothing stops a call to 'read' made > by > OpenSSL from getting the last bits of data from the first session and the > first bits of data from the second. Then OpenSSL has no place to put the > 'leftover' data that is vital to establishing the second session. As a > result, the next session can't properly establish. > > This is most likely to show up under load and is a classic race condition. > > > So successful SSL handshakes in persistent connection should be > possible > > 'every time'. I do not think it can happen by accident. > > You say this, but your design does not make sure. You get lucky a lot and > it > happens by accident. But you provide no guaranteed separation between the > last bits of the first session and the first bits of the second. > > > And I do agree with you on significance of improvement. I haven't > > quantified yet the gain in doing connection in persistent TCP. > > So you made a premature optimization that his risks you don't understand. > > > But server as persistent TCP feature. Some client may wish to > communicate > > like that. > > Then you need a precise specification that explains in detail how the > sessions are separated at the TCP level, and you need to make sure both > the > client and the server follow that specification. You are doing this > completely wrong, and it is unfortunate that it worked by accident > misleading you into thinking what you were doing made some kind of sense. > It > does not. > > By the way, did you do any kind of analysis to make sure this doesn't have > security risks? Offhand, I can't think of any way that it would, but I > wouldn't trust it without a full evaluation. If both SSL sessions have the > same security parameters, tearing down the old one and building up a new > one > is a pure waste. If they have different security parameters, the > possibility > that the boundary between the two could be compromised in some way seems > to > be a threat that needs proper evaluation. > > DS > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] >
