[squid-users] "ACCESS DENIED" page by ssl_bump terminate

Alex Rousskov rousskov at measurement-factory.com
Mon Mar 28 18:25:28 UTC 2016


On 03/28/2016 12:01 PM, Yuri Voinov wrote:
> 28.03.16 20:59, Alex Rousskov пишет:
>> On 03/27/2016 11:59 PM, Alexandr Yatskin wrote:
>>> Directive "deny_info" didn't work when we blocked https site with option
>>> "ssl_bump".


>> "deny_info" is not compatible with the ssl_bump "terminate" action. The
>> "terminate" action means "Close client and server connections". It is
>> impossible to serve an [error] response on a closed connection.

>> IIRC, blocking the CONNECT request (fake or real) with http_access is
>> enough to force Squid to respond with an "access denied" error -- Squid
>> should automatically bump the client connection (if that is still
>> possible when the CONNECT request is blocked) to serve an error response.


> I.e., to use deny_info bump is required?


I cannot respond to that question with a "yes" or "no" answer because
the question is imprecise and any answer is likely to mislead.


To serve an HTTP error to an SSL client, Squid has to establish an SSL
connection with that client. In SslBump environments, the latter usually
means bumping the client connection. Bumping the client connection may
happen implicitly (e.g., if http_access rules block fake or real
CONNECT) or explicitly (i.e., if an ssl_bump bump action matches during
one of the SslBump steps).

Outside of ssl-bump http_ports, it is possible to respond with a plain
Squid error to the real HTTP CONNECT request (i.e., without establishing
the SSL connection first). IIRC, older Squids used to do that in some
SslBump cases as well. If there is still such a way to do this for an
ssl-bump port, then please note that it will probably have no desirable
effect on most browsers because most browsers do not render HTTP [error]
responses to CONNECT requests.

The deny_info configuration is consulted after Squid has decided to deny
access and is generating an error page. AFAIK, the deny_info directive
itself does not affect the deny/allow decision and does not "know" the
context of that decision except for the ability to match the name of the
last http_access ACL evaluated (or equivalent).


HTH,

Alex.


More information about the squid-users mailing list