Sorry,
Some explanations available in sources ssl/t1_lib.c:
==
- Applications must use SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION
if they provide for changing an explicit servername context for the
session,
i.e. when the session has been established with a servername extension.
==
So this option must be used if server use server_name extension.
But what will happens if server do use server_name extension, but not set
SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION?
What the security consequences will be?
I understand there is some, but can't figure out what exactly...
The only thing I was able to find is this:
http://mail-archives.apache.org/mod_mbox/httpd-bugs/200409.mbox/%3c20041001143012.6555.qm...@nagoya.betaversion.org%3E
If two virtual servers configured to use different ciphersuites, there is a
possiblility for malicious client to establish session with one server with
it's ciphersuite, and then renegotiate connection with other server.
And ciphersuie remains unchanged.
I can't say for sure is it security or compatibility issue.
Would be really appreciated for any comments.
Best wishes,
Andrey
On 18 June 2011 15:58, Andrey Kulikov amde...@gmail.com wrote:
Hello,
There is an option available:
SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION
Descroption laconicaly states:
When performing renegotiation as a server, always start a new session
(i.e., session resumption requests are only accepted in the initial
handshake). This option is not needed for clients.
But I can't find any information WHY and WHEN I should (or should not) use
this option.
Could anyone explain, what the purpose of this option?
I.e. what the drawback of allowing session resumption during renegotiation?
Is it for compatibility with buggy clients?
Or is it some security countermeasure?
Would be really appreciated for any comments.
Best wishes,
Andrey
