squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method

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

squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method

David Touzeau-3
  

Hi we want to use squid as * * * Secure Proxy * * * using https_port
We have tested major browsers and it seems working good.

To make it work, we need to deploy the proxy certificate on all browsers to make the secure connection running.

In this case, squid forward requests without decrypting them.because ssl-bump is not added.

But Adding the ssl-bump in https_port is not permitted :

"sl-bump on https_port requires tproxy/intercept which is missing"

why bumping is not allowed ?


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

Re: squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method

Amos Jeffries
Administrator
On 18/05/20 10:15 am, David Touzeau wrote:

>   
>
> Hi we want to use squid as * * * Secure Proxy * * * using https_port
> We have tested major browsers and it seems working good.
>
> To make it work, we need to deploy the proxy certificate on all browsers
> to make the secure connection running.
>
> In this case, squid forward requests without decrypting them.because
> ssl-bump is not added.
>
> But Adding the ssl-bump in https_port is not permitted :
>
> "sl-bump on https_port requires tproxy/intercept which is missing"
>
> why bumping is not allowed ?
>

Because origin server and explicit proxy traffic are mutually exclusive
syntax at the HTTP level, and use different types of SSL certificate at
the TLS level.

A "Secure proxy" receives explicit-proxy HTTP traffic over TLS. That
traffic gets decrypted normally on receipt by the https_port, using a
proxy server certificate.

SSL-Bump auto-generates a server certificate to decrypt with, and
expects origin form HTTP syntax once decrypted.


HTTPS traffic as we know it (CONNECT tunnels to port 443) might still be
sent to a secure proxy. In which case there are two layers of encryption
nested inside each other. Decrypting the interior layer of at is not yet
supported by Squid.


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

Re: squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method

Matus UHLAR - fantomas
>On 18/05/20 10:15 am, David Touzeau wrote:
>> Hi we want to use squid as * * * Secure Proxy * * * using https_port
>> We have tested major browsers and it seems working good.
>>
>> To make it work, we need to deploy the proxy certificate on all browsers
>> to make the secure connection running.
>>
>> In this case, squid forward requests without decrypting them.because
>> ssl-bump is not added.
>>
>> But Adding the ssl-bump in https_port is not permitted :
>>
>> "sl-bump on https_port requires tproxy/intercept which is missing"
>>
>> why bumping is not allowed ?

On 19.05.20 23:15, Amos Jeffries wrote:

>Because origin server and explicit proxy traffic are mutually exclusive
>syntax at the HTTP level, and use different types of SSL certificate at
>the TLS level.
>
>A "Secure proxy" receives explicit-proxy HTTP traffic over TLS. That
>traffic gets decrypted normally on receipt by the https_port, using a
>proxy server certificate.
>
>SSL-Bump auto-generates a server certificate to decrypt with, and
>expects origin form HTTP syntax once decrypted.

David, note that requiring browsers to connect to your proxy over encrypted
(https) connection, and then decrypting tunnels to real server will lower
the clients' security:
Clients will talk HTTPS to proxy, but proxy to server connection might be as
well unencrypted (or, decrypted by proxy).
This makes thinge like SSL authentication impossible.
I understand that you might scan connections for viruses or disabled
content, but the security will be harmed.

>HTTPS traffic as we know it (CONNECT tunnels to port 443) might still be
>sent to a secure proxy. In which case there are two layers of encryption
>nested inside each other. Decrypting the interior layer of at is not yet
>supported by Squid.

so, this is the real 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.
42.7 percent of all statistics are made up on the spot.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method

Alex Rousskov
In reply to this post by Amos Jeffries
On 5/19/20 7:15 AM, Amos Jeffries wrote:

> On 18/05/20 10:15 am, David Touzeau wrote:
>>   
>>
>> Hi we want to use squid as * * * Secure Proxy * * * using https_port
>> We have tested major browsers and it seems working good.
>>
>> To make it work, we need to deploy the proxy certificate on all browsers
>> to make the secure connection running.
>>
>> In this case, squid forward requests without decrypting them.because
>> ssl-bump is not added.
>>
>> But Adding the ssl-bump in https_port is not permitted :
>>
>> "sl-bump on https_port requires tproxy/intercept which is missing"
>>
>> why bumping is not allowed ?
>>
>
> Because origin server and explicit proxy traffic are mutually exclusive
> syntax at the HTTP level, and use different types of SSL certificate at
> the TLS level.
>
> A "Secure proxy" receives explicit-proxy HTTP traffic over TLS. That
> traffic gets decrypted normally on receipt by the https_port, using a
> proxy server certificate.
>
> SSL-Bump auto-generates a server certificate to decrypt with, and
> expects origin form HTTP syntax once decrypted.
>
>
> HTTPS traffic as we know it (CONNECT tunnels to port 443) might still be
> sent to a secure proxy. In which case there are two layers of encryption
> nested inside each other. Decrypting the interior layer of at is not yet
> supported by Squid.


David,

    Just to avoid misunderstanding: The answer to your question is in
the last sentence of the last paragraph by Amos -- Squid lacks the code
that is necessary to do what you want. There are no fundamental reasons
it cannot be done. 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.


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: squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method

Alex Rousskov
In reply to this post by Matus UHLAR - fantomas
>> On 18/05/20 10:15 am, David Touzeau wrote:
>>> Hi we want to use squid as * * * Secure Proxy * * * using https_port
>>> We have tested major browsers and it seems working good.
>>>
>>> To make it work, we need to deploy the proxy certificate on all browsers
>>> to make the secure connection running.

I hope that deployment is not necessary -- an HTTPS proxy should be
using a certificate issued for its domain name and signed by a
well-known CA already trusted by browsers. An HTTPS proxy is not faking
anything. If browsers do require CA certificate import in this
environment, it is their limitation.


On 5/19/20 9:24 AM, Matus UHLAR - fantomas wrote:
> David, note that requiring browsers to connect to your proxy over encrypted
> (https) connection, and then decrypting tunnels to real server will lower
> the clients' security

A proper SslBump implementation for HTTPS proxy will not be "decrypting
tunnels to real server". The security of such an implementation will be
the same as of SslBump supported today (plus the additional protections
offered by securing the browser-proxy communication).

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: squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method

David Touzeau-3
Thanks for the answer details

How to be a sponsor ? ( cost ) of such feature
Could you think it can be planned for 5.x ?
I think it should be a "future" "standard" in the same way of DNS over SSL

Le 19/05/2020 à 16:46, Alex Rousskov a écrit :
On 18/05/20 10:15 am, David Touzeau wrote:
Hi we want to use squid as * * * Secure Proxy * * * using https_port
We have tested major browsers and it seems working good.

To make it work, we need to deploy the proxy certificate on all browsers
to make the secure connection running.
I hope that deployment is not necessary -- an HTTPS proxy should be
using a certificate issued for its domain name and signed by a
well-known CA already trusted by browsers. An HTTPS proxy is not faking
anything. If browsers do require CA certificate import in this
environment, it is their limitation.


On 5/19/20 9:24 AM, Matus UHLAR - fantomas wrote:
David, note that requiring browsers to connect to your proxy over encrypted
(https) connection, and then decrypting tunnels to real server will lower
the clients' security
A proper SslBump implementation for HTTPS proxy will not be "decrypting
tunnels to real server". The security of such an implementation will be
the same as of SslBump supported today (plus the additional protections
offered by securing the browser-proxy communication).

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: squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method

Matus UHLAR - fantomas
In reply to this post by Alex Rousskov
>>> On 18/05/20 10:15 am, David Touzeau wrote:
>>>> Hi we want to use squid as * * * Secure Proxy * * * using https_port
>>>> We have tested major browsers and it seems working good.
>>>>
>>>> To make it work, we need to deploy the proxy certificate on all browsers
>>>> to make the secure connection running.

On 19.05.20 10:46, Alex Rousskov wrote:
>I hope that deployment is not necessary -- an HTTPS proxy should be
>using a certificate issued for its domain name and signed by a
>well-known CA already trusted by browsers. An HTTPS proxy is not faking
>anything. If browsers do require CA certificate import in this
>environment, it is their limitation.

That means, SSL connection from brower to the proxy will be encrypted and
signed by certificate installed on the proxy, which may be signed by public
authority, provided the proxy has public DNS name
(public authorities only sign public domains)

the traffic inside of the SSL tunnel will be standard proxy communication -
GET, POST, CONNECT requests.

CONNECT requests will ask the proxy to build tunnel to destination server,
which will usually contain encrypted HTTPS communication between browser and
final server.  So, CONNECT will create HTTPS connection (browser-server)
inside of HTTPS connection (browser-proxy)

>On 5/19/20 9:24 AM, Matus UHLAR - fantomas wrote:
>> David, note that requiring browsers to connect to your proxy over encrypted
>> (https) connection, and then decrypting tunnels to real server will lower
>> the clients' security
>
>A proper SslBump implementation for HTTPS proxy will not be "decrypting
>tunnels to real server". The security of such an implementation will be
>the same as of SslBump supported today (plus the additional protections
>offered by securing the browser-proxy communication).

If David wants to ssl-bump the traffic inside the HTTPS tunel (and I from
Davis's request I believe he wants to do that), it means that the
communication between browser and server has to be decrypted on squid, squid
will talk to server using HTTPS and create HTTPS endpoint to the client that
provides data, which means:

- squid will see the communication between browser and server
  (which is what HTTPS is designed to avoid)
- squid will need to dynamically creste certificated for sites it bumps
  using local CA
- clients will need to install the CA as trusted.

This is exactly what SSL Bump is about.

My point is that David wants to provide "secure" proxy which may compromise
the security instead by bumping connections.

I am not objecting against doing it, but I want to note that whole point of
HTTPS (where the "S" means secure) is that noone in the middle sees what is
the content of communication between client and server.

--
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.
On the other hand, you have different fingers.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method

Alex Rousskov
In reply to this post by David Touzeau-3
On 5/20/20 3:51 AM, David Touzeau wrote:

> How to be a sponsor?

There are many ways, including these two:

1. You privately find a developer (a person or an organization) and pay
them for implementing the changes you need.

2. You post an RFQ to squid-dev and solicit quotes/bids from developers.

If substantial changes you sponsored are officially accepted, you can
request to be officially listed in SPONSORS. Needless to say, you can
pull resources with other co-sponsors.

For a complex feature like TLS-inside-TLS bumping, please make sure that

a) The required architectural changes are deemed acceptable to the Squid
Project before the development starts. Otherwise, you may end up with a
large piece of code that you would have to pay somebody to maintain
forever. Such preliminary acceptance can be secured via discussions on
squid-dev. Such discussions should be initiated by (the developer)
posting a Request For Comments outlining major anticipated changes.

b) The developer will support the changes throughout Squid Project
review and initial deployment. It is very likely that the initial
version of the "working" code will need to be adjusted (for many reasons).

The following FAQ may be useful in this context:
https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F


> ( cost ) of such feature

That would be determined by the developer, subject to the usual business
negotiations (warranties, deadlines, backporting support, payment terms,
etc.). The most common pitfalls here are underestimating the complexity
of the changes, the overheads related to getting the changes officially
accepted, and medium-term support costs. FWIW, if I were to get a quote
that equates this project with a week worth of work, I would laugh at it.

Please note that the Squid Project itself does not do Squid development
and does not receive any money for Squid development. Some developers
contribute back to the Project (in various ways), but there is no
requirement to do so. This is typical for many open source projects, of
course.


> Could you think it can be planned for 5.x ?

IMO, no. The change is too big to qualify for any reasonable v5 freeze
exception. Squid v6 is your best bet right now. If the developer knows
what they are doing, there are ways to mitigate associated risks.


HTH,

Alex.


> Le 19/05/2020 à 16:46, Alex Rousskov a écrit :
>>>> On 18/05/20 10:15 am, David Touzeau wrote:
>>>>> Hi we want to use squid as * * * Secure Proxy * * * using https_port
>>>>> We have tested major browsers and it seems working good.
>>>>>
>>>>> To make it work, we need to deploy the proxy certificate on all browsers
>>>>> to make the secure connection running.
>> I hope that deployment is not necessary -- an HTTPS proxy should be
>> using a certificate issued for its domain name and signed by a
>> well-known CA already trusted by browsers. An HTTPS proxy is not faking
>> anything. If browsers do require CA certificate import in this
>> environment, it is their limitation.
>>
>>
>> On 5/19/20 9:24 AM, Matus UHLAR - fantomas wrote:
>>> David, note that requiring browsers to connect to your proxy over encrypted
>>> (https) connection, and then decrypting tunnels to real server will lower
>>> the clients' security
>> A proper SslBump implementation for HTTPS proxy will not be "decrypting
>> tunnels to real server". The security of such an implementation will be
>> the same as of SslBump supported today (plus the additional protections
>> offered by securing the browser-proxy communication).
>>
>> 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: squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method

Alex Rousskov
In reply to this post by Matus UHLAR - fantomas
On 5/20/20 6:02 AM, Matus UHLAR - fantomas wrote:
>> On 5/19/20 9:24 AM, Matus UHLAR - fantomas wrote:
>>> David, note that requiring browsers to connect to your proxy over
>>> encrypted (https) connection, and then decrypting tunnels to real server will
>>> lower the clients' security

> On 19.05.20 10:46, Alex Rousskov wrote:
>> A proper SslBump implementation for HTTPS proxy will not be "decrypting
>> tunnels to real server". The security of such an implementation will be
>> the same as of SslBump supported today (plus the additional protections
>> offered by securing the browser-proxy communication).

> If David wants to ssl-bump the traffic inside the HTTPS tunel, it means that the
> communication between browser and server has to be decrypted on squid,
> squid will talk to server using HTTPS

You are right. Due to insufficient shared terminology, we are simply
talking about two different things:

* I am talking about Squid (in a bumping HTTPS proxy role) sending
bumped requests to plain servers, exposing previously encrypted traffic.
While that is technically possible to support (in some cases) and even
occasionally explicitly requested (in a peering environment), that
should _not_ happen if the existing SslBump support is added to the
existing HTTPS proxy mode.

* You are talking about Squid (in a bumping HTTPS proxy role) inspecting
TLS traffic that the client meant for to origin servers eyes only. That
will happen, of course. This is what SslBump is about.


> My point is that David wants to provide "secure" proxy which may compromise
> the security instead by bumping connections.

Right. And my point is that adding SslBump support to HTTPS proxy does
not make things _worse_ as far as "security" and "privacy" are
concerned. Compared to using SslBump in an HTTP proxy, adding SslBump
support to HTTPS proxy may make things better. How much better depends
on your threat model, of course.

No sane person would argue that bumping is a good solution. My point was
that if you have to bump, then using an HTTPS proxy is not going to make
things worse.

It would be better if popular browsers would send plain https://... URLs
to an HTTPS proxy they trust, but they refuse to support that "GET
https" mode.


Cheers,

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