On 27/08/2015 10:50 p.m., john jacob wrote:
> Hi All,
>
> I am trying to configure a squid filtering instance which serves both proxy
> and intercepted (transparent) connections. Filtering is accomplished by a
> Request eCAP adapter which have something like
>
> if(IsDenied() && RequestMethod=="CONNECT")
> {
> // Gives TAG_NONE/403 in the access log
> hostx->blockVirgin();
> return;
> }
>
> I also have a requirement to bump a particular domain and peek other https
> connections for intercepted mode. So there are 3 possible
> outcomes/filtering decision for any https connections hitting this server.
> They are
>
> 1) Bump and allow the access
> 2) Non bumped and allowed access
> 3) Non bumped and denied access, by the code given above in eCAP adapter
>
> My squid (tried with v3.5.6 and v3.5.7-20150823-r13895, same outcome)
> config looks like below
> .
> .
> .
> # TAG: ssl_bump
> ssl_bump server-first <ip of the domain to be bumped>
> ssl_bump peek all
> ssl_bump splice all
> .
Dont use those three options together. The "server-first" option is a
backward compatibility option only.
The "bump" action is usualy best to use in its place. This config looks
like a case where that is true.
> .
> .
> http_port <proxy ip>:<port> ssl-bump generate-host-certificates=on
> dynamic_cert_mem_cache_size=4MB cert=<path>
>
>
> https_port <intercept/transparent ip>:<port> intercept ssl-bump
> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=<path>
>
> Things are fine with the intercepted connections (for all the 3 scenarios).
> But 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.
Certain very popular browsers refuse to show the user any error messages
output by a proxy in response to a CONNECT message. Just a bland
connection failed message of their own.
To get around that we have a nasty hack that delays emitting error pages
until after the bumping has been done. I think that is what you are
seeing happen. There may well be bugs in the hack itself, but the
behaviours you describe all seem like logical side effects given what it
does.
- delays the 403 output -> logs 200 for the 'CONNECT', then
- bumping starts and does peek, then
- splice starts, and detects 403 to be sent back.
- but thats impossible in splice, so terminate.
Theres also a good possibility Squid is sending the 403 as plain-text
instead of terminating or delivering TLS handshake data. But the
client/browser simply not showing it to you because well, browsers.
>
> 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.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
>
> Regards,
> John
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
