[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:
> 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