TCP Connection: (4 bytes)

TCP TearDown: (3 bytes)

7 bytes were considered overhead and optimized on a channel that needs an
SSL session.

seems hardly worth it...IMO

-----Original Message-----
[]On Behalf Of David Schwartz
Sent: Thursday, February 21, 2008 1:31 PM
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

>> the last message of the first session, how do you make sure you also

>> 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
> connecting to server simultaneously.

It is either designed properly or it's not. You can't validate a design by

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.


__________________________________________________ ____________________
OpenSSL Project
User Support Mailing List
Automated List Manager

__________________________________________________ ____________________
OpenSSL Project
User Support Mailing List
Automated List Manager