On 12/14/18 12:03 PM, Subhish Pillai wrote: > my use case for the squid proxy is to be able to accept a > HTTPS_proxy request from the client and tunnel it forward to the > destination server. > How do I get this to work without having to create self-signed certs on > the proxy server and importing that into the client ca-bundle. Get a server certificate from a CA authority that the client trusts, issued for the Squid proxy domain. Give Squid that certificate. For example, you may be able to use a free letsencrypt.org CA. An HTTPS proxy needs a certificate it can sign its traffic with. That certificate must be issued by a client-trusted CA. Whether that is a fake CA that you operate (what you may have referred to as a "self-signed cert" above) or a real CA trusted by millions of other clients (e.g., letsencrypt), is your choice. > For that I copied over the CA bundle from the client > into the proxy server and pointed the "tls-cert" option to that file Why? Please suggest specific documentation changes that would remove the implication that doing the above has something to do with your goals. That option is for specifying the signing certificate (i.e. the certificate the proxy is going to sign traffic with). > Am I missing any config steps in the squid.conf file? You are missing a clientca or tls-cafile option that triggers client certificate request (from Squid to client) and gives Squid CA certificates to trust when validating the client-supplied certificate. This is unrelated to the Squid signing certificate discussed above. Alex. > On Wed, Dec 12, 2018 at 6:53 PM Amos Jeffries <squid3@xxxxxxxxxxxxx > <mailto:squid3@xxxxxxxxxxxxx>> wrote: > > On 13/12/18 12:50 pm, Subhish Pillai wrote: > > Thanks Alex, that was very helpful. > > > > Based on your explanation, I just want to use squid as a blind TCP > > tunnel carrying the HTTPS connection from client to app server. > > > > In that case, I don't need to use ssl_bump feature and the ssl_crtd > > program for certificate management, is that correct? > > > > Going by the description you gave of the client configuration, it > should be. > > > > Would this config file work to setup the TCP tunnel -- > > ... > > ## Allow server side certificate errors such as untrusted > certificates, > > otherwise the connection is closed for such errors > > sslproxy_cert_error allow all > > > > ## Accept certificates that fail verification (should only be > needed if > > using 'sslproxy_cert_error allow all') > > sslproxy_flags DONT_VERIFY_PEER > > > > These sslproxy_* options only apply when Squid is actively performing > TLS to upstream servers. They have no place in the "blind tunnel" > situation. > (They also are deprecated in Squid-4, replaced by the > tls_outgoing_options directive > <http://www.squid-cache.org/Doc/config/tls_outgoing_options/>). > > If the client software is sending CONNECT requests containing the HTTPS > traffic, then there is absolutely nothing your config needs to do than > let them send those requests to the proxy (as the default config does). > > You do not even need Squid to be built with TLS/SSL support. That is the > meaning of "blind" in this setup. > > Amos > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > <mailto:squid-users@xxxxxxxxxxxxxxxxxxxxx> > http://lists.squid-cache.org/listinfo/squid-users > > > > -- > > *Subhish Pillai* > > R&D Software Quality Engineer > > Broadcom | Brocade Storage Networking > > T (720) 462-2900 > > > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
