[squid-users] peek all step with bump instance of proxy

[Alex Rousskov]

On 08/27/2015 04:50 AM, john jacob wrote:

> with the proxy connections I am encountering some
> peculiar behavior with scenario 3 (ie when a non bumped https CONNECT is
> denied by eCAP). Instead of terminating the connection, it is logged as
> TAG_NONE/200 in the access log and getting bumped (a dynamic certificate
> is generated) and then getting terminated. The behavior disappears and
> works if I comment the "peek all" line.
> 
> I am not sure if this is a bug or an expected behavior.

Most of the stuff you are describing matches my expectations, but there
is not enough information in a couple of cases:

* "getting bumped and then getting terminated". Terminated without
serving an error page to the bumped client? Is there a request after
CONNECT? Is the client happy about the bumped connection? How many
CONNECT requests does your eCAP adapter see (and deny) in this case?

* "works if I comment the 'peek all' line". Works how? I would expect
Squid to bump and then serve an error page to the user on a bumped
connection. How many CONNECT requests does your eCAP adapter see (and
deny) in this case?

Here is some background so that you can debug this further:

Denying a CONNECT request implies serving an error page to the user.
However, the user will not see the error page if Squid sends it as a
response to the CONNECT request (due to lazy browsers security policies;
nothing to do with Squid). The only way to show that error page to the
user is to bump the client connection and then serve the error page over
that bumped connection in response to the first bumped request.

If your eCAP adapter denies CONNECT during an SslBump step, Squid should
bump the client connection (200 OK) and serve an error page to the user
in response to the first request on that bumped connection, if any
(TAG_NONE/403?).

You can find more information about this behaviour at
http://bazaar.launchpad.net/~squid/squid/trunk/revision/13759
but some of that old info is probably out of date by now.



> Of course the proxy bumped connection works fine if I selectively peek
> for intercepted connections (ssl_bump peek <if only in intercepted
> mode>), but in this case I am getting duplicate entries in the access
> log file (ie 2 CONNECT log messages for each https CONNECT) for
> intercepted mode https connections.

This is expected if you peek at step1. The second CONNECT should have
SNI information (but it often does not -- it is complicated and there
are bugs/missing features in that area of the code). If you do not need
SNI, you can make all decisions during the first CONNECT.


> The same goes for other ACL
> combinations like the below resulting in duplicated log messages
> 
> ssl_bump server-first <ip of the domain to be bumped>
> ssl_bump splice <only if the request hit the proxy ip:port and not the
> intercept/transparent ip :port>
> ssl_bump peek all
> ssl_bump splice all

In general, it is a bad idea to combine legacy (server-first) and modern
(peek/stare/splice/bump/terminate) rules. If at all possible, use modern
rules.

Alex.