The configuration of https_port when intercepting traffic currently
requires both the ssl-bump and one of intercept or tproxy options to be
explicitly configured.
This alters the situation slightly to make intercept/tproxy imply
ssl-bump option and remove a likely self_destruct() call.
The reverse case cannot be done and is left as a FATAL event due to
being unable to determine which of intercept and tproxy is the right
option to configure.
Amos
=== modified file 'src/cache_cf.cc'
--- src/cache_cf.cc 2013-06-05 15:02:11 +0000
+++ src/cache_cf.cc 2013-06-07 14:38:34 +0000
@@ -3840,15 +3840,16 @@
#if USE_SSL
if (strcmp(protocol, "https") == 0) {
- /* ssl-bump on https_port configuration requires either tproxy or
intercept, and vice versa */
+ /* ssl-bump on https_port configuration requires either tproxy or
intercept to indicate, and vice versa */
const bool hijacked = s->flags.isIntercepted();
if (s->flags.tunnelSslBumping && !hijacked) {
debugs(3, DBG_CRITICAL, "FATAL: ssl-bump on https_port requires
tproxy/intercept which is missing.");
self_destruct();
}
+ /* intercept and tproxy on https_port require and imply ssl-bump to be
enabled. */
if (hijacked && !s->flags.tunnelSslBumping) {
- debugs(3, DBG_CRITICAL, "FATAL: tproxy/intercept on https_port
requires ssl-bump which is missing.");
- self_destruct();
+ debugs(3, 2, "NOTICE: tproxy/intercept on https_port requires
ssl-bump which is missing. Enabling ssl-bump.");
+ s->flags.tunnelSslBumping = true;
}
}
#endif
