httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
Subject Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Date Fri, 13 Dec 2013 14:52:08 GMT
On Fri, Dec 13, 2013 at 2:42 PM, Plüm, Rüdiger, Vodafone Group <> wrote:

> *Von:* Yann Ylavic []
> *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
     *   the cipher suite changed in _any_ way (which is straight-forward
     *   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
     *   client supports. So as long as the current cipher is still in the
     *   cipher suite we're happy. Because we can assume we would have
     *   selected it again even when other (better) ciphers exists now in
     *   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).


View raw message