[squid-users] Wrong req_header result in cache_peer_access when using ssl_bump

[Mihai Ene]

Hello,

I have created a gist with the relevant parts of `cache.log`
(post-connection)
https://gist.github.com/randunel/5c0d282c52e9135aa21b8c6e28925a52

The following logs are available:

1. The initial HTTP CONNECT requests on port :8000 on line 51
https://gist.github.com/randunel/5c0d282c52e9135aa21b8c6e28925a52#file-3-cache-log-L51

2. The mark 0x10 is set on line 435
https://gist.github.com/randunel/5c0d282c52e9135aa21b8c6e28925a52#file-3-cache-log-L435

3. The redirected HTTPS request on port :8443 comes in, line 467
https://gist.github.com/randunel/5c0d282c52e9135aa21b8c6e28925a52#file-3-cache-log-L467

4. The forwarded CONNECT request is on line 526
https://gist.github.com/randunel/5c0d282c52e9135aa21b8c6e28925a52#file-3-cache-log-L526

5. X-My-Header is *NOT* found on line 966
https://gist.github.com/randunel/5c0d282c52e9135aa21b8c6e28925a52#file-3-cache-log-L966

5. The bumped contents are on line 1575
https://gist.github.com/randunel/5c0d282c52e9135aa21b8c6e28925a52#file-3-cache-log-L1575
, where X-My-Header is visible


The following inconsistencies are seen:

a. The X-My-Header is *not* added to the CONNECT request according to
config
https://gist.github.com/randunel/5c0d282c52e9135aa21b8c6e28925a52#file-1-squid-conf-L19
b. X-My-Header NOT found on line 966, although it is clearly visible on
line 1579

-----

The reason I was asking earlier whether this is the expected behaviour or
not, was because I was wondering whether the ACLs apply to the CONNECT
request contents, or to the ssl_bump contents.

Is there a way to determine the cache_peer based on ssl bumped contents?

If not, is there a way to add X-My-Header to the CONNECT request, as a
workaround to ssl bumped contents not following any ACLs?

If not, is there a way to set the cache_peer based on the headers of the
bumped request?

If there's nothing I can do about this, is there a way to set the
ssl_bumped cache_peer based on the earlier proxy_auth username?



*Mihai Ene*
Software Developer

*UB | Your universal basket*

http://ub.io
me at ub.io
@shop_ub
+44 (0)7473 804972 <+447473804972>

On Fri, Jul 15, 2016 at 8:18 PM, Alex Rousskov <
rousskov at measurement-factory.com> wrote:

> On 07/15/2016 12:11 PM, Mihai Ene wrote:
> > I have a working ssl_bump
> > configuration when using direct connections. However, cache_peer and
> > cache_peer_access have req_header rules which aren't followed in bumped
> > connections.
>
> If Squid has access to [fake or real] request headers, they should be
> available to ACLs.
>
>
> > In logs, immediately after bumping, I see attempts to read X-My-Header
> > during cache_peer_access rules, and the header appears to always be
> > empty and ACLs always evaluate to 0, although the same logs show the
> > correct, expected X-My-Header later on, when forwarding the request.
>
> I can think of two possibilities:
>
> 1. When debugging, you are looking at CONNECT transactions (rather than
> HTTP requests inside bumped CONNECT tunnels) _and_ your CONNECT
> transactions do not have X-My-Header.
>
> 2. It is a bug you should report.
>
> If there is an X-My-Header in CONNECT transactions that your Squid
> receives, see #2. Otherwise, see #1. You can use wireshark or Squid
> ALL,2 debugging to see CONNECT headers that Squid receives.
>
> The above assumes you are not intercepting SSL connections and are not
> dynamically adding X-My-Header to the received requests.
>
>
> HTH,
>
> Alex.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160718/819f88ec/attachment.html>