On 06/12/17 06:29, Alex Rousskov wrote:
On 12/05/2017 10:05 AM, erdosain9 wrote:
"Does that error match the generated certificate sent by Squid to a
blocked Chrome user? In other words, does that certificate have an
invalid common name (CN) field? "
No, is the same certificate.
Your statement does not answer my question. I can ask a different
question if you prefer: What is is common name (CN) field of the
generated certificate sent by Squid to a blocked Chrome user?
"I suggest comparing the following two certificates:
* the certificate sent by Squid to a blocked FireFox user
* the certificate sent by Squid to a blocked Chrome user "
Is the same certificate.
How do you compare the two certificates?
"I also suggest comparing the following access.log entries:
* the line(s) corresponding to the blocked FireFox user request
* the line(s) corresponding to the blocked Chrome user request "
Line corresponding to blocked Chrome
1512493257.523 175 192.168.1.121 TCP_DENIED/200 0 CONNECT es-la.facebook.com:443 user@xxxxxxxxxx HIER_NONE/- -
1512493257.716 169 192.168.1.121 TCP_MISS/204 193 GET http://www.gstatic.com/generate_204 user@xxxxxxxxxx HIER_DIRECT/172.217.30.163 -
The allowed GET request looks out of place here. It is possible that
that request was sent by Chrome after (or during) Chrome error page
generation and, hence, should be ignored during this analysis. To make
sure you look at requests on one TCP connection, log the source TCP port
number of the client connection to Squid (%>p).
That URI is Chrome testing for Internet access.
Line corresponding to blocked Firefox
1512493386.314 43 192.168.1.121 TCP_DENIED/200 0 CONNECT es-la.facebook.com:443 user@xxxxxxxxxx HIER_NONE/- -
1512493386.317 0 192.168.1.121 TAG_NONE/403 6569 GET https://es-la.facebook.com/ user@xxxxxxxxxx HIER_NONE/- text/html
This group looks OK to me: The CONNECT request was denied (without
letting the browser know). The following GET request (presumably on the
same TCP connection) was bumped to serve the denial error page to the
browser.
1512493386.397 45 192.168.1.121 TCP_DENIED/200 0 CONNECT es-la.facebook.com:443 user@xxxxxxxxxx HIER_NONE/- -
1512493386.400 0 192.168.1.121 TAG_NONE/403 6561 GET http://squid.DOMAIN.lan:3128/squid-internal-static/icons/SN.png
user@xxxxxxxxxx HIER_NONE/- text/html
Something went wrong here. The denied GET request is (logged as) a plain
HTTP request (no "https://";). Perhaps it is unrelated to the denied
CONNECT attempt, but then why did that GET get a 403 response? The above
%>p logging suggestion applies here as well.
It is the icon on a Squid error page. I doubt it has anything to do with
the second CONNECT line directly above it, but is probably the result of
the 403 being delivered by Squid two lines previously.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
