[squid-users] ssl_bump with parent cache

[Aaron Dewell]

Hi Alex, thanks for your reply! I did get access to the parent proxy and my assumption was wrong, it's doing minimal bumping. Also, the reason it's on 443 is to operate on a "standard" port for firewalls.
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.
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 better.
On Mar 8 2022, at 1:43 pm, Alex Rousskov <rousskov at measurement-factory.com> 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
>

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