[squid-users] Squid TPROXY issues with Google sites

[Alex Rousskov]

On 05/26/2017 05:22 PM, Vieri wrote:

> If I have this:
> 
> ssl_bump peek all
> ssl_bump splice AllowTroublesome
> ssl_bump bump all

... then you have a configuration that does not make sense because one
cannot bump after peeking at step2. Your configuration is equivalent to

  * if the current step is 1 or 2, then peek
  * if AllowTroublesome during step 3, then splice
  * otherwise, do the impossible

which, bugs notwithstanding, is equivalent to

  ssl_bump peek all
  ssl_bump splice all

If the above does not block anything then your http_access rules allow
all CONNECTs (and you never get beyond CONNECTs because you do not bump).


> If I replace the above snippet with this:
> 
> ssl_bump stare all
> ssl_bump bump all

This configuration makes sense (but it may not do what you want).

If you want to be able to make a "splice or bump" decision, then you
have to make it during step2:

  ssl_bump peek step1
  ssl_bump splice AllowTroublesome
  ssl_bump bump all


> If I had an http_access rule that allowed the transaction to take
> place then I would expect it to happen regardless of the ssl_bump
> directive.

Your expectations are wrong. SslBump directives expose http_access rules
to more (or fewer) transactions. For example, the "splice all"
configuration does not expose http_access rules to any GET requests.


> Alex, you mention the SSLPeekAndSplice web page. I'll try to sum it
> up in just a few lines

The SslBump feature is too complex to sum it up in just a few lines
unless those lines are something like "do not use it without fully
understanding it". Once you learn the basics of SSL handshake, which
Squid steps look at what parts of the handshake, and what the essential
difference between peeking and staring is, then SslBump becomes less of
black magic. Without that knowledge, it is a dark mystery.


> - peek implies splice which means you can't do content analysis (as
> in scan for threats via c-icap modules)

Wrong. Peeking at step1 does not preclude future bumping. Peeking at
step2 precludes future bumping. If you peek at step2, then you have to
splice or terminate at step3.


> - stare implies bump which means you can do content analysis

Wrong for similar/symmetrical reasons.


> - you don't need to stare, you can just bump

Wrong in many cases -- usually you _do_ need to stare (or peek) at least
at step1, but YMMV.


> - you need to stare before bump if you want the clients to accept a
> certificate with domain names instead of IP addresses

Misleading. You need to stare or peek to get more information, including
the server domain name. That information comes from either the client or
the server, depending on the step. That information is used to generate
a fake certificate. The more info Squid has, the better it can
fake/mimic the true certificate, but learning more information restricts
the set of ssl_bump actions.


> - you can bump first by ACLs and then splice the rest

If you mean that ssl_bump rules may start with "bump" rules and end with
"splice" rules, then this is true, but the reverse is also true, and the
rules may contain a mixture of many actions.


> - you can bump after peek but only if you do that at SslBump1

Too vague to be generally useful. You can bump after peeking at step1.
You cannot bump after peeking at step2.


> the "Bump All Sites Except Banks" example where the next
> phrase contradicts the title by saying that the requests to non-banks
> won't be bumped.

Correct! The example, the title, and the warning were written by
different people. One of them is right. If you know how SslBump works,
you know which part is correct. At that time, please feel free to
propose changes to fix the wiki page. Hundreds of folks receive SslBump
help on this mailing list, but only one of them took the pains to
improve the page afterwards (thank you again, Marcus Kool!). Parts of
that page still need a lot of work.


HTH,

Alex.