Discussion:
[squid-users] Squid-3.5.27 MITM stopped work after few minutes
Денис Степанов
2018-08-31 09:53:13 UTC
Permalink
Good day!
I have a some problem with Squid-3.5.27: after working of 15-20 minutes
appears problem with SubjectAlternativeName for any HTTPS websites (for
more details see
https://forum.netgate.com/topic/134054/squid-3-5-27-ssl-custom-works-few-minutes-mitm-breakdown
).
P.S. I can attach logs of last 5 minutes Squid's working and config file in
next message.

P.P.S. I was writing such message few times with attached files, but I
think, that it was dropped by antispam filters
Antony Stone
2018-08-31 10:03:26 UTC
Permalink
Post by Денис Степанов
Good day!
I have a some problem with Squid-3.5.27: after working of 15-20 minutes
appears problem with SubjectAlternativeName for any HTTPS websites (for
more details see
https://forum.netgate.com/topic/134054/squid-3-5-27-ssl-custom-works-few-mi
nutes-mitm-breakdown ).
That thread seems to deal exclusively with Chrome as the browser.

Please can you try the same tests with other browsers (Firefox, Safari, Opera,
Edge, whatever you have available) and report whether the results are
different?
Post by Денис Степанов
P.S. I can attach logs of last 5 minutes Squid's working and config file in
next message.
Yes, please do that (rather than posting multiple copies of the same message).


Regards,


Antony.
--
There's a good theatrical performance about puns on in the West End. It's a
play on words.

Please reply to the list;
please *don't* CC me.
Денис Степанов
2018-08-31 11:12:00 UTC
Permalink
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.

P.S. Sorry for spamming of the same message copies
Amos Jeffries
2018-08-31 13:05:44 UTC
Permalink
 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

Loading...