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

[Alex Rousskov]

On 05/31/2017 08:15 PM, Masha Lifshin wrote:
> 
> 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?

You are correct. It is explicit proxying, 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 ...

Yes.

Again, the actual port number does not matter here as long as the
browser is configured to use the same port. I would not use 3128, 80, or
443 because, to many people, those numbers mean something different than
an "HTTPS proxy" port. My 31443 suggestion is based on an
unregistered(?) port that "looks like" a combination of registered or
well-known ports 3128 and 443. FWIW, many products use ports ending with
443 for similar purposes AFAICT.


> 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?

Yes, provided the browser supports HTTPS proxies, of course. Several
popular browsers do, but not all HTTP clients support HTTPS proxies.
Also, it is difficult to configure the popular browsers to do what you
want; the required configuration changes are _not_ available through the
regular browser configuration interface. After you figure browser
configuration out, please consider writing a Squid wiki entry to
document your findings.


Thank you,

Alex.



> On Wed, May 31, 2017 at 5:10 PM, Alex Rousskov 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>
>     <http://172.30.0.67:443> ...
>     >     > https_port 172.30.0.67:443 <http://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.
>     >
>     >
>     >
> 
> 
>