[squid-dev] [PATCH] sslproxy_cert_sign_hash configuration option

[Tsantilas Christos]

On 10/06/2014 07:26 PM, Amos Jeffries wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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 [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...
>>
> I know. What problem was there mimicing the hash?

Currently we are not mimicing signing hash. If we do it, we  may found 
problems. It is something which is not tested.
If in the future we need to mimic signing algorithm, we can implement it.

This is not the only reason.

Certificates mimicking is able only on bump-server-first mode.
It is not possible on bump-client-first, and in cases an error page is 
generated because bumping failed, or because we found wrong certificates.
But in these cases too we need to generate certificates...

The sha256 will be the default with this patch, but if in the future the 
sha256 found insecure, the system admin will be able to fix it using 
this cfg parameter.

>
>> 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  ...
>
> Hmm. yes.
>   Would it be easy to check for minimum values to prevent the below
> examples?

Not in all cases, or not so easy.
The client TLS version is known on Peek-and-splice mode or in 
bump-client-first, but not in bump-server-first mode.

Regards,
    Christos

>
>>
>>>
>>> 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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
>
> iQEcBAEBAgAGBQJUMsK5AAoJELJo5wb/XPRjNB8H/0yYcp24LQbxeyNjHJLvfYYD
> LU4H+fxqqmOldpG82E9EJRyhhITZtsuYkQ9ipWLquZXwkvrtwki2jSI0A90Frq1F
> aGEKCGjAyAhFQ69BuFD4V5dJIDZyGJLpdpPm5QrgRPzbFJ8F49mZ/FB7rVu2yTYr
> Mh4fAA+ddnuXg9Fkj6ImJU64aYkNYWlR0StlC9c/y40Ikw43H3Ux4pHUtL4jMwYN
> ygxH5b1gYkhCRJCkYQhqlPpHVoyF+8cmFPe/54OlJU79UnjFvfDTivkAWHddDs05
> SzIOvsQWZLVZc3jzhDK3DNvC8dclsaDyuf8+9plfiH/33itLEQiX6GmCwTNcpIA=
> =bzuy
> -----END PGP SIGNATURE-----
> _______________________________________________
> squid-dev mailing list
> squid-dev at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>