[squid-users] Have issue with "https_port ssl-bump intercept"

[Amos Jeffries]

On 16/08/18 21:15, pius wrote:
> Hi,
> 
> We are planning to control the traffic that goes out from the network. Few
> of them are HTTPS. we managed to whitelist HTTP traffic that going out the
> network. And we are really happy about it. Now only worry we got is the
> HTTPS traffic. 
> 
> I listen 2 port in squid.  3129(HTTP) and 3130 (HTTPS). 
> 
> When we communicate https traffic to the outside world, we prefer to use
> 3130 so that we will have an end to end encryption. But at the same time, I
> need to whitelist some domain name so that only those domain name can be
> communicated safely. Is this is possible in squid?

Yes, provided that:
 1) only the domain name is wanted, and
 2 a) the client sends TLS SNI, and
 2 b) the server certificate confirms the TLS SNI

In that one case, you can use SSL-Bump peek and splice to retain the
encryption.

 acl whitelist ssl::server_name ...

 acl step1 at_step SslBump1
 acl step2 at_step SslBump2

 ssl_bump peek all
 ssl_bump splice whitelist
 ssl_bump terminate all

NP: you will still have to configure Squid with a self-signed CA cert
for the odd situations when Squid has to 'bump' to deliver errors to the
client.

Care also has to be taken to "allow" the CONNECT messages SSl-Bump
processing uses. These may appear in http_access etc. with raw-IP:port
only OR with non-whitelisted domains from TLS SNI.

The above config will only whitelist after the server cert is known and
should terminate TLS without any HTTP(S) error page being delivered to
clients - but can only do so if http_access does _not_ cause a "deny"
part way through the handshake (eg from on-whitelisted SNI names).


BTW; Please also be aware that TLS is *not* "end-to-end". It is only
point-to-point encryption. It is a mistake to think of it as fully
end-to-end. There are very likely multiple HTTP(S) network hops at both
client and server ends which are encrypted differently or unencrypted.

Amos