Re: Why Openssl s_server is allowing Session Reuse on the same tcp connection

[sajualways]

The use case is changing the keys for securing long-standing connections.
Of course this is in the server's responsibility, but the mechanism is the
same for client and server.

But we have SSL Renegotiation functionality used for this purpose,where
complete ssl handshake happens again in an encrypted format on the same tcp
connection.

Usually SSL Resumption(Reuse) is used to have a short handshake in a
different tcp connection.

So I want the use case why SSL Resumption(Reuse) happens on the same tcp
connection.

Regards,
Sajeev


On Mon, Apr 29, 2013 at 8:15 PM, Eisenacher, Patrick [via OpenSSL] 
ml-node+s6102n44948...@n7.nabble.com wrote:

  -Original Message-
  From: sajualways
 
  But what Use Case does this have, where client tells the server to
 resume
  the ssl session on the same tcp connection.

 The use case is changing the keys for securing long-standing connections.
 Of course this is in the server's responsibility, but the mechanism is the
 same for client and server.


 HTH,
 Patrick Eisenacher
 :��IϮ��r�m (���Z+�K �+1���x ��h���[�z�(���Z+� ��f�y��� ��
 �f���h��)z{,���

 --
  If you reply to this email, your message will be added to the discussion
 below:

 http://openssl.6102.n7.nabble.com/Why-Openssl-s-server-is-allowing-Session-Reuse-on-the-same-tcp-connection-tp44907p44948.html
  To unsubscribe from Why Openssl s_server is allowing Session Reuse on
 the same tcp connection, click 
 herehttp://openssl.6102.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=44907code=c2FqdWFsd2F5c0BnbWFpbC5jb218NDQ5MDd8LTE5NTQ3NjQxNTc=
 .
 NAMLhttp://openssl.6102.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml





--
View this message in context: 
http://openssl.6102.n7.nabble.com/Why-Openssl-s-server-is-allowing-Session-Reuse-on-the-same-tcp-connection-tp44907p44949.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

RE: Why Openssl s_server is allowing Session Reuse on the same tcp connection

[Eisenacher, Patrick]

 -Original Message-
 From: sajualways
 
 But what Use Case does this have, where client tells the server to resume
 the ssl session on the same tcp connection.

The use case is changing the keys for securing long-standing connections. Of 
course this is in the server's responsibility, but the mechanism is the same 
for client and server. 


HTH,
Patrick Eisenacher

RE: Why Openssl s_server is allowing Session Reuse on the same tcp connection

[sajualways]

Thanks Patrick. 

But what Use Case does this have, where client tells the server to resume
the ssl session on the same tcp connection.

Usually a different tcp connection makes sense to reuse the session id.





--
View this message in context: 
http://openssl.6102.n7.nabble.com/Why-Openssl-s-server-is-allowing-Session-Reuse-on-the-same-tcp-connection-tp44907p44926.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Why Openssl s_server is allowing Session Reuse on the same tcp connection

[Eisenacher, Patrick]

 -Original Message-
 From: sajualways
 
 Openssl s_server is allowing Session Reuse on the same tcp connection

Yes, of course. Why not? The ssl protocol is taking place on a higher OSI level 
than tcp, so it doesn't matter whether it's the same or a different tcp 
connection.

 When a second client hello is sent with session id of first handshake it
 is reusing i.e it is doing a session resumption instead it should do
 Renegotiation

By sending an ssl session id, your client tells the server to resume that ssl 
session. If your client doesn't want to resume any ssl session, but start a new 
one and thus undergo a full handshake, then simply make it not send an ssl 
session id.


HTH,
Patrick Eisenacher