On Fri, Apr 16, 1999, Matthias Loepfe wrote:
>[...]
> > 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.
Additional rules? You mean when people use it they will find out more
optimization possibilities? Ok, as long as they're not causing
security risks, that's no problem.
BTW, I've now implemented it this way: Unless one uses "SSLOptions
+OptRenegotiate" the paranoid approach is used where a renegotiation is forced
whenever something is changed on the parameters. With "+OptRenegotiate" it's
done the optimized way described above.
I've just still one problem: The "manually force a client verification" seems
to be not supported by OpenSSL and is actually not possible when the client
already resumed the connection. And I'm still not sure what we can assume in
this situation (i.e. whether the present cert is really already verified).
So the problem is this:
1. The client connects with a certificate and sends the HTTP request.
2. mod_ssl determines that client auth is needed on a per-dir basis
and foces a renegotiation.
3. The client now upgrades the connection by presenting the client
certificate.
4. mod_ssl accepts it and sends the response.
5. The client creates a new forthcoming or even parallel
connection by resuming the last session, i.e. it immediately connects with
the _upgraded_ state, i.e. already presents the certificate in the initial
handshake.
6. The clients HTTP request again hits the per-dir client auth requirements.
7. What can mod_ssl now assume when it finds out that client auth is requested
and a peer certficate is present?
Because under 7.) mod_ssl usually _CANNOT_ any longer verify the certificate
chain because it's no longer present (OpenSSL stores only the peer certificate
but not the chain). Can mod_ssl now assume that it already has verified it
once in a previous session? I think mod_ssl can assume this as long as it can
make sure the connection is a resumed one. When it's a not-resumed one (i.e.
client connected with a certificate although mod_ssl hasn't requested it) I
think mod_ssl has to still force a renegotiation, because the present
certificate then wasn't verified.
> <Location /a>
> SSLCipherSuite DES-CBC3-SHA:RC4-SHA
> </Location>
> 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.
Yes, I've thought about this, too. And that actually was the initial reason I
created the OptRenegotiate option. To allow the user to choose himself
whether this optimization is wanted by him.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
