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