Ralf S. Engelschall wrote:
>
> On Wed, Apr 14, 1999, Matthias Loepfe wrote:
>
> > A renegotiation only happens if:
> >
> > 1.) if current cipher is not contained in the new cipher list
> > 2.) if current cert chain length is longer than the verify depth
> > 3.) if verify client is required and no peer cert is available
> > 4.) ....
>
> Ok, I've though about this now again and think your suggestions are ok, but
> technically read the following for mod_ssl:
>
> A renegotiation _has_ to be performed...
>
> o If the currently active cipher is not contained in the
> reconfigured/new cipher suite.
> o If the currently active verify type is less (strong) than
> the reconfigured/new verify type
> (order is: none < optional_no_ca < optional < require)
> o If the currently active verify depth is greater than the
> reconfigured/new verify depth.
>
> Additionally the following optimization is possible: When the currently active
> verify type is "none" but a client certificate is already known/present, it's
> enough to manually force a client verification but skip the renegotation
> handshake itself.
Thats exactly what I meant. But As soon a you enable your EXPERIMENTAL code
(ServerCert, CACerts) there will come aditional rules.
>
> Is this optimized approach still secure?
This morning a had a longer discussion with the security responsibles of a
large bank. At the end we concluded that it should be ok to do it this way.
The only thing which arose was that you cannot guarantee a client that
there will be always the best possible cipher used. That means if you
have two location with different cipher-lists configured, it is possible
that the client chooses tho different cipers to communicate with one of
thge locations depending if before there was a communication with the
other one:
Example:
<Location /a>
SSLCipherSuite DES-CBC3-SHA:RC4-SHA
</Location>
<Location /b>
SSLCipherSuite RC4-SHA
</Location>
If the client first connect to '/b' and the to '/a' it will use
RC4-SHA other wise it will use DES-CBC3-SHA
But we also agreed that this is not really a reason not to optimize
the renegotiation.
regards
Matthias
-------------------------------------------------------------------------------
Matthias Loepfe, AdNovum Informatik AG, Roentgenstr. 22, CH-8005 Zurich
Email: [EMAIL PROTECTED] Voice: +41 1 272 6111 Fax: +41 1 272 6312
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
