<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 6 Feb 2019 at 05:53, Amos Jeffries <<a href="mailto:squid3@treenet.co.nz">squid3@treenet.co.nz</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>It depends on what your policies are as to which is the better approach<br>to take. It is looking a bit like (2) is probably the way to go. With<br>the switch from dstdomain to server_name type for the ssl_bump<br>processing this issue may just disappear.<br>
<br></blockquote><div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Thank you, will try it tomorow.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>> <br>> by the way, my final goal is to enable https traffic through, not really<br>> intercept it, by trial and error and reading the mailing list, that<br>> config below is what seems to be working for me right now, can not<br>> confirm totally as parent proxy is not under my control, nor is the<br>> appliance, however from the access.log and system message logs, things<br>> look better than earlier. what is the best resource to understand the<br>> peek and splice, any good places other than squid cache main url?<br>> <br>
<br>The documentation of what modern Squid SSL-Bump feature does can be<br>found at <<a href="https://wiki.squid-cache.org/Features/SslPeekAndSplice" rel="noreferrer" target="_blank">https://wiki.squid-cache.org/Features/SslPeekAndSplice</a>>. It is<br>community maintained and kept as up to date as we can.<br>
<br>That page links to the relevant squid.conf documentation for the<br>relevant pieces. The whole TLS situation is a bit volatile so questions<br>are welcome here if you are unsure about anything in regards to your<br>specific Squid version, or observe things not matching that text.<br>
<br><span class="gmail_default" style="font-family:tahoma,sans-serif"> ..... ..... ...... </span><br>If you try to force things you will run up against the lack of<br>re-CONNECT features in Squid. That is Squid cannot yet generate CONNECT<br>tunnels through non-TLS peers like you have.<br>
<br>Given that the intercepted HTTPS traffic must leave Squid over secure<br>connections that effectively means it cannot use the peer as it normally<br>would and has to send that traffic via ORIGINAL_DST / DIRECT connections<br>to the HTTPS server. If those are forbidden the transaction has no<br>choice but to terminate with an error message.<br>
<br>
<br>FWIW: Measurement Factory have an experimental branch adding that<br>re-CONNECT functionality to Squid, if you are okay running alpha quality<br>code that may be of interest.<br> On the other side, I am working with a client on a configuration that<br>should result in the needed behaviour for the stable releases. That is<br>just entering testing and depends on whether they are willing for the<br>details to be published.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I am ok if it resolves my issues and does not introduce new bugs, I have some deadlines that I need to meet or otherwise drop all of this.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br><span class="gmail_default" style="font-family:tahoma,sans-serif"> </span>> #### Anonymous access to parent proxy<br>> <br>> #forwarded_for delete<br>> <br>> #request_header_access Surrogate-Capability deny all<br>> <br>
<br>FYI: the bug behind the S-C header problems is now fixed in v4.5<br>release. Once you upgrade this can be removed.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I am on v4.5</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br><span class="gmail_default" style="font-family:tahoma,sans-serif"> </span>> <br>> dns_v4_first on<br>> <br>> cache_peer 192.168.4.22 parent 9090 0 no-query<br>> #sslcapath=/etc/pki/ca-trust/source/anchors/ <br>> <br>> acl local-network dstdomain .<a href="http://azcompany.com" rel="noreferrer" target="_blank">azcompany.com</a> #<br>> tighten after finalizng troubleshooting, maybe replace with localnet<br>> <br>> http_access allow all<br>> <br>> never_direct deny local-network # revisit not using DNS for resolution<br>> <br>> never_direct allow all <br>> <br>> http_port 8080 intercept # should I really use intercept in here? can<br>> I get away without it<br>> <br>> https_port 8090 intercept ssl-bump generate-host-certificates=on <br>> cert=/etc/squid/ssl_certs/bccaz01CA.pem <br>> dynamic_cert_mem_cache_size=16MB #connection-auth=off<br>> <br>> http_port 8100 #forward port not used, only for troubleshooting.<br>> <br>> <br>> sslcrtd_program /usr/lib64/squid/security_file_certgen -s<br>> /var/spool/squid/ssl_db -M 4MB<br>> <br>> <br>> acl step1 at_step SslBump1<br>> <br>> acl azure_sites dstdom_regex <a href="http://microsoft.com" rel="noreferrer" target="_blank">microsoft.com</a> <<a href="http://microsoft.com" rel="noreferrer" target="_blank">http://microsoft.com</a>><br>> <a href="http://azure.com" rel="noreferrer" target="_blank">azure.com</a> <<a href="http://azure.com" rel="noreferrer" target="_blank">http://azure.com</a>> <a href="http://azureedge.net" rel="noreferrer" target="_blank">azureedge.net</a> <<a href="http://azureedge.net" rel="noreferrer" target="_blank">http://azureedge.net</a>><br>> <a href="http://microsoftazurestack.com" rel="noreferrer" target="_blank">microsoftazurestack.com</a> <<a href="http://microsoftazurestack.com" rel="noreferrer" target="_blank">http://microsoftazurestack.com</a>><br>> <a href="http://trafficmanager.net" rel="noreferrer" target="_blank">trafficmanager.net</a> <<a href="http://trafficmanager.net" rel="noreferrer" target="_blank">http://trafficmanager.net</a>> <a href="http://wdcp.microsoft.com" rel="noreferrer" target="_blank">wdcp.microsoft.com</a><br>> <<a href="http://wdcp.microsoft.com" rel="noreferrer" target="_blank">http://wdcp.microsoft.com</a>> <a href="http://wdcpalt.microsoft.com" rel="noreferrer" target="_blank">wdcpalt.microsoft.com</a><br>> <<a href="http://wdcpalt.microsoft.com" rel="noreferrer" target="_blank">http://wdcpalt.microsoft.com</a>> <a href="http://updates.microsoft.com" rel="noreferrer" target="_blank">updates.microsoft.com</a><br>> <<a href="http://updates.microsoft.com" rel="noreferrer" target="_blank">http://updates.microsoft.com</a>><br>> <br>> acl azure_sites2 dstdom_regex <a href="http://download.microsoft.com" rel="noreferrer" target="_blank">download.microsoft.com</a><br>> <<a href="http://download.microsoft.com" rel="noreferrer" target="_blank">http://download.microsoft.com</a>> <a href="http://msdl.microsoft.com" rel="noreferrer" target="_blank">msdl.microsoft.com</a><br>> <<a href="http://msdl.microsoft.com" rel="noreferrer" target="_blank">http://msdl.microsoft.com</a>> <a href="http://crl.microsoft.com" rel="noreferrer" target="_blank">crl.microsoft.com</a> <<a href="http://crl.microsoft.com" rel="noreferrer" target="_blank">http://crl.microsoft.com</a>><br>> <a href="http://secure.aadcdn.microsoftonline-p.com" rel="noreferrer" target="_blank">secure.aadcdn.microsoftonline-p.com</a><br>> <<a href="http://secure.aadcdn.microsoftonline-p.com" rel="noreferrer" target="_blank">http://secure.aadcdn.microsoftonline-p.com</a>><br>> <br>
<br>FYI: Regex is a slow procedure so when possible should be avoided. Since<br>all the above are domain names it looks like dstdomain would be better<br>with these ACL values. Some maybe using the wildcard dstdomain syntax.<br>
<br> acl azure_sites dstdomain .<a href="http://microsoft.com" rel="noreferrer" target="_blank">microsoft.com</a> \<br> .<a href="http://azure.com" rel="noreferrer" target="_blank">azure.com</a> .<a href="http://azureedge.net" rel="noreferrer" target="_blank">azureedge.net</a> \<br> .<a href="http://microsoftazurestack.com" rel="noreferrer" target="_blank">microsoftazurestack.com</a> .<a href="http://trafficmanager.net" rel="noreferrer" target="_blank">trafficmanager.net</a><br>
<br> acl azure_sites2 dstdomain .<a href="http://microsoft.com" rel="noreferrer" target="_blank">microsoft.com</a> \<br> <a href="http://secure.aadcdn.microsoftonline-p.com" rel="noreferrer" target="_blank">secure.aadcdn.microsoftonline-p.com</a></blockquote><div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Great, thanks, will use that definitely. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
<br>> ssl_bump peek step1<br>> <br>> ssl_bump splice azure_sites azure_sites2 #Avoid bumping Microsoft/Azure<br>> related sites<br>> <br>
<br>The way ACLs work in Squid items on a line like "azure_sites<br>azure_sites2" *both* have to match for the lines action to be used.<br>
<br>So the above line means all those domains except *.<a href="http://microsoft.com" rel="noreferrer" target="_blank">microsoft.com</a> will<br>*not* be spliced here even if a URL domain was available.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Sorry, I did not get that, is it because <a href="http://microsoft.com">microsoft.com</a> is duplicated by mistake twice on both lines? </div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Thank you Amos, you were great help.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Walid</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div></div></div>