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
>
