<br><div>Ok, with a bit more messing with it...  Changing bump to splice does work:</div><br><div>ssl_bump splice all</div><br><div>Adding:</div><br><div>acl step2 at_step SslBump2</div><div>ssl_bump peek step1</div><div>ssl_bump peek step2</div><div>ssl_bump splice step2</div><br><div>Fails (back to the connection errors as with bump).  My guess is that this means it can splice at step1 but not step 2, which I know is more intrusive.  </div><br><div>This appears to be the relevant data from the log:</div><br><div>2022/03/08 14:35:47.644 kid1| 83,7| bio.cc(163) stateChanged: FD 10 now: 0x4004 TED (TLSv1.3 early data)</div><div>2022/03/08 14:35:47.644 kid1| 83,7| bio.cc(163) stateChanged: FD 10 now: 0x2002 SSLERR (error)</div><div>2022/03/08 14:35:47.644 kid1| Error negotiating SSL connection on FD 10: error:00000001:lib(0):func(0):reason(1) (1/-1)</div><br><div>at which point it starts freeing memory, etc.</div><br><div class="gmail_quote_attribution">On Mar 8 2022, at 2:57 pm, Alex Rousskov <rousskov@measurement-factory.com> wrote:</div><blockquote><div><div>On 3/8/22 16:38, Aaron Dewell wrote:</div><br><div>> Hi Alex, thanks for your reply!  I did get access to the parent proxy</div><div>> and my assumption was wrong, it's doing minimal bumping.</div><br><div>TLS inspection at the parent proxy does not affect what I was trying to</div><div>double check. What matters is whether it is a forward HTTP proxy (e.g.,</div><div>a Squid instance listening on an http_port configured without intercept,</div><div>tproxy, or accel flags). It sounds like that is what it is. That's OK!</div><br><div>I do not remember whether your Squid version (v4.13) supports SslBump</div><div>with parent forward proxies, but I believe modern Squids do, and we can</div><div>assume that your Squid version does as well. The debugging should show</div><div>whether that is indeed the case.</div><br><br><div>> The parent is doing peek and splice to an exact list of internal</div><div>> destinations.  Specifically, peek step1 all, peek step2 allowed_sites,</div><div>> splice allowed_sites, terminate all.  That shouldn't (to my imperfect</div><div>> knowledge) interfere with what I'm doing though.</div><br><div>Yes, assuming the parent does not terminate your Squid connections, of</div><div>course (i.e. assuming connections from your Squid always match</div><div>allowed_sites after step1 at the parent proxy).</div><br><br><div>> That's a good idea to do splice only and see if that's successful.</div><div>> Trying to do too much at once!  I'll see what that does, then try debug</div><div>> again.  The debug output wasn't very helpful before, but stepwise may be</div><div>> more useful.</div><br><div>Just to clarify: The debugging output was not meant for you to</div><div>interpret. A Squid developer should do that. It may contain sensitive</div><div>details; it is best to not use anything but test traffic and test</div><div>certificate keys when sharing ALL,9 output.</div><br><div>Alex.</div><br><br><div>> On Mar 8 2022, at 1:43 pm, Alex Rousskov wrote:</div><div>></div><div>> On 3/8/22 14:16, Aaron Dewell wrote:</div><div>></div><div>> > I'm trying to use these two features at the same time.  The use</div><div>> case is</div><div>> > pretty simple.  I want to capture all traffic from a single source (a</div><div>> > device of mine) to another squid proxy server and decrypt/log</div><div>> it.    I'm</div><div>> > using the Ubuntu 20 package of squid-ssl version 4.13.</div><div>> ></div><div>> > Device -> ssl_bump proxy -> upstream proxy -> website</div><div>> ></div><div>> > It was all successfully working without ssl_bump, so the cache_peer</div><div>> > configuration works.  One side note: the parent proxy is running</div><div>> on 443</div><div>> > without SSL (I believe - I don't run it but I've asked those that</div><div>> do for</div><div>> > confirmation, but I do know it's a pretty standard destination proxy</div><div>> > configuration).</div><div>> ></div><div>> > The website itself is not directly accessible thus the upstream</div><div>> proxy is</div><div>> > required.</div><div>> ></div><div>> > Adding the ssl_bump configuration caused it to not work, with errors</div><div>> > about SSL versions and "Error negotiating SSL connection on FD</div><div>> xx".  My</div><div>> > best guess is that it is attempting to establish an SSL connection to</div><div>> > the upstream and failing.</div><div>> ></div><div>> > acl step1 at_step SslBump1</div><div>> > ssl_bump peek step1</div><div>> > ssl_bump bump all</div><div>> > http_port 3128 ssl-bump cert=/var/lib/squid/ssl_cert/myCA.pem</div><div>> > generate-host-certificates=on dynamic_cert_mem_cache_size=4MB</div><div>> > tls_outgoing_options options=NO_SSLv3</div><div>> > flags=DON'T_VERIFY_PEER,DONT_VERIFY_DOMAIN</div><div>> > cert=/var/lib/squid/ssl_cert/device.pem</div><div>> > key=/var/lib/squid/ssl_cert/client.key</div><div>> ></div><div>> > (client.key and client.pem are from the device and are needed due</div><div>> to the</div><div>> > authentication of the session at the destination server.  Also, I</div><div>> > haven't looked at the packet logging yet. I assume that will be</div><div>> an easy</div><div>> > addition once the setup works generally.)</div><div>> ></div><div>> > However, my understanding is that the cache_peer configuration should</div><div>> > NOT do TLS by default unless that was specified in the options, and I</div><div>> > see no way to explicitly disable it.</div><div>> ></div><div>> > So first question: is that assumption accurate?  No TLS to the parent</div><div>> > unless explicitly configured?</div><div>></div><div>> Yes, that is correct: cache_peers are plain HTTP forward proxies unless</div><div>> explicitly configured otherwise. Their listening port value does carry</div><div>> any special meaning as far as Squid code is concerned.</div><div>></div><div>> However, it is very unusual to run a plain HTTP forward proxy on port</div><div>> 443. That port may imply that your parent proxy is an HTTPS reverse</div><div>> proxy. If it is, you need to use originserver flag when configuring the</div><div>> corresponding cache_peer line. You can check by sending plain CONNECT</div><div>> requests to that upstream proxy using wget, curl, or some such. A</div><div>> reverse HTTPS proxy would reject such requests.</div><div>></div><div>></div><div>> > if the ssl_bump configuration is causing it to attempt an upstream</div><div>> > TLS connection ...</div><div>></div><div>> Bugs notwithstanding, it should not.</div><div>></div><div>></div><div>> > Anything here that I'm doing obviously wrong?</div><div>></div><div>> I see no red flags relevant to your specific question.</div><div>></div><div>> Does replacing "bump all" with "splice all" fix the problem? I realize</div><div>> that you do want to bump/see the device traffic, but I wonder whether</div><div>> the errors are not between Squid and the upstream proxy but Squid and</div><div>> the web site. Splicing would remove those errors while still keeping</div><div>> some SslBump code active.</div><div>></div><div>> Sharing a (pointer to compressed) libpcap packet capture and/or a</div><div>> (pointer to compressed) ALL,9 cache.log while reproducing the problem</div><div>> with a single transaction may help:</div><div>> https://wiki.squid-cache.org/SquidFaq/BugReporting#Debugging_a_single_transaction</div><div>></div><div>> Alex.</div><div>> _______________________________________________</div><div>> squid-users mailing list</div><div>> squid-users@lists.squid-cache.org</div><div>> http://lists.squid-cache.org/listinfo/squid-users</div><div>></div><div>> Sent from Mailspring</div></div></blockquote><img class="mailspring-open" alt="Sent from Mailspring" width="0" height="0" style="border:0; width:0; height:0;" src="https://link.getmailspring.com/open/E24BC440-52BA-431A-A9AC-A6C5A1958101@getmailspring.com?me=3a79f6de&recipient=c3F1aWQtdXNlcnNAbGlzdHMuc3F1aWQtY2FjaGUub3Jn">