[squid-dev] [PATCH] Support http_access denials of SslBump "peeked" connections.

[Amos Jeffries]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/12/2014 5:30 a.m., Tsantilas Christos wrote:
> Hi all,
> 
> 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


I see two separate bugs in your description:

1) For plain HTTP requests the bug is how the client CONNECT request
is getting past "http_access deny all" in the first place before
bumping is even considered to be an option.

That config should never be getting anywhere near bumping for plain
HTTP requests until *after* the CONNECT has decided to be accepted.

The call chain should be:
  httpAccept()->
  while parseOne() {
    processRequest() ->
    doCallouts {
      http_access ACLs,
      adaptation,
       etc
      httpStart[ bump | tunnel ]
    }
  }



2) For intercepted traffic the bug is probably absence of
implicit/fake CONNECT wrapper around the whole connection traffic
content. The fake CONNECT should be passed through http_access before
any traffic is allowed to flow.
 - if SNI is present, then fake with that otherwise fake with TCP dst-IP.

I think what we are missing for this #2 bug is really the earlier
proposed tcp_access (or a TLS equivalent).


> 
> 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.
> 
> Please read the Technical notes included in patch preamble.

While we are missing proper non-http_access ACL controls this change
is acceptible as a workaround for bug #2.

Can you check whether it also fixes bug #1 properly?

+1.

Amos

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUjilTAAoJELJo5wb/XPRj5yYIAMvhz44CBbx9kVIEzoNOsY3T
QELsFQ/LTQ1r3CdV8i0EMCF06uL9GH592oHPNWbkXivRXLmMqo38wmviAQSnMH8b
B6n4y128l95PUPgUW4NnzdaYuH6Xn+E6Y23GLFGlvARjrTiELGaz/EwP36nhk8Kx
ZDBssyyAvEbkVMNqglyJ75ETLS59fMKC3BBzbNZ4ZOAPpeR5N6mKlmTxDgabnXup
KgpnSrXnH2g+JP/PTrde5+gyt3NJtg4j7pDgxYIvAcaFTLD4Ms2M6WqT5adLmXmc
uY/kZpD1a7tjGLc0259633HpLoaKsdupi1jlE9etdf5n4VosASNk8IOLGyeW7fo=
=s1ZX
-----END PGP SIGNATURE-----