<div dir="ltr">Hello,<div><br></div><div>I have created a gist with the relevant parts of `cache.log` (post-connection) <a href="https://gist.github.com/randunel/5c0d282c52e9135aa21b8c6e28925a52">https://gist.github.com/randunel/5c0d282c52e9135aa21b8c6e28925a52</a></div><div><br></div><div>The following logs are available:</div><div><br></div><div>1. The initial HTTP CONNECT requests on port :8000 on line 51 <a href="https://gist.github.com/randunel/5c0d282c52e9135aa21b8c6e28925a52#file-3-cache-log-L51">https://gist.github.com/randunel/5c0d282c52e9135aa21b8c6e28925a52#file-3-cache-log-L51</a></div><div><br></div><div>2. The mark 0x10 is set on line 435 <a href="https://gist.github.com/randunel/5c0d282c52e9135aa21b8c6e28925a52#file-3-cache-log-L435">https://gist.github.com/randunel/5c0d282c52e9135aa21b8c6e28925a52#file-3-cache-log-L435</a></div><div><br></div><div>3. The redirected HTTPS request on port :8443 comes in, line 467 <a href="https://gist.github.com/randunel/5c0d282c52e9135aa21b8c6e28925a52#file-3-cache-log-L467">https://gist.github.com/randunel/5c0d282c52e9135aa21b8c6e28925a52#file-3-cache-log-L467</a></div><div><br></div><div>4. The forwarded CONNECT request is on line 526 <a href="https://gist.github.com/randunel/5c0d282c52e9135aa21b8c6e28925a52#file-3-cache-log-L526">https://gist.github.com/randunel/5c0d282c52e9135aa21b8c6e28925a52#file-3-cache-log-L526</a></div><div><br></div><div>5. X-My-Header is *NOT* found on line 966 <a href="https://gist.github.com/randunel/5c0d282c52e9135aa21b8c6e28925a52#file-3-cache-log-L966">https://gist.github.com/randunel/5c0d282c52e9135aa21b8c6e28925a52#file-3-cache-log-L966</a></div><div><br></div><div>5. The bumped contents are on line 1575 <a href="https://gist.github.com/randunel/5c0d282c52e9135aa21b8c6e28925a52#file-3-cache-log-L1575">https://gist.github.com/randunel/5c0d282c52e9135aa21b8c6e28925a52#file-3-cache-log-L1575</a> , where X-My-Header is visible</div><div><br></div><div><br></div><div>The following inconsistencies are seen:</div><div><br></div><div>a. The X-My-Header is *not* added to the CONNECT request according to config <a href="https://gist.github.com/randunel/5c0d282c52e9135aa21b8c6e28925a52#file-1-squid-conf-L19">https://gist.github.com/randunel/5c0d282c52e9135aa21b8c6e28925a52#file-1-squid-conf-L19</a></div><div>b. X-My-Header NOT found on line 966, although it is clearly visible on line 1579</div><div><br></div><div>-----</div><div><br></div><div>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.</div><div><br></div><div>Is there a way to determine the cache_peer based on ssl bumped contents?</div><div><br></div><div>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?</div><div><br></div><div>If not, is there a way to set the cache_peer based on the headers of the bumped request?</div><div><br></div><div>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?</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div></div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br><br><b>Mihai Ene</b><div><font color="#999999">Software Developer</font></div><div><font color="#999999"><br></font></div><div><b style="color:rgb(153,153,153);font-size:12.8000001907349px">UB | Your universal basket</b></div><div><font color="#999999"><br></font></div><div><font color="#999999"><a href="http://ub.io" target="_blank">http://ub.io</a></font></div><div><font color="#999999"><a href="mailto:me@ub.io" target="_blank">me@ub.io</a></font></div><div><span style="font-size:small">@shop_ub</span><br></div><div><font color="#999999"><a href="tel:+447473804972" value="+447881904476" target="_blank">+44 (0)7473 804972</a></font></div></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Fri, Jul 15, 2016 at 8:18 PM, Alex Rousskov <span dir="ltr"><<a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 07/15/2016 12:11 PM, Mihai Ene wrote:<br>
> I have a working ssl_bump<br>
> configuration when using direct connections. However, cache_peer and<br>
> cache_peer_access have req_header rules which aren't followed in bumped<br>
> connections.<br>
<br>
</span>If Squid has access to [fake or real] request headers, they should be<br>
available to ACLs.<br>
<span class=""><br>
<br>
> In logs, immediately after bumping, I see attempts to read X-My-Header<br>
> during cache_peer_access rules, and the header appears to always be<br>
> empty and ACLs always evaluate to 0, although the same logs show the<br>
> correct, expected X-My-Header later on, when forwarding the request.<br>
<br>
</span>I can think of two possibilities:<br>
<br>
1. When debugging, you are looking at CONNECT transactions (rather than<br>
HTTP requests inside bumped CONNECT tunnels) _and_ your CONNECT<br>
transactions do not have X-My-Header.<br>
<br>
2. It is a bug you should report.<br>
<br>
If there is an X-My-Header in CONNECT transactions that your Squid<br>
receives, see #2. Otherwise, see #1. You can use wireshark or Squid<br>
ALL,2 debugging to see CONNECT headers that Squid receives.<br>
<br>
The above assumes you are not intercepting SSL connections and are not<br>
dynamically adding X-My-Header to the received requests.<br>
<br>
<br>
HTH,<br>
<br>
Alex.<br>
<br>
</blockquote></div><br></div>