[squid-users] ssl_bump with parent cache

[Alex Rousskov]

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