[squid-users] Fwd: Squid-3.5.27 MITM stopped work after few minutes

[Amos Jeffries]

On 31/08/18 11:12 PM, Денис Степанов wrote:
> 
> 
>  cache.log
> <https://drive.google.com/file/d/15PYj86Qv-pdiwSHV_0oLC8BsS-oCkzIV/view?usp=drive_web>
> 
>  squid.conf
> <https://drive.google.com/file/d/1IVT4VqIOELuAtQYd981ugpsrbaIEUp0O/view?usp=drive_web>
> 
> Such problem appears on Firefox browser too.
> 

The cache.log is not very useful because you configured Squid to not
even check any TLS/SSL problems:

 sslproxy_flags DONT_VERIFY_PEER


... and you told Squid not to bother telling you about any problems that
did come up:

  sslproxy_cert_error allow all

Please remove those lines from your config. They are both extremely bad
ideas. The problems still happen and still cause more issues - but only
your clients/users can see the nasty behaviour they cause.
 You *want* Squid to inform you about security problems. So you have a
chance to fix them before users come knocking.


Along with that your ssl_bump configuration tells Squid to peek at the
TLS clientHello and bump immediately - before any details such as server
name or server certificate features are known:

 # step 1 or step2 - only if domain is known AND matches
 ssl_bump splice noBump

 # step1 always
 ssl_bump peek step1

 # step2 always
 ssl_bump bump all

 # step3 never reached.


That is what we call client-first bumping and the behaviour you describe
as happening (certs generated when only IPs are known) is expected. That
and many other related problems are the reasons it was deprecated in
Squid-3.4 and replaced with the peek and splice feature.

If that type of bumping is what you want then the problem is something
you chose to happen. The side effects are yours.

Otherwise you need to have a rule doing "stare" action at step2 to get
server details before bumping - which then is at step3.
 Be aware that with stare any sites in noBump which Squid could not
identify at the step1 and step2 phases cannot be spliced but have to be
bump'd or terminate'd.


Amos