[squid-users] ssl bump and chrome 58

Thu Apr 27 17:25:37 UTC 2017

3.5 and above have "server-first" only for backward compatibility.

27.04.2017 22:50, William Lima пишет:
> Hi,
>
> The problem occurs due to some ssl_bump directive actions, so Squid cannot get all information (X.509 v3 extensions) to mimic. "ssl_bump server-first all" should work.
>
> William Lima
>
> ----- Original Message -----
> From: "Flashdown" <flashdown at data-core.org>
> To: "Yuri Voinov" <yvoinov at gmail.com>
> Cc: squid-users at lists.squid-cache.org
> Sent: Thursday, April 27, 2017 1:41:48 PM
> Subject: Re: [squid-users] ssl bump and chrome 58
>
> I've tested the registry setting and it worked out. You can copy the 
> below lines in a .reg file and execute it.
>
> Windows Registry Editor Version 5.00
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
> "EnableCommonNameFallbackForLocalAnchors"=dword:00000001
>
>
> Best regards,
> Flashdown
>
> Am 2017-04-27 18:34, schrieb Flashdown:
>> Hello together,
>>
>> here is a workaround that you could use in the meanwhile.
>>
>> https://www.chromium.org/administrators/policy-list-3#EnableCommonNameFallbackForLocalAnchors
>>
>> Source:
>> https://www.chromium.org/administrators/policy-list-3#EnableCommonNameFallbackForLocalAnchors
>>>>>>> BEGIN
>> EnableCommonNameFallbackForLocalAnchors
>> Whether to allow certificates issued by local trust anchors that are
>> missing the subjectAlternativeName extension
>>
>> Data type:
>>     Boolean [Windows:REG_DWORD]
>> Windows registry location:
>>     
>> Software\Policies\Google\Chrome\EnableCommonNameFallbackForLocalAnchors
>> Mac/Linux preference name:
>>     EnableCommonNameFallbackForLocalAnchors
>> Android restriction name:
>>     EnableCommonNameFallbackForLocalAnchors
>> Supported on:
>>
>>         Google Chrome (Linux, Mac, Windows) since version 58 until 
>> version 65
>>         Google Chrome OS (Google Chrome OS) since version 58 until 
>> version 65
>>         Google Chrome (Android) since version 58 until version 65
>>
>> Supported features:
>>     Dynamic Policy Refresh: Yes, Per Profile: No
>> Description:
>>
>>     When this setting is enabled, Google Chrome will use the
>> commonName of a server certificate to match a hostname if the
>> certificate is missing a subjectAlternativeName extension, as long as
>> it successfully validates and chains to a locally-installed CA
>> certificates.
>>
>>     Note that this is not recommended, as this may allow bypassing the
>> nameConstraints extension that restricts the hostnames that a given
>> certificate can be authorized for.
>>
>>     If this policy is not set, or is set to false, server certificates
>> that lack a subjectAlternativeName extension containing either a DNS
>> name or IP address will not be trusted.
>> Example value:
>>     0x00000000 (Windows), false (Linux), false (Android), <false /> 
>> (Mac)
>> <<<<<<<<<<<< END
>>
>>
>>
>> Am 2017-04-27 18:16, schrieb Flashdown:
>>> Hello together,
>>>
>>> Suddenly I am facing the same issue when users Chrome has been updated
>>> to V58. I am running Squid 3.5.23.
>>>
>>> This is the reason:
>>> https://www.thesslstore.com/blog/security-changes-in-chrome-58/
>>> Short: Common Name Support Removed in Chrome 58 and Squid does not
>>> create certs with DNS-Alternatives names in it. Because of that it
>>> fails.
>>>
>>> Chrome says:
>>> 1. Subject Alternative Name Missing - The certificate for this site
>>> does not contain a Subject Alternative Name extension containing a
>>> domain name or IP address.
>>> 2. Certificate Error - There are issues with the site's certificate
>>> chain (net::ERR_CERT_COMMON_NAME_INVALID).
>>>
>>> Can we get Squid to add the DNS-Alternative Name to the generated
>>> certs? Since this is what I believe is now required in Chrome 58+
>>>
>>> Best regards,
>>> Enrico
>>>
>>>
>>> Am 2017-04-21 15:35, schrieb Yuri Voinov:
>>>> I see no problem with it on all five SSL Bump-aware servers with new
>>>> Chrome. So fare so good.
>>>>
>>>>
>>>> 21.04.2017 18:29, Marko Cupać пишет:
>>>>> Hi,
>>>>>
>>>>> I have squid setup with ssl bump which worked fine, but since I 
>>>>> updated
>>>>> chrome to 58 it won't display any https sites, throwing
>>>>> NTT:ERR_CERT_COMMON_NAME_INVALID. https sites still work in previous
>>>>> chrome version, as well as in IE.
>>>>>
>>>>> Anything I can do in squid config to get ssl-bumped sites in chrome
>>>>> again?
>>>>>
>>>>> Thank you in advance,
>>>> _______________________________________________
>>>> squid-users mailing list
>>>> squid-users at lists.squid-cache.org
>>>> http://lists.squid-cache.org/listinfo/squid-users
>>> _______________________________________________
>>> squid-users mailing list
>>> squid-users at lists.squid-cache.org
>>> http://lists.squid-cache.org/listinfo/squid-users
>> _______________________________________________
>> squid-users mailing list
>> squid-users at lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-- 
Bugs to the Future
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x613DEC46.asc
Type: application/pgp-keys
Size: 2437 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20170427/6560be29/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20170427/6560be29/attachment.sig>