[squid-dev] [PATCH] sslproxy_cert_sign_hash configuration option
squid3 at treenet.co.nz
Mon Oct 6 16:26:33 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
On 7/10/2014 3:50 a.m., Tsantilas Christos wrote:
> On 10/06/2014 10:13 AM, Amos Jeffries wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> On 2/10/2014 5:48 a.m., Tsantilas Christos wrote:
>>> Browser vendors will get rid of SSL certificates that use SHA-1
>>> to generate the hash that is then signed by the CA. For
>>> example, Google Chrome will start to show an "insecure" sign
>>> for certificates that are valid after 1.1.2016 and will
>>> generate a warning page for certificates that are valid after
>>> 1.1.2017 ,,. Microsoft will block certificates with
>>> SHA-1 after 1.1.2017 .
>> IMHO this directive should not be necessary.
>> 1) when mimicing certs server provides the hash type.
> We have found problems when trying to mimic everything...
I know. What problem was there mimicing the hash?
> For mimicking hash type, probably we need to support ACLs:
> sslproxy_cert_sign_hash_mimic allow acl1 acl2 But this is a
> different project. We do not cover this cases in this patch...
>> 2) cleanly generated certs should always be using a secure hash
>> in compliance with TLS specification. The TLS/SSL maximum version
>> supplied by the client also drives the hashes the server is able
>> to use: - MD5 for SSL, - SHA1 for TLS 1.0/1.1, - SHA256 for TLS
> The web servers does not provide a different Certificates signing
> hashing algorithm depending on client TLS version supported....
> Also the user may wants to use SHA384 ...
Would it be easy to check for minimum values to prevent the below
>> Allowing configuration of the hash seems to be unnecessary, and
>> adds potential for configuring impossible situations like SSL
>> without MD5, or more likely SHA-256 with TLS/1.0.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
-----END PGP SIGNATURE-----
More information about the squid-dev