Thank you, very helpful. Some more clarifying questions for you.
# HTTPS proxy; clients establish TLS connections to 31443 (your item #1)
https_port 31443 ssl-bump ...
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@xxxxxxxxxxxxxxxxxxxxxxx> 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.
>
>
>
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
