<div dir="ltr"><div>Hi <i>ngtech1ltd,</i></div><div><i><br></i></div><div>Logformat:</div><div><i><br></i></div><div>logformat custom %ts.%03tu %>a %Ss/%03>Hs %ssl::>sni %ssl::bump_mode %ssl::<cert_subject %<A %err_code %err_detail<br>access_log daemon:/var/log/squid/custom.log custom</div><div><br></div><div>Complete config for https:</div><div><br></div><div># Handle HTTPS requests<br>https_port 3130 intercept ssl-bump cert=/etc/squid/ssl/squid.pem<br>acl SSL_port port 443<br>http_access allow SSL_port<br>acl step1 at_step SslBump1<br>acl step2 at_step SslBump2<br>acl step3 at_step SslBump3<br>ssl_bump peek step1 all<br><br># Deny requests to proxy instance metadat<br>acl instance_metadata dst 169.254.169.254<br>http_access deny instance_metadata<br><br># Filter HTTP requests based on the whitelist<br>acl allowed_http_sites dstdom_regex "/etc/squid/whitelist.txt"<br>http_access allow allowed_http_sites<br><br># Filter HTTPS requests based on the whitelist<br>acl allowed_https_sites ssl::server_name_regex "/etc/squid/whitelist.txt"<br>ssl_bump peek step2 allowed_https_sites<br>ssl_bump splice step3 allowed_https_sites<br>ssl_bump terminate step2 all<br><br>http_access deny all</div><div><br></div><div><br></div><div>TBH reproducing it could be pretty hard. As far as I know that connection comes from some agent that aws uses to grab data about what you are running on the EC2, that EC2 machine is pretty old (so almost sure is running an old agent version). I don´t see any usage on that service so I imagine is not activate. Also the behavior I imagine has something to do with AWS processing that connection and failing (for example because the Squid machine has no rights to use it). Really the only strange thing is that it logs 500 and TCP_TUNNEL, there is no way I can check if something else is going on. Honestly if you don´t see the motive why it logs 500 and TCP_TUNNEL I would probably give up on that... Is the only I spot strange. <br></div><div><br></div><div>I just took and old subnet and put there the Squid for some testing, then I saw that (among a lot else logs that were going fine) there were one strange log every few seconds and didn´t understand what´s going on. I was thinking that it was my config file since I read a lot of blogs saying that HTTPS transparent proxy without certificate was not possible (it looks like it is). So I focused on fixing that but after trying a lot of different sslbumb combinations I didn´t fix that. <br></div><div><br></div><div><br></div><div>Thanks!<br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El jue, 1 dic 2022 a las 16:41, Gabriel Vilariño (<<a href="mailto:gvilarino6@gmail.com">gvilarino6@gmail.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi there,</div><div><br></div><div>Sorry for the delay. I have problems to only log 1 request. <br></div><div><br></div><div>I removed the internal ip that makes the request and one internal dns, but dont think that´s important. Also removed all machines that weren´t producing this traffic so we should only have the AWS arsernal request (on the access.log I only see one but could be a second one, however all of those produce exact same result).</div><div><br></div><div>About the motivation Alex, really the only thing that concerns me is the strange log (TCP_TUNNEL and error 500). On the usage side, I can not tell if that call is working (going trough or not) since I don´t even use that service. I was evaluating how Squid works and simply run in that strange log. My final objective is to simply understand what´s going on (tunnel or 500) but there is nothing critical that I have to fix. <br></div><div><br></div><div>Link: <a href="https://privfile.com/download.php?fid=6388c98c4ad19-MTQ5ODM=" target="_blank">https://privfile.com/download.php?fid=6388c98c4ad19-MTQ5ODM=</a> is valid for one day, password is "pepe" without "".<br></div><div><br></div><div>Thanks!<br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mié, 30 nov 2022 a las 9:16, Gabriel Vilariño (<<a href="mailto:gvilarino6@gmail.com" target="_blank">gvilarino6@gmail.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi again!</div><div><br></div><div>Thanks for the info!</div><div><br></div><div>Log with error code and error detail at the end, both "-":<br></div><div>1669794718.051 INTERNAL_IP <b>TCP_TUNNEL/500</b> <a href="http://arsenal.us-west-2.amazonaws.com" target="_blank">arsenal.us-west-2.amazonaws.com</a> splice /CN=<a href="http://arsenal.us-west-2.amazonaws.com" target="_blank">arsenal.us-west-2.amazonaws.com</a> 54.240.254.131<b> - -</b></div><div><br></div><div>The cache.log with ALL,1 does not look to share a lot, in fact I don´t see any messages referencing this transaction:</div><div><br></div><div>22/11/30 07:51:39 kid1| Current Directory is /<br>2022/11/30 07:51:39 kid1| Creating missing swap directories<br>2022/11/30 07:51:39 kid1| No cache_dir stores are configured.<br>2022/11/30 07:51:39| Removing PID file (/run/squid.pid)<br>2022/11/30 07:51:39 kid1| Current Directory is /<br>2022/11/30 07:51:39 kid1| Starting Squid Cache version 5.7 for x86_64-pc-linux-gnu...<br>2022/11/30 07:51:39 kid1| Service Name: squid<br>2022/11/30 07:51:39 kid1| Process ID 64694<br>2022/11/30 07:51:39 kid1| Process Roles: worker<br>2022/11/30 07:51:39 kid1| With 1024 file descriptors available<br>2022/11/30 07:51:39 kid1| Initializing IP Cache...<br>2022/11/30 07:51:39 kid1| DNS Socket created at [::], FD 9<br>2022/11/30 07:51:39 kid1| DNS Socket created at 0.0.0.0, FD 10<br>2022/11/30 07:51:39 kid1| Adding nameserver 127.0.0.53 from /etc/resolv.conf<br>2022/11/30 07:51:39 kid1| Adding domain dev.ops.mitekcloud.local from /etc/resolv.conf<br>2022/11/30 07:51:39 kid1| helperOpenServers: Starting 5/32 'security_file_certgen' processes<br>2022/11/30 07:51:39 kid1| Logfile: opening log daemon:/var/log/squid/custom.log<br>2022/11/30 07:51:39 kid1| Logfile Daemon: opening log /var/log/squid/custom.log<br>2022/11/30 07:51:40 kid1| Local cache digest enabled; rebuild/rewrite every 3600/3600 sec<br>2022/11/30 07:51:40 kid1| Store logging disabled<br>2022/11/30 07:51:40 kid1| Swap maxSize 0 + 262144 KB, estimated 20164 objects<br>2022/11/30 07:51:40 kid1| Target number of buckets: 1008<br>2022/11/30 07:51:40 kid1| Using 8192 Store buckets<br>2022/11/30 07:51:40 kid1| Max Mem  size: 262144 KB<br>2022/11/30 07:51:40 kid1| Max Swap size: 0 KB<br>2022/11/30 07:51:40 kid1| Using Least Load store dir selection<br>2022/11/30 07:51:40 kid1| Current Directory is /<br>2022/11/30 07:51:40 kid1| Finished loading MIME types and icons.<br>2022/11/30 07:51:40 kid1| HTCP Disabled.<br>2022/11/30 07:51:40 kid1| Pinger socket opened on FD 27<br>2022/11/30 07:51:40 kid1| Squid plugin modules loaded: 0<br>2022/11/30 07:51:40 kid1| Adaptation support is off.<br>2022/11/30 07:51:40 kid1| Accepting HTTP Socket connections at conn13 local=[::]:3128 remote=[::] FD 23 flags=9<br>2022/11/30 07:51:40 kid1| Accepting NAT intercepted HTTP Socket connections at conn15 local=[::]:3129 remote=[::] FD 24 flags=41<br>2022/11/30 07:51:40 kid1| Accepting NAT intercepted SSL bumped HTTPS Socket connections at conn17 local=[::]:3130 remote=[::] FD 25 flags=41<br>2022/11/30 07:51:40| pinger: Initialising ICMP pinger ...<br>2022/11/30 07:51:40| pinger: ICMP socket opened.<br>2022/11/30 07:51:40| pinger: ICMPv6 socket opened<br>2022/11/30 07:51:41 kid1| storeLateRelease: released 0 objects<br>2022/11/30 07:52:09 kid1| Preparing for shutdown after 3 requests</div><div>... Starts ending the connections for shutdown, ends with next message...</div><div><b>2022/11/30 07:52:40 kid1| Squid Cache (Version 5.7): Exiting normally.</b></div><div><br></div><div>I checked with further log levels but it outputs a lot of data (I know this one is not for admins, I wanted to try to sent only the relevant logs since those aws agents do several calls and I was not to only record one transaction). Also if I needed, this is shared as an attachment? <br></div><div><br></div><div>Thanks in advance!<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mar, 29 nov 2022 a las 21:52, Gabriel Vilariño (<<a href="mailto:gvilarino6@gmail.com" target="_blank">gvilarino6@gmail.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Thanks Alex!</div><div><br></div><div>Here are the fixed logs:</div><div><span><span><span><code style="white-space:pre-wrap"><span>1669726977.734 INTERNAL_CLIENT_IP TCP_TUNNEL/500 <a href="http://arsenal.us-west-2.amazonaws.com" target="_blank">arsenal.us-west-2.amazonaws.com</a> splice /CN=<a href="http://arsenal.us-west-2.amazonaws.com" target="_blank">arsenal.us-west-2.amazonaws.com</a> 54.240.251.223</span></code></span></span></span></div><div><span><span><span><code style="white-space:pre-wrap"><span><br></span></code></span></span></span></div><div><span><span><span><code style="white-space:pre-wrap"><span><span style="font-family:arial,sans-serif">As you can see, the destination is an aws service, more interesting, it effectively <b>logs the splice</b> action! That´s why I though it was letting the traffic go trough. Also the debug logs fr</span>om SSL show this:</span></code></span></span></span></div><div><span><span><span><code style="white-space:pre-wrap"><span><span><span><span><code style="white-space:pre-wrap">2022/11/29 10:32:38.943 kid1| 83,5| PeekingPeerConnector.cc(273) <b>startTunneling: will tunnel instead of negotiating TLS</b>  # Last line from previously attached logs</code></span></span></span></span></code></span></span></span></div><div><span><span><span><code style="white-space:pre-wrap"><span><span><span><span><code style="white-space:pre-wrap"><br></code></span></span></span></span></code></span></span></span></div><div><span><span><span><code style="white-space:pre-wrap"><span><span><span><span><code style="white-space:pre-wrap"><span style="font-family:arial,sans-serif">As far as I know this means <b>is getting to the TCP_TUNNEL, at that point it can not know anything about the internal status on the connection between client and host</b>. If not, <b>where I should be looking for this error? </b>Should try to review further the debug ssl logs to se if I fend something more useful? Maybe tcpdump? This could be just the end service failing on the request? Or is an error between Squid and the end sever?</span></code></span></span></span></span></code></span></span></span></div><div><span><span><span><code style="white-space:pre-wrap"><span><span><span><span><code style="white-space:pre-wrap"><span style="font-family:arial,sans-serif"><br></span></code></span></span></span></span></code></span></span></span></div><div><span><span><span><code style="white-space:pre-wrap"><span><span><span><span><code style="white-space:pre-wrap"><span style="font-family:arial,sans-serif">If I understand right the request that fails is the fake connect and I need to understand why. Also note almost same config logged this as TCP_TUNNEL/200 on version 3.5.</span> <span style="font-family:arial,sans-serif">But as said before, I really not sure how to check, since that service is just an agent installed on some aws machines and don´t know how to reproduce this behavior. </span><br></code></span></span></span></span></code></span></span></span></div><div><div><span><span><span><code style="white-space:pre-wrap"><span><br></span></code></span></span></span></div><div><span><span><span><code style="white-space:pre-wrap"><span><br></span></code></span></span></span></div><div><span><span><span><code style="white-space:pre-wrap"><span><br></span></code></span></span></span></div><div><span><span><span><code style="white-space:pre-wrap"><span><br></span></code></span></span></span></div><div><span><span><span><code style="white-space:pre-wrap"><span><span style="font-family:arial,sans-serif">Thanks again! Hope I answered fine since I didn´t get the answer email.</span><br></span></code></span></span></span></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mar, 29 nov 2022 a las 14:06, Gabriel Vilariño (<<a href="mailto:gvilarino6@gmail.com" target="_blank">gvilarino6@gmail.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Just got it solved. Was caused because of checking default access.log. Using a new file solves all the problems. <br></div><div><br></div><div>However, in this context, what means TCP_TUNNEL/500? is it because the TLS handshake? I would like to know if it is tunneling correctly or is having some trouble (not easy to test right now).</div><div><br></div><div>Thanks!<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mar, 29 nov 2022 a las 13:16, Gabriel Vilariño (<<a href="mailto:gvilarino6@gmail.com" target="_blank">gvilarino6@gmail.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi there,</div><div><br></div><div>I am setting up an HTTP/HTTPS transparent proxy, meaning the clients not need any certificates for using the proxy. This works fine on version 3.5 of Squid, however after upgrading to 5.7 the behavior of the logs change:</div><div><br></div><div>1669723133.174   8037 10.184.19.220 TCP_TUNNEL/500 6207 CONNECT <a href="http://54.240.253.128:443" target="_blank">54.240.253.128:443</a> - ORIGINAL_DST/<a href="http://54.240.253.128" target="_blank">54.240.253.128</a> -</div><div><br></div><div>Directive: logformat squid %ts.%03tu %>a %Ss/%03>Hs %ssl::>sni %ssl::bump_mode ssl::>cert_subject %<ru</div><div><br></div><div>On version 3.5 we were obtaining the domain name (an aws service) in the place of ORIGINAL_DST. Also now we are not seeing any information about the bump_mode in no one of the connections while before we were seeing it. One could trough that it could be because of the /500 message, however on a 200 one to <a href="http://docs.ansble.com" target="_blank">docs.ansble.com</a> it also don´t show any data on the sni field:</div><div><br></div><div>1669723513.363    332 10.184.19.220 TCP_TUNNEL/200 38192 CONNECT <a href="http://104.26.0.234:443" target="_blank">104.26.0.234:443</a> - ORIGINAL_DST/<a href="http://104.26.0.234" target="_blank">104.26.0.234</a> -</div><div><br></div><div>Also the 500 looks to come from the squid not understanding something on the SSL negotiation:<br></div><div><br></div><span><span><span><code style="white-space:pre-wrap"><span>2022/11/29 10:32:38.943 kid1| 83,4| support.cc(248) check_domain: Verifying server domain <a href="http://arsenal.us-west-2.amazonaws.com" target="_blank">arsenal.us-west-2.amazonaws.com</a> to certificate name/subjectAltName <a href="http://arsenal.us-west-2.amazonaws.com" target="_blank">arsenal.us-west-2.amazonaws.com</a>
</span></code></span></span></span><span><span><span><code style="white-space:pre-wrap">2022/11/29 10:32:38.943 kid1| 83,5| bio.cc(136) read: FD 28 read 347 <= 65535
</code></span></span></span><span><span><span><code style="white-space:pre-wrap">2022/11/29 10:32:38.943 kid1| 83,5| Io.cc(91) Handshake: -1/0 for TLS connection 0x558453168970 over conn99 local=SQUID-INTERNAL-IP:44264 remote=<a href="http://54.240.251.223:443" target="_blank">54.240.251.223:443</a> ORIGINAL_DST FD 28 flags=1
</code></span></span></span><span><span><span><code style="white-space:pre-wrap">2022/11/29 10:32:38.943 kid1| 83,2| PeerConnector.cc(256) handleNegotiationResult: ERROR: failure while establishing TLS connection on FD: 280x558452b68980*1
</code></span></span></span><span><span><span><code style="white-space:pre-wrap">2022/11/29 10:32:38.943 kid1| 83,5| NegotiationHistory.cc(85) retrieveNegotiatedInfo: SSL connection info on FD 28 SSL version NONE/0.0 negotiated cipher 
</code></span></span></span><span><span><span><code style="white-space:pre-wrap">2022/11/29 10:32:38.943 kid1| 83,5| PeekingPeerConnector.cc(84) checkForPeekAndSpliceMatched: Will check for peek and splice on FD 28
</code></span></span></span><span><span><span><code style="white-space:pre-wrap">2022/11/29 10:32:38.943 kid1| 83,5| PeekingPeerConnector.cc(395) serverCertificateVerified: HTTPS server CN: <a href="http://arsenal.us-west-2.amazonaws.com" target="_blank">arsenal.us-west-2.amazonaws.com</a> bumped: conn99 local=SQUID-INTERNAL-IP:44264 remote=<a href="http://54.240.251.223:443" target="_blank">54.240.251.223:443</a> ORIGINAL_DST FD 28 flags=1
</code></span></span></span><div><span><span><span><code style="white-space:pre-wrap">2022/11/29 10:32:38.943 kid1| 83,5| PeekingPeerConnector.cc(273) startTunneling: will tunnel instead of negotiating TLS</code></span></span></span></div><div><br></div><div>It is clear that in creates the tunnel so the 500 probably is that error? Why the bump/sni messages never log anything (according to <a href="https://wiki.squid-cache.org/Features/SslPeekAndSplice" target="_blank">https://wiki.squid-cache.org/Features/SslPeekAndSplice</a> they should log splice not -). This is the config for bumping:</div><div><br></div><div><br></div><div><br></div><div>acl step1 at_step SslBump1<br>acl step2 at_step SslBump2<br>acl step3 at_step SslBump3<br>ssl_bump peek step1 all</div><div><br></div><div>.... http rules ...<br></div><div><br></div><div>acl allowed_https_sites ssl::server_name_regex "/etc/squid/whitelist.txt"<br>ssl_bump peek step2 allowed_https_sites<br>ssl_bump splice step3 allowed_https_sites<br>ssl_bump terminate step2 all</div><div><br></div><div><br></div><div><br></div><div><br></div><div>Ip tables simply redirect:</div><div><br></div><div>iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3129</div><div>iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 3130 # https port on squid: https_port 3130 intercept ssl-bump cert=/etc/squid/ssl/dummy.pem</div><div><br></div><div>Thanks in advance, i have been trying this for a week now reading a lot of posts but not luck...<br></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>