[squid-users] Encrypt CONNECT Header

[Matus UHLAR - fantomas]

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 <
>rousskov at 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, uhlar at 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.