Thanks to everyone who followed through :)
For completion, I pushed this to trunk in r1829513 though arguably we
could/should accept some behavioural change here in 2.5. No strong
opinion on this really. 2.4 backport also proposed.
It bugs me to be left with the "surprising" behaviour of ssl_hook_Fixup
discovered here - it still thinks SSL is disabled for an active SSL
connection only because of sc->enabled. We could fix that by having that
function ignore sc->enabled and treat a non-NULL sslconn->ssl as
sufficient proof the connection uses SSL. Related issue in PR 61519.
Possibly also we could do something like SSL_get_state(sslconn->ssl) to
check that a connection is actually negotiated. I'm not at all
confident that the existence of sslconn->ssl is a *good* indicator that
the connection is using SSL, and it might do the wrong thing in some
edge case. (I managed to re-introduce CVE-2005-3357 briefly when
fiddling with this code, so, there are definitely dragons here)
trunk equiv e.g.
Index: modules/ssl/ssl_util.c
===================================================================
--- modules/ssl/ssl_util.c (revision 1829263)
+++ modules/ssl/ssl_util.c (working copy)
@@ -109,7 +109,7 @@
sslconn = myConnConfig(r->connection->master);
}
- if (sc->enabled == SSL_ENABLED_FALSE || !sslconn || !sslconn->ssl)
+ if (!sslconn || !sslconn->ssl)
return 0;
if (scout) *scout = sslconn;
