[squid-users] Help troubleshooting proxy<-->client https

[Masha Lifshin]

Thank you, very helpful.  Some more clarifying questions for you.

Sorry for the imprecise language, I mean not interception but rather
accepting connections to that port.  Our browsers will be explicitly
configured to connect our proxy, so I believe that is not interception?

If we want to only allow encrypted traffic between the browser and proxy,
does that mean we'd only want to use the following line from your example?

# HTTPS proxy; clients establish TLS connections to 31443 (your item #1)
https_port 31443 ssl-bump ...

Once a handshake is done and tls connection is established here, would it
be possible to have all http and https traffic from the browser go through
31443?  So squid would not need to have ports 80 and 443 open?

Thank you,
-Masha


On Wed, May 31, 2017 at 5:10 PM, Alex Rousskov <
rousskov at measurement-factory.com> wrote:

> On 05/31/2017 02:42 PM, Masha Lifshin wrote:
>
> > What I am trying to achieve is
>
>
> > 1. an https connection between the client and squid proxy, as well as
>
> > 2. listen on port 80 for http traffic,
>
> > 3. on port 443 for ssl traffic, and
>
> > 4. apply ssl-bump to the ssl traffic.
>
>
> If I parsed your query correctly, and by "listen" you mean "intercept",
> and you want to apply SslBump to proxied SSL traffic on all ports, then
> it looks like you will need three ports, each doing ssl-bump. In other
> words, instead of
>
> > http_port 80 ssl-bump cert=some.cert.pem ...
> > https_port 443 cert=other.cert.pem ...
>
> You will need something like this:
>
> # HTTPS proxy; clients establish TLS connections to 31443 (your item #1)
> https_port 31443 ssl-bump ...
>
> # HTTP-intercepting proxy (your item #2)
> http_port 80 intercept ssl-bump ...
>
> # SSL-intercepting proxy (your item #3)
> https_port 443 intercept ssl-bump ...
>
> You may need "tproxy" instead of "intercept", depending on how you are
> intercepting/forwarding traffic.
>
> The actual port numbers do no matter.
>
>
> > Also wondering what, if any, are the security issues with using port 80
> > for the http traffic?
>
> Anybody with access to that traffic will be able to easily see
> everything and, with a monumental effort, potentially occasionally
> modify unencrypted traffic, including plain CONNECT requests that
> establish secure channels.
>
>
> HTH,
>
> Alex.
>
>
> > On Fri, May 26, 2017 at 7:19 AM, Alex Rousskov wrote:
> >
> >     On 05/26/2017 12:00 AM, Masha Lifshin wrote:
> >     > I have added an https_port directive
> >     > to squid.conf, but it must be misconfigured.
> >
> >     > http_port 172.30.0.67:443 <http://172.30.0.67:443> ...
> >     > https_port 172.30.0.67:443 <http://172.30.0.67:443> ...
> >
> >     You are right -- your Squid is misconfigured. You cannot use the same
> >     address for two ports. Unfortunately, Squid thinks that port binding
> >     errors are a minor inconvenience and continues running after logging
> an
> >     error message (that looks like many other benign error messages).
> >
> >     Changing one of the ports will solve the "same address" problem
> >     described above.
> >
> >     Do not use port 443 for http_port. It makes triage extremely
> confusing
> >     because port 443 usually implies SSL. Consider using port 3128
> instead.
> >
> >
> >     HTH,
> >
> >     Alex.
> >
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20170531/de5006a8/attachment.html>