[squid-users] 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.

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, 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.
On the other hand, you have different fingers.