[squid-users] Questions around https transparent chained proxy

[Amos Jeffries]

On 16/02/19 9:18 pm, Walid A. Shaari wrote:
> Greetings,
> 
> The end goal is enforcing an appliance(s) tls traffic to go through
> the corporate proxy, as I understand it (splice, not interested in
> decrypting)
> 
> http traffic works fine. however not clear 100% regarding https traffic.
> 
> 1) does the order of the below directives (ssl_bump, never_direct, and
> cacher_peer,..etc) matter where it is in the squid.conf file, or is it
> just the ACLs and ssl_bump that are order strict in squid.conf?

The order of these directives does not matter. They are for different
"hook" / decision points in the transaction.

Lines with the same directive name are order dependent. They are
inspected in the exact order configured.


> 
> ------ partial squid.conf  # is that order ok----
> ssl_bump peek all     # or should I just peek at step1
> ssl_bump splice  all
> #ssl_bump bump all   # not necessary in that case, traffic should have
> been already spliced
> never_direct allow all
> 
> cache_peer  upstream-proxy parent 8118 0 no-query no-digest
> ---------------------------
> 
> 2) What does the only-proxy option really means for cache-peer?

Responses received from that peer can only be proxied, not cached.


> 3) if the parent proxy is not using SSL/tls, however, the clients are
> using tls/SSL, is that an issue?

Maybe. Traffic which arrive encrypted must leave encrypted.

If you apply "bump" action to a TLS connection, the resulting https://
URL requests received on that connection cannot go to an insecure peer.

If you are only splicing, then the CONNECT _can_ go to these peers.
Since the traffic is still in its original encrypted form.


> 4) in an https transparent chained proxy scenario, is there a way I
> can get rid of exporting the squid proxy certificates to the clients?

You can choose not to do it.

If you are splicing, Squid should take no part in the crypto. Therefore
no X.509 cert generated by Squid will be delivered and the client has no
need of the custom CA to verify a non-existent cert.

If bumping ever occurs (eg to deliver an error message about TLS
failure). Then TLS clients will display warnings and popups about
inability to trust the server.

It is up to you whether that error handling case is important enough to
care.


> as the clients are part of an appliance that I do not have control
> over and not all traffic is actually originating from browsers?

Being a Browser is irrelevant. All TLS clients have this behaviour. Not
to do so is a violation of TLS security requirements (aka. insecure).


> 5)  Is squid 3.5 out of the Linux distro good enough, or should I
> upgrade to latest 4.x for a guaranteed splice functionality?


TLS environment is quite volatile, and Squid is constantly being updated
to cope with that and fix issues found in the implementation. Some major
changes cannot be backported without risking instability in 'stable'
series. Most small changes are not backported as a matter of policy.

An older version may be 'good enough' but for sure the latest release
will have less annoyances.


> the
> unofficial binary package for RHEL available is 3.5.27, while centos
> package is 4.5-1. shouldn't both be the same?


Eliezer does a fair bit of extra testing on his packages and they may
not all get updated at once. (I'm fairly sure he is open to funding if
you wish to sponsor any particular work.)


Amos