]> git.ipfire.org Git - thirdparty/squid.git/commit - src/client_side_request.cc
Support http_access denials of SslBump "peeked" connections.
authorChristos Tsantilas <chtsanti@users.sourceforge.net>
Tue, 16 Dec 2014 18:29:14 +0000 (20:29 +0200)
committerChristos Tsantilas <chtsanti@users.sourceforge.net>
Tue, 16 Dec 2014 18:29:14 +0000 (20:29 +0200)
commit9e104535d56af155cb1c51f82680f10d307259e7
tree06e733e3bd7ad944e854588eb631c0192b884e21
parent98340a7b8aeafac88486185909cb35d8e12830f8
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).

This is a Measurement Factory project.
src/client_side.cc
src/client_side_request.cc