[squid-dev] [PATCH] sslproxy_cert_sign_hash configuration option
Tsantilas Christos
chtsanti at users.sourceforge.net
Mon Oct 6 14:50:45 UTC 2014
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
>> [1],[2],[4]. Microsoft will block certificates with SHA-1 after
>> 1.1.2017 [3].
>>
>
> 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...
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 1.2+
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 ...
>
> 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.
>
> Amos
More information about the squid-dev
mailing list