[squid-users] Encrypt CONNECT Header

[Felipe Polanco]

If you need to encrypt the traffic between the browser and the proxy
perhaps you can use a VPN or a browser extension for this, that way your
traffic is encrypted on its way to the proxy.

On Tue, May 5, 2020 at 5:29 PM Ryan Le <ryanlele264 at gmail.com> wrote:

> Hi All,
> Thanks for providing the information.
> 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. 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.
>
> 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.
>>
>>
>> Cheers,
>>
>> Alex.
>>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20200506/84f74bc0/attachment-0001.html>