------=_Part_8439_27313702.1203658491135
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

...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 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: owner-openssl-users@openssl.org
> [mailtowner-openssl-users@openssl.org]On 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 majordomo@openssl.org
>
> __________________________________________________ ____________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-users@openssl.org
> Automated List Manager majordomo@openssl.org
>


------=_Part_8439_27313702.1203658491135
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline



..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 <saju.paul@messageway.com> 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: wner-openssl-users@openssl.org">owner-openssl-users@openssl.org

[mailto:wner-openssl-users@openssl.org">owner-openssl-users@openssl.org]On Behalf Of David Schwartz

Sent: Thursday, February 21, 2008 1:31 PM

To: penssl-users@openssl.org">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                    penssl-users@openssl.org">openssl-users@openssl.org

Automated List Manager                           majordomo@openssl.org



__________________________________________________ ____________________

OpenSSL Project                                 http://www.openssl.org

User Support Mailing List                    penssl-users@openssl.org">openssl-users@openssl.org

Automated List Manager                           majordomo@openssl.org




------=_Part_8439_27313702.1203658491135--
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majordomo@openssl.org