Encrypt CONNECT Header

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Encrypt CONNECT Header

Ryan Le
Is there plans to support explicit forward proxy over HTTPS to the proxy with
ssl-bump? 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.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Encrypt CONNECT Header

Felipe Polanco
I may be mistaken but I believe you don't need to use ssl-bump with explicit https proxy.

In your browser settings, use an HTTPS proxy instead of HTTP.

On Tue, May 5, 2020 at 10:19 AM Ryan Le <[hidden email]> wrote:
Is there plans to support explicit forward proxy over HTTPS to the proxy with
ssl-bump? 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.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Encrypt CONNECT Header

Matus UHLAR - fantomas
On 05.05.20 10:24, Felipe Polanco wrote:
>I may be mistaken but I believe you don't need to use ssl-bump with
>explicit https proxy.
>
>In your browser settings, use an HTTPS proxy instead of HTTP.

and squid needs https_port to accept https traffic.

>On Tue, May 5, 2020 at 10:19 AM Ryan Le <[hidden email]> wrote:
>> Is there plans to support explicit forward proxy over HTTPS to the proxy
>> with
>> ssl-bump? 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.

people will still be able to see SNI SSL header.

however, ssl-bump is different feature.

--
Matus UHLAR - fantomas, [hidden email] ; 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.
WinError #99999: Out of error messages.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Encrypt CONNECT Header

Alex Rousskov
In reply to this post by Ryan Le
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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Encrypt CONNECT Header

Ryan Le
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 <[hidden email]> 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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Encrypt CONNECT Header

Matus UHLAR - fantomas
In reply to this post by Ryan Le
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 <
>[hidden email]> 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, [hidden email] ; 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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Encrypt CONNECT Header

Amos Jeffries
Administrator
Alex has already covered the main point for your issue. The below are
details I think it worth you spending some time on in addition to the
encryption.


On 7/05/20 3:18 am, Matus UHLAR - fantomas wrote:
> On 05.05.20 17:29, Ryan Le wrote:
>> Proxy-Authorization is of concern here. Most modern browsers now support
>> PAC with HTTPS versus PROXY.
>

It sounds like you know something about the browser support. If you have
any more information than we document at
<https://wiki.squid-cache.org/Features/HTTPS#Encrypted_browser-Squid_connection>
please mention it.

>
>> The Proxy-Authorization can carry the Basic Auth (and NTLM) credentials
>> which is of concern currently since all users are mobile.

Only if the proxy explicitly requests those credentials. It is highly
recommended that you upgrade any insecure authentication protocols
regardless of whether TLS is used.

NTLM is the worst auth scheme and has been superseded by Kerberos
decades ago. Please at least upgrade that.


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users