Re: dynamic renegotiation
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]
Re: dynamic renegotiation
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]
Re: dynamic renegotiation
On Wed, Apr 14, 1999, Matthias Loepfe wrote: From my point of view there happen much too much renegotiations Yes, that's correct. We've recognized this some time ago, too. I've written it down on my TODO list, but it's non-trivial to make better. which is especially anoying if client certs are requested because there is always a user interaction required. Could the logic which determines a renegotiation be slightly changed? 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.) Hmm... good suggestions, but as I already said once in the past: One has to be _VERY_ carefully when doing short-cuts or optimizations for this stuff because one can too easily introduce security holes. That's why I currently implemented it this way: mod_ssl checks whether the parameters change in _any_ way and when it changed it forces a renegotiation. You're right that this often still is too much renegotiation. I'll try to sit down in a silent minute and think about the possible and safe optimizations again. During my tests I found a behaviour which I don't understand. Probably someone can explain it to me: The following two cipher lists are the same: HIGH:+MEDIUM HIGH:+MEDIUM:+EXP But the following contains the export ciphers as expected HIGH:+MEDIUM:EXP You can verify it with 'openssl ciphers -v list' grin That's because Eric's syntax is strange. The "+XXX" does _NOT_ mean "plus XXX" or "add XXX to the cipher suite". It means "move XXX to this place of the ordering". When you don't have XXX in the cipher suite "+XXX" is useless. That why CipherSuite strings usually start with some "XXX:YYY:ZZZ" followed with appended ":+AAA:+BBB" where AAA and BBB are subparts of XXX, YYY or ZZZ. Read the mod_ssl user manual carefully. I think I've explained it there in detail. 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]
Re: dynamic renegotiation
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. Is this optimized approach still secure? 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]
