www.cendio.com
Bug 5879 - Windows will soon deprecate SHA-1 for code signing
: Windows will soon deprecate SHA-1 for code signing
Status: CLOSED FIXED
: ThinLinc
Client platforms
: pre-1.0
: PC Unknown
: P2 Normal
: 4.8.0
Assigned To:
:
:
: 5360 5597
:
  Show dependency treegraph
 
Reported: 2016-05-10 18:02 by
Modified: 2017-03-23 10:26 (History)
Acceptance Criteria:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From cendio 2016-05-10 18:02:39
See here:

http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-authenticode-code-signing-and-timestamping.aspx

In short, from Feb 14, 2017 we need to sign our Windows binaries using SHA-2
rather than SHA-1.

Note that at least Windows 7/Server 2008R2 is required to support SHA-2
signature. So older platforms will be an issue and we need to either drop
support for them, or do some special handling.
------- Comment #1 From cendio 2016-05-17 10:18:18 -------
The product council will keep track of this bug and make sure we take action
before the deadline.
------- Comment #2 From cendio 2016-12-12 09:59:18 -------
Quoting from bug 5620:

> Fixed in 30705. Note that the new certicate is SHA-256 rather than SHA-1.

No mention on the bug of this being reverted for a SHA-1 certificate either.
What's going on here?
------- Comment #3 From cendio 2016-12-12 12:33:30 -------
(In reply to comment #2)

> No mention on the bug of this being reverted for a SHA-1 certificate either.
> What's going on here?

We have some additional information om Issue17128. I think the idea was this:

"The signature must be made using SHA-1 as the digest algorithm, but it is OK
if parts of the certificate's chain of trust use SHA-2. This might also apply
to digest algorithm used by the timestamp."

This is taken from  http://www.davidegrayson.com/signing/, which is very good.
------- Comment #4 From cendio 2016-12-13 16:34:02 -------
(In reply to comment #0)
> 
> Note that at least Windows 7/Server 2008R2 is required to support SHA-2
> signature. So older platforms will be an issue and we need to either drop
> support for them, or do some special handling.
>
Security update KB3033929 is required to support SHA-2 on Windows 7 / 2008R2
------- Comment #5 From cendio 2016-12-13 16:40:30 -------
(In reply to comment #4)
> (In reply to comment #0)
> > 
> > Note that at least Windows 7/Server 2008R2 is required to support SHA-2
> > signature. So older platforms will be an issue and we need to either drop
> > support for them, or do some special handling.
> >
> Security update KB3033929 is required to support SHA-2 on Windows 7 / 2008R2

No, according to http://www.davidegrayson.com/signing/, this is only necessary
for kernel modules, which we do not have.
------- Comment #6 From cendio 2016-12-14 07:38:59 -------
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #0)
> > > 
> > > Note that at least Windows 7/Server 2008R2 is required to support SHA-2
> > > signature. So older platforms will be an issue and we need to either drop
> > > support for them, or do some special handling.
> > >
> > Security update KB3033929 is required to support SHA-2 on Windows 7 / 2008R2
> 
> No, according to http://www.davidegrayson.com/signing/, this is only necessary
> for kernel modules, which we do not have.

That's correct, I mixed up the kb numbers, I ment  to say KB2949927 which adds
support for SHA-2 sign and verify to windows 7 / 2008R2 and is not mentioned at
http://www.davidegrayson.com/signing/
------- Comment #7 From cendio 2016-12-22 10:21:39 -------
Plenty of confusion from my part here. There are very few authorative
sources for information about these subjects online, but I think I
have it figured out with help from Henrik.

First - I mistakenly identified our existing code signing certificate
(pki/Cendio-AB.pem) as a SHA-1 certificate. In fact, it's using SHA-2
(sha256WithRSAEncryption in OpenSSL-speak). My mistake - I must have
mixed it up with something else along the way.

We can generate signatures with SHA-256 digests by modifying how we
call osslsigncode - just add "-h sha256" to the command line.

At the same time, we also want to have our signed timestamps use
SHA-256 digests, so we need to instruct our timestamping service to
use SHA-256. While signtool.exe has a command line parameter to
control this, osslsigncode does not, so we need a service that
defaults to SHA-256. The GoDaddy-recommended tsa.starfieldtech.com can
only produce signatures with SHA-1 digests with osslsigncode, so I've
settled for a GlobalSign timestamping service instead.
------- Comment #8 From cendio 2016-12-22 10:27:57 -------
With regards to Windows platforms - Windows 7 with updates can handle
SHA-256 signatures. There's a general (informal) agreement that this
is a reasonable requirement and that we don't need to note this in our
documentation.
------- Comment #10 From cendio 2016-12-22 10:59:29 -------
The changes in r31994 result in the following behavior for the client
installer:

| Windows | Verified publisher? |
|---------+---------------------|
| Vista   | No                  |
|---------+---------------------|
| 7¹      | Yes                 |
| 10      | Yes                 |
|---------+---------------------|

¹: with updates applied


I've also verified an installer with signtool from the Windows SDK:

 signtool /v /tw /pa <file>

(/tw to warn if the signature isn't timestamped, /pa to use the authenticode
verification rather than windows driver verification.)
------- Comment #11 From cendio 2016-12-27 15:55:55 -------
Looks good. Verified that the new SHA256 signature works with build 5330 on
Windows 10 and Windows 7. Verified that it isn't recognized on Windows Vista.