On 1/4/22 2:35 AM, Will BMD wrote:
HTTP proxy limitationThe system cannot decrypt traffic if an HTTP proxy is positioned between a client and your managed device, and the client and server establish a tunneled TLS/SSL connection using the CONNECT HTTP method. The Handshake Errors undecryptable action determines how the system handles this traffic.
I ... don't know what to make of this. I would have some questions for the vendor (Cisco).
This sort of hints at a technical limitation that the Cisco FTDv /might/ have. It sounds to me like the firewall might be able to pretend to be a web server via interception of some sort, but that it can't handle HTTP's CONNECT verb which is common to sue on proxies particularly for HTTPS connections.
I'm fairly certain that Squid /does/ support bumping such CONNECT requests.This also hints at /needing/ ~> /requiring/ the downstream client devices to /not/ be configured to use the firewall as a proxy. Because if the clients are configured to use the firewall as a proxy, they will inherently issue CONNECT requests.
More questions. This itches like a limitation.It also /really/ seems to me like Squid /should/ be able to work behind this as long as it has the proper public root certificate that is used to support the (re)signing.
Okay, what if we removed the firewall and replaced it with another squid proxy server, where that is also doing ssl_bump. I assume this would work but are there negative implications of doing so?
I would /expect/ that two Squid servers could work in this type of configuration. It's my understanding that Squid has support for parent / child proxy hierarchies that would apply to this. Even if it did not, I think that two simple ssl_bump Squid servers /should/ work with each other. Proper certificate trust configuration not withstanding.
-- Grant. . . . unix || die
<<attachment: smime.p7s>>
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
