[squid-users] Host header forgery affects pure splice environment too?

[Alex Rousskov]

On 12/27/2015 03:13 PM, Jason Haar wrote:
> Surely if all you are doing is
> splice-only, it shouldn't be doing that check at all?


The situation is not that black-and-white, unfortunately. This general
problem can be viewed under several different angles:

A. You are not using a splice-only configuration.

As you said, you are peeking at SNI before splicing. Thus, your overall
configuration (and Squid involvement) is much more complex than
"splice-only". Pure splicing would have worked fine (or would fail for
different reasons).


B. Your splicing intent is unknown to Squid.

There are several common reasons for splicing, including:

1.  To avoid bumping things that cannot or should not be bumped.
2a. To log connection details.
2b. To return errors when connections fail certain validation checks.


C. Your final action may be unknown to validating Squid.

During a "peek" or "stare" action, Squid does not yet know whether the
final SslBump action is going to be "splice", "bump", or "terminate".
Thus, even if we manage to agree that "splice" means "check nothing",
Squid would not be able to apply that agreement to the "peek" action,
unless we also agree that "peek" means "check nothing".

And if neither peek nor splice should check anything, then how can an
admin rewrite her currently-working configuration that validates server
certificates without bumping connections to sites that pass validation?


AFAICT, given the above mixture, Squid cannot reliably determine your
true peeking-and-splicing intent and disable the right set of checks
accordingly while supporting everything it already supports. Do we need
more configuration knobs to help Squid to make the right decision?

Alex.