[squid-users] net::err_cert_common_name_invalid just in squid page with dstdomain block

[Amos Jeffries]

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 at DOMAIN.LAN HIER_NONE/- -
>> 1512493257.716    169 192.168.1.121 TCP_MISS/204 193 GET http://www.gstatic.com/generate_204 user at DOMAIN.LAN 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 at DOMAIN.LAN HIER_NONE/- -
>> 1512493386.317      0 192.168.1.121 TAG_NONE/403 6569 GET https://es-la.facebook.com/ user at DOMAIN.LAN 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 at DOMAIN.LAN 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 at DOMAIN.LAN 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