On Fri, Dec 13, 2013 at 2:42 PM, Plüm, Rüdiger, Vodafone Group < ruediger.pl...@vodafone.com> wrote:
> > > > > *Von:* Yann Ylavic [mailto:ylavic....@gmail.com] > *Gesendet:* Freitag, 13. Dezember 2013 13:09 > *An:* httpd > *Betreff:* Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT > requests > > > > Without SNI (in 2.2.x, I can't tell for 2.4), doesn't this lead to a > (secure/full) renegotiation? > > > > IMHO no. This is the problem. > IM(even more)HO, the following 2.2.x code from ssl_hook_Access() does the trick : /* * Override of SSLCipherSuite * * We provide two options here: * * o The paranoid and default approach where we force a renegotiation when * the cipher suite changed in _any_ way (which is straight-forward but * often forces renegotiations too often and is perhaps not what the * user actually wanted). * * o The optimized and still secure way where we force a renegotiation * only if the currently active cipher is no longer contained in the * reconfigured/new cipher suite. Any other changes are not important * because it's the servers choice to select a cipher from the ones the * client supports. So as long as the current cipher is still in the new * cipher suite we're happy. Because we can assume we would have * selected it again even when other (better) ciphers exists now in the * new cipher suite. This approach is fine because the user explicitly * has to enable this via ``SSLOptions +OptRenegotiate''. So we do no * implicit optimizations. */ if (dc->szCipherSuite || (r->server != handshakeserver)) { ... renegotiate if the (whole) ciphercipher suite changed (paranoïd) ... ... or if the handshaked cipher is not in r->server's cipher suite (+OptRenegotiate) ... } I have seen the "Reconfigured cipher suite will force renegotiation" log many times because of multiple SSL vhosts listening on the same IP:port (a common configuration "mistake" without SNI, but which works, slowly...). I can't tell whether this applies to all the other SSL parameters though (most -if not all?- seem to be handled the same way in ssl_hook_Access(), but I didn't do an exhaustive search to tell the truth, and maybe it is not feasible here for all). Regards, Yann.
