[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