[squid-users] ssl_bump with parent cache

Tue Mar 8 22:56:22 UTC 2022

Ok, with a bit more messing with it... Changing bump to splice does work:
ssl_bump splice all
Adding:
acl step2 at_step SslBump2
ssl_bump peek step1
ssl_bump peek step2
ssl_bump splice step2

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.
This appears to be the relevant data from the log:
2022/03/08 14:35:47.644 kid1| 83,7| bio.cc(163) stateChanged: FD 10 now: 0x4004 TED (TLSv1.3 early data)
2022/03/08 14:35:47.644 kid1| 83,7| bio.cc(163) stateChanged: FD 10 now: 0x2002 SSLERR (error)
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)

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20220308/ebdf3508/attachment.htm>