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?
On Fri, Jul 15, 2016 at 8:18 PM, Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> 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.
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
