[squid-users] Squid blocking own OCSP/AIA requests

[Markus Wernig]

Hi all

I have configured Squid 4.0.18 (CentOS) with sslbump and clamav as
ecap_service. This works well.

One thing I've noticed though, are constant log entries like this in
access.log:

2017-03-21 10:35:08.338 +0100 000137 - TCP_DENIED/403 3607 GET
http://apps.identrust.com/roots/dstrootcax3.p7c - HIER_NONE/-
text/html;charset=utf-8 -
2017-03-21 10:35:08.345 +0100 000161 10.254.254.2 NONE/200 0 CONNECT
letsencrypt.org:443 - HIER_DIRECT/letsencrypt.org - -

It appears that this is the OCSP URI for Letsencrypt certificates.

And in fact every time this is logged, a CONNECT to a https uri is
logged that is using a Letsencrypt certificate (like eg.
https://letsencrypt.org).

Given that there is no client IP logged, I assume that squid is blocking
its own outgoing OCSP request here (the browser is configured to NOT use
OCSP).

The same seems to happen when there's no OCSP URI, but a regular AIA URI
in the certificate:

2017-03-21 10:36:19.773 +0100 000000 - TCP_DENIED/403 3734 GET
http://swisssign.net/cgi-bin/authority/download/5B257B96A465517EB839F3C078665EE83AE7F0EE
- HIER_NONE/- text/html;charset=utf-8 -
2017-03-21 10:36:19.782 +0100 000038 10.254.254.2 NONE/200 0 CONNECT
swisssign.net:443 - HIER_DIRECT/swisssign.net - -

I do have "http_access allow localhost" in squid.conf, but since there's
no IP associated with the request, this does not seem to help.

Is there a way to allow these outgoing internal requests? I've looked
through the FAQ and wiki, but couldn't find anything on the topic.

Thanks & best

/markus

[Alex Rousskov]

2017-03-21 10:35:08.338 +0100 000137 - TCP_DENIED/403 3607 GET http://apps.identrust.com/roots/dstrootcax3.p7c - HIER_NONE/- text/html;charset=utf-8 -
2017-03-21 10:35:08.345 +0100 000161 10.254.254.2 NONE/200 0 CONNECT letsencrypt.org:443 - HIER_DIRECT/letsencrypt.org - -
It appears that this is the OCSP URI for Letsencrypt certificates.
And in fact every time this is logged, a CONNECT to a https uri is
logged that is using a Letsencrypt certificate (like eg.
https://letsencrypt.org).
Given that there is no client IP logged, I assume that squid is blocking
its own outgoing OCSP request here

You are correct, but I would rephrase that to sound less masochistic:
Your http_access rules block Squid-generated requests, including
certificate download requests.

The same seems to happen when there's no OCSP URI, but a regular AIA URI
2017-03-21 10:36:19.773 +0100 000000 - TCP_DENIED/403 3734 GET http://swisssign.net/cgi-bin/authority/download/5B257B96A465517EB839F3C078665EE83AE7F0EE - HIER_NONE/- text/html;charset=utf-8 -
2017-03-21 10:36:19.782 +0100 000038 10.254.254.2 NONE/200 0 CONNECT swisssign.net:443 - HIER_DIRECT/swisssign.net - -

I do not remember whether the new certificate downloader feature
supports both OCSP and AIA, but your triage implies that it does. Same
access rules apply to all downloader requests.

I do have "http_access allow localhost" in squid.conf, but since there's
no IP associated with the request, this does not seem to help.

Correct. Regular "src" ACLs and their equivalents do not match internal
requests because they have no client [IP addresses].

Is there a way to allow these outgoing internal requests? I've looked
through the FAQ and wiki, but couldn't find anything on the topic.

This has been discussed on squid-users, and Factory is working on a
long-term solution. Meanwhile, there is a short-term workaround that may
work for you. Search for generatedBySquid at the following URL but do
read the follow up emails for possible problems you might face:

http://lists.squid-cache.org/pipermail/squid-users/2017-January/014224.html


HTH,

Alex.

[Markus Wernig]

Small update:

- The URL http://apps.identrust.com/roots/dstrootcax3.p7c is not the
OCSP responder, but the AIA for the Root CA (DST Root CA X3) embedded in
the issuing CA's certificate's CA Issuers.
- Same for
http://swisssign.net/cgi-bin/authority/download/5B257B96A465517EB839F3C078665EE83AE7F0EE:
AIA for Root CA.

Since squid is sslbumping the connection, it must be doing the AIA
lookups (presumably for SSL verification). Does anybody have an idea why
it is blocking its own requests?

Best /markus

Post by Markus Wernig
Hi all
I have configured Squid 4.0.18 (CentOS) with sslbump and clamav as
ecap_service. This works well.
One thing I've noticed though, are constant log entries like this in
2017-03-21 10:35:08.338 +0100 000137 - TCP_DENIED/403 3607 GET
http://apps.identrust.com/roots/dstrootcax3.p7c - HIER_NONE/-
text/html;charset=utf-8 -
2017-03-21 10:35:08.345 +0100 000161 10.254.254.2 NONE/200 0 CONNECT
letsencrypt.org:443 - HIER_DIRECT/letsencrypt.org - -
It appears that this is the OCSP URI for Letsencrypt certificates.
And in fact every time this is logged, a CONNECT to a https uri is
logged that is using a Letsencrypt certificate (like eg.
https://letsencrypt.org).
Given that there is no client IP logged, I assume that squid is blocking
its own outgoing OCSP request here (the browser is configured to NOT use
OCSP).
The same seems to happen when there's no OCSP URI, but a regular AIA URI
2017-03-21 10:36:19.773 +0100 000000 - TCP_DENIED/403 3734 GET
http://swisssign.net/cgi-bin/authority/download/5B257B96A465517EB839F3C078665EE83AE7F0EE
- HIER_NONE/- text/html;charset=utf-8 -
2017-03-21 10:36:19.782 +0100 000038 10.254.254.2 NONE/200 0 CONNECT
swisssign.net:443 - HIER_DIRECT/swisssign.net - -
I do have "http_access allow localhost" in squid.conf, but since there's
no IP associated with the request, this does not seem to help.
Is there a way to allow these outgoing internal requests? I've looked
through the FAQ and wiki, but couldn't find anything on the topic.
Thanks & best
/markus
_______________________________________________
squid-users mailing list
http://lists.squid-cache.org/listinfo/squid-users

[Alex Rousskov]

- The URL ... is the AIA for the Root CA
Since squid is sslbumping the connection, it must be doing the AIA
lookups (presumably for SSL verification). Does anybody have an idea why
it is blocking its own requests?

My answer has not changed:

http://lists.squid-cache.org/pipermail/squid-users/2017-March/014773.html

Did you expect your update to change that answer?

Alex.