>> 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]
