On 05.05.20 17:29, Ryan Le wrote:
The issue is not related to the server certificate SNI. It's related to
exposing a few other sensitive data points such as the domain which is
clearly exposed in the CONNECT header. This would be exposed regardless of
TLS 1.3.
not if you talk to the proxy over https.
you don't need "forward proxy over HTTPS to the proxy with ssl-bump"
you only need "proxy over https".
I wonder that you are OK with proxy doing ssl-bump then. You don't want
anyone to see traffic between browser and proxy, but are you OK that
the proxy will see what you browse on the destination servers?
Also, there are other headers that are sensitive and outside the
encrypted payload including User-Agent and Proxy-Authorization. The
Proxy-Authorization is of concern here. Most modern browsers now support
PAC with HTTPS versus PROXY.
The Proxy-Authorization can carry the Basic Auth (and NTLM) credentials
which is of concern currently since all users are mobile.
Being proactive before this become a problem at causes unnecessary
exposure. Zoom had a lot of issues and wouldn't want this to affect squid
or squid users.
well, using "https_port" on squid and connecting to squid over https is just
enough for you.
On Tue, May 5, 2020 at 11:33 AM Alex Rousskov <
rouss...@measurement-factory.com> wrote:
On 5/5/20 10:18 AM, Ryan Le wrote:
> Is there plans to support explicit forward proxy over HTTPS to the proxy
> with ssl-bump?
There have been a few requests for TLS-inside-TLS support, but I am not
aware of any actual sponsors or features on the road map. It is a
complicated project, even though each of its two components already
works today.
> We would like to use https_port ssl-bump without using the
> intercept or tproxy option. Clients will use PAC with a HTTPS directive
> rather than a PROXY directive. The goal is to also encrypted the CONNECT
> header which exposes the domain in plain text while it traverses to the
> proxy.
Yes, it is a valid use case (that few people understand).
> Felipe: you don't need to use ssl-bump with explicit https proxy.
Popular browsers barely support HTTPS proxies and refuse to delegate TLS
handling to them. Thus, a connection to a secure origin server will be
encrypted by the browser and sent over an encrypted channel through the
HTTPS proxy -- TLS-inside-TLS. If you want to look inside that browser
connection, you have to remove both TLS layers. To remove the outer
layer, you need an https_port in a forward proxy configuration. To
remove the inner layer, you need SslBump. The combination is not yet
supported.
> Matus: people will still be able to see SNI SSL header.
... but not the origin server SNI. Only the proxy SNI is exposed in this
use case, and that exposure is usually not a problem.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Remember half the people you know are below average.
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
