Support http_access denials of SslBump "peeked" connections.
If an SSL connection is "peeked", it is currently not possible to deny it
with http_access. For example, the following configuration denies all plain
HTTP requests as expected but allows all CONNECTs (and all subsequent
encrypted/spliced HTTPS requests inside the allowed CONNECT tunnels):
http_access deny all
ssl_bump peek all
ssl_bump splice all
The bug results in insecure bumping configurations and/or forces admins to
abuse ssl_bump directive (during step1 of bumping) for access control (as a
partial workaround).
This change sends all SSL tunnels (CONNECT and transparent) through http_access
(and adaptation, etc.) checks during bumping step1. If (real or fake) CONNECT is
denied during step1, then Squid does not connect to the SSL server, but bumps
the client connection, and then delivers an error page (in response to the
first decrypted GET). The behavior is similar to what Squid has already been
doing for server certificate validation errors.
Technical notes
----------------
Before these changes:
* When a transparent SSL connection is being bumped, if we decide to splice
during step1, then we splice the connections without any http_access
checks. The (spliced) connection is always established.
* When a CONNECT tunnel is being bumped at step1, if peek/stare/server-first
mode is selected, and our http_access check fails, then:
1) We create an error page and proceeding with SSL bump, expecting
to serve the error after the client SSL connection is negotiated.
2) We start forwarding SSL Hello to the server, to peek/stare at (or
server-first bump) the server connection.
3) If we then decide to splice the connection during step2 or step3, then
we splice, and the error page never gets served to the client!
After these changes:
* During transparent SSL bumping, if we decide to splice at step1, do not
splice the connection immediately, but create a fake CONNECT request first
and send it through the callout code (http_access check, ICAP/ECAP, etc.).
If that fake CONNECT is denied, the code path described below kicks in.
* When an error page is generated during CONNECT or transparent bumping
(e.g. because an http_access check has failed), we switch to the
"client-first" bumping mode and then serve the error page to the client
(upon receiving the first regular request on the bumped connection).