EDIT (7/7/2016) - voir ajout à la fin du post
J'ai suivi attentivement les problèmes liés à la dépréciation de Microsoft concernant l'utilisation des certificats de signature de code SHA1 pour les exécutables Windows ( http://social.technet.Microsoft.com/wiki/contents/articles/32288.windows- application-de-code-authentique-signature-et-horodatage.aspx ).
Nous sommes maintenant en 2016, et comme nous devrons signer et publier du code sous peu, j'essaie de vérifier qu'en effet, sans mettre à niveau notre certificat de signature de code vers un SHA256, nous aurons des problèmes. Cependant, je semble incapable de démontrer les problèmes attendus.
J'ai signé certains exécutables (aujourd'hui, en 2016) en utilisant le certificat SHA1 et configuré AppLocker pour exécuter uniquement les exécutables signés (j'ai vérifié cela - je ne peux pas exécuter les exécutables non signés). Cependant, je suis toujours en mesure d'exécuter librement mes exécutables nouvellement signés SHA1, et en outre, le téléchargement de ces fichiers à partir d'un serveur Web en IE ne me présente aucun 'avertissement' (comme je l'avais fait attendu) - l'analyse de sécurité indique que tout va bien avec les fichiers!
J'exécute les tests sur Windows 7.
Quels problèmes réels dois-je s'attendre à rencontrer?
(au cas où vous vous demandez pourquoi nous ne nous contentons pas simplement de mettre à niveau vers SHA256 de toute façon - il y a plusieurs raisons: l'une est bureaucratique, mais l'autre est le fait que nous signons également des scripts VBS qui ne prennent actuellement pas en charge la double signature).
EDIT (7/7/2016) Eh bien, il semble que Microsoft a enfin mis à jour une mise à jour vers IE et Edge qui vous avertit si vous téléchargez un exécutable signé uniquement avec un certificat SHA-1! Fondamentalement, avec IE 11.0.30 ou version ultérieure, si vous téléchargez un exécutable signé avec un certificat SHA-1 (mais pas SHA-256) APRÈS le 01/01/2016, vous verrez l'un des avertissements suivants:
Je suppose que Microsoft accepte enfin les avertissements en préparation de la date butoir du 1/1/2017. Il est important de noter que pour le moment, en dehors de ces avertissements, il n'y a pas d'autres changements - les fichiers s'exécutent toujours sans problème, et bien sûr, leur téléchargement dans d'autres navigateurs ne pose pas de problème.
J'ai maintenant trouvé un exemple d'un téléchargement réel qui a été signé à l'aide d'un certificat SHA-1 après le 1/1/2016. J'ai téléchargé KeePass 2.31 en utilisant Edge sur Windows 10.
Edge me dit que "la signature de ce fichier est corrompue ou invalide."
Si je clique avec le bouton droit et sélectionne "exécuter quand même", ou double-clique sur le fichier dans l'Explorateur Windows, SmartScreen bloque le fichier:
Cochez la case et cliquez sur Exécuter quand même pour que le fichier s'exécute normalement. L'avertissement UAC affiche alors le nom de l'éditeur comme il le fait avec un exécutable correctement signé.
Cliquer sur "Exécuter quand même" lorsque SmartScreen bloque le fichier supprime la "Marque du Web" du fichier. Un double-clic sur le fichier une deuxième fois dans l'Explorateur Windows ne bloque plus le fichier.
La boîte de dialogue Détails de la signature numérique dans l'Explorateur Windows indique également que la signature est OK. Il le fait même lorsque le fichier a toujours la "marque du Web" (c'est-à-dire avant d'utiliser le bouton Exécuter quand même dans le filtre SmartScreen):
Le fichier a en fait deux signatures. Le premier utilise SHA-1 pour la signature et le second utilise SHA-256 pour la signature. Mais de manière critique, les deux ont été créés à l'aide d'un certificat SHA-1. C'est ce que Windows 7 et les versions ultérieures trouvent à redire aux fichiers téléchargés. En outre, les deux signatures sont horodatées avec SHA-1. Windows 10 aura un problème avec cela pour les fichiers téléchargés à partir du 1/1/2017.
Il semble que la boîte de dialogue Détails des signatures numériques ne tienne pas compte du fait qu'un fichier porte la "marque du Web". Il indique "cette signature numérique est OK" pour les deux signatures de ce fichier. Donc, pour vraiment tester si vos fichiers sont correctement signés, vous devez les télécharger depuis votre site Web comme le feraient vos clients.
Le test du même téléchargement dans un instantané de machine virtuelle de Windows 10 d'origine qui n'a pas été mis à jour depuis août et un autre instantané de la version 1511 qui n'a pas été mis à jour depuis novembre ne génère aucun avertissement. Si j'ai ensuite le 1511 VM vérifier et installer les mises à jour jusqu'à ce qu'il dise qu'il est à jour, alors je reçois les avertissements ci-dessus. J'ai noté dans ma réponse précédente que le SHA-1 la dépréciation est repoussée via Windows Update. Il semble donc que ce soit une mise à jour très récente, peut-être une mise à jour post-1/1/16. Assurez-vous que votre PC dispose de toutes les dernières mises à jour de sécurité avant tester votre téléchargement.
Il s'agit davantage d'une entrée de commentaire/recherche de faits étendue. Pas une réponse à part entière en soi.
Je ne comprends pas non plus. C'est assez déroutant. Mais je ne me sens pas si mal de ne pas comprendre cela, car Eric Lawrence est confus par cela aussi. Il était auparavant un développeur d'Internet Explorer, mais travaille maintenant sur Google Chrome. Et il connaît bien les certificats. (Donc, s'il ne l'obtient pas, je suis enclin à dire que c'est vraiment IS confus.) (Et il est également sur StackExchange .)
Voir ses commentaires ici:
https://blogs.windows.com/msedgedev/2015/11/04/sha-1-deprecation-update/ (Archivé ici .)
A noter également: ce bijou ici:
Eric Lawrence
La base de connaissances que vous liez indique qu'il n'est pas prévu de déprécier les signatures Authenticode basées sur MD5 (le hachage du code, pas le certificat). Cela semble… irresponsable.
Effrayant. Malheureusement, Microsoft n'a pas répondu à ce commentaire.
Et il a laissé un autre commentaire sur le site Wiki TechNet: http://social.technet.Microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-authenticode-code-signing-and -timestamping.aspx (Archivé ici .)
EricLaw [ex-MSFT] 4 novembre 2015 9h23
Ce texte est assez déroutant: "Hash de fichiers de signature de code: Microsoft n'exige pas que les autorités de certification passent à l'utilisation de SHA-2. Windows n'appliquera pas non plus les stratégies sur ces certificats. Si des attaques pré-image sur SHA1 deviennent possibles, nous réévaluerons la façon dont le système approuve ces certificats. "Le hachage du fichier Authenticode n'est pas généré par une autorité de certification et la signature n'est pas un "certificat".
Et encore: Aucune réponse de Microsoft à cela. Et ce n'est pas le seul commentaire exprimant de la confusion.
Jouer avec l'horloge système? Si vous souhaitez reproduire l'échec, vous pouvez essayer les étapes "Graham Bloice" listes sur le TechNet Post :
Lors des tests, nous avons constaté que les fichiers cab signés SHA1 existants utilisés pour installer un composant ActiveX via IE échouent à installer immédiatement après la date de dépréciation (en ajustant la date dans le registre), même si le L'horodatage de la signature de la cabine est antérieur à la date de dépréciation (déplacée). Win 10 n'échoue pas, mais Win 7, Win 8.1, Server 2K12 et Server 2K12 R2 échouent tous dans nos tests.
Cela semble en contradiction avec l'avis de dépréciation qui dit que les signatures horodatées avant la date de dépréciation seront valables jusqu'en 2020.
Encore une fois: aucune réponse de Microsoft à cela.
Article de blog détaillé sur AuthentiCode: 2014-09-04, Eric Lawrence, MSDN Blogs, Mises en garde pour la signature de code Authenticode
2015-12-28, @EricLaw, https://Twitter.com/ericlaw/status/68148757822312448189
Question connexe: 2012-09-20, Signature de code avec MD5 sous Windows 8
Didier Stevens, 29/12/2015, Signature du code SHA256 et Microsoft (Archivé ici .)
Cela clarifie considérablement la situation:
Tout d'abord, la perte de confiance ne se produira pas pour tous les exécutables avec une signature sha-1. Cela ne se produira qu'avec des exécutables avec un attribut "Marque du Web" et sans horodatage ou horodatage après le 1/1/2016.
Il y a 3 résumés dans une signature Authenticode horodatée sur laquelle vous avez le contrôle.
Le résumé de votre certificat. Un certificat récemment acheté utilisera SHA-256. La plupart des autorités de certification sont passées à l'émission de certificats SHA-256 en 2014. Elles ne fournissent des certificats SHA-1 que sur demande spéciale. Un moyen rapide de vérifier votre certificat consiste à cliquer avec le bouton droit sur un .exe que vous avez signé avec lui dans l'Explorateur, puis à accéder à l'onglet Signatures numériques, bouton Détails, bouton Afficher le certificat, onglet Détails. L'algorithme de signature doit être "sha256". Windows XP SP3 est la plus ancienne version de Windows qui prend en charge les certificats SHA-256. La politique indiquée sur le document que vous avez lié est "Windows [7 et versions ultérieures] fait confiance à SHA1 (si horodaté avant le 1/1/2016) et SHA-2 (tout horodatage) pour la marque des fichiers Web. "
Le résumé de la signature elle-même. Vous pouvez vérifier les signatures existantes sur l'onglet Signatures numériques. Windows 7 et versions ultérieures affichent directement l'algorithme de résumé. Sur n'importe quelle version de Windows, vous pouvez cliquer sur le bouton Détails, onglet Avancé pour vérifier l'algorithme de résumé. Lorsque vous utilisez signtool.exe, cela peut être défini sur SHA-256 avec le /fd sha256
argument. Windows 7 est la version la plus ancienne de Windows qui prend en charge les signatures SHA-256. Pour cela, la politique déclarée est "Aucun changement jusqu'à ce que la pré-image SHA-1 soit possible". Même les signatures MD5 sont toujours acceptées .
Le résumé de l'horodatage. Lorsque vous utilisez signtool.exe, vous devez utiliser le /tr
argument avec l'URL d'un service d'horodatage RFC 3161 et /td sha256
pour demander SHA-256. Windows 7 est la version la plus ancienne de Windows qui prend en charge les horodatages SHA-256. Pour cela, la politique indiquée est "Sur Win 10 et supérieur, bloqué le 1/1/2017 pour Mark of the Web files".
Le résumé est que si vous obtenez un certificat SHA-256, une seule signature SHA-1 utilisant ce certificat avec un horodatage SHA-1 est actuellement acceptée par Windows XP SP3 via Windows 10. Sur 1/1/2017, vous aurez besoin de deux signatures si vous souhaitez prendre en charge Windows 10 ainsi que Vista ou XP SP3.
La stratégie d'amortissement est appliquée à Windows 7 et versions ultérieures via la mise à jour Windows. Si les mises à jour sont désactivées, l'amortissement ne se produira pas. Ce que vous devez savoir, c'est que Windows 7 traite une signature avec un certificat SHA-1 comme non valide, ce qui devrait entraîner des avertissements plus sévères lors de l'exécution d'un fichier téléchargé à partir d'Internet.
Juste quelques informations supplémentaires de ma part, car j'ai rencontré un problème avec tout cela aujourd'hui, cela m'a coûté une demi-journée.
J'ai obtenu le message "La signature de ce fichier est corrompue ou invalide." d'Edge également. Windows m'a dit que mon fichier (qui était déjà signé avec SHA256) n'est pas sécurisé et n'a pas réussi à me montrer les informations de certificat correctes (uniquement "Publisher inconnu").
Nous utilisons des certificats de signature de code StartSSL et sommes passés à un nouveau certificat SHA256 en décembre. Ce que nous n'avons pas remarqué, c'est que signtool inclut également tous les certificats intermédiaires (!) Pendant le processus de signature. Il s'avère: il utilise la version localement mise en cache des certificats intermédiaires, qui étaient obsolètes (toujours en utilisant SHA1), bien que de nouveaux soient disponibles. Après avoir supprimé et mis à jour ce certificat, tout a fonctionné comme prévu.
Donc, assurez-vous de vérifier si chaque certificat de la chaîne est également SHA256, ou tout se cassera - car les intermédiaires sont inclus pendant le processus de signature!
Je viens de vivre le même problème avec nos applications Windows. Voici donc quelques informations pour vous:
A) Comme vous l'avez souligné SHA-1
le hachage est éliminé en raison de sa résistance aux collisions inadéquate . Ou, en d'autres termes, il ne produit pas de signatures de code qui sont suffisamment fortes par rapport aux normes cryptographiques actuelles.
B) Pour signer le code de votre exécutable, vous devez disposer d'un certificat de signature de code qui prend en charge SHA-2
algorithmes de hachage, tels que SHA-256
. (Dans mon cas, le CA , Comodo, a mis à jour gratuitement notre certificat de signature de code existant. Vous devrez cependant demander à votre autorité de certification.)
C) Téléchargez et installez la dernière Windows SDK . Ensuite, vous pouvez accéder à signtool.exe
dans l'un de ces deux emplacements:
For 32-bit:
%SystemDrive%\Program Files (x86)\Windows Kits\10\bin\x86
For 64-bit:
%SystemDrive%\Program Files (x86)\Windows Kits\10\bin\x64
D) Le tableau suivant indique le support de l'OS SHA-1
et SHA-256
signatures de code:
+---------------------+-------------------------------+------------------------------+
| Windows OS | SHA-1 | SHA-256 |
+---------------------+-------------------------------+------------------------------+
| XP SP3, Server 2003 | Yes | No (need KB968730, KB938397) |
| Vista, Server 2008 | Yes | No (need KB2763674) |
| 7, Server 2008 R2 | No (if signed after 1/1/2016) | Yes (with latest updates) |
| 8.1, Server 2012 R2 | No (if signed after 1/1/2016) | Yes |
| 10, Server 2016 | No (if signed after 1/1/2016) | Yes |
+---------------------+-------------------------------+------------------------------+
Une note importante pour les utilisateurs de Vista est qu'ils doivent installer KB2763674 pour pouvoir ouvrir des fichiers signés avec SHA-256
Signature.
E) La solution pour corriger les écarts dans le tableau ci-dessus consiste donc à double signer vos exécutables. À ma connaissance, les fichiers suivants prennent en charge la double signature:
.cpl, .com, .dll, .exe, .scr
Donc, pour coder, signez un fichier appelez signtool
deux fois comme tel:
Première SHA-1
(comme solution de rechange pour les anciens systèmes d'exploitation):
SignTool.exe sign /f "path_to_exported_cert.pfx" /p "pfx_file_password" /d "Your file description if you need it" /t "http://timestamp.verisign.com/scripts/timstamp.dll" /v "path_to_file_to_sign.exe"
puis SHA-256
sur le même fichier pour l'ajouter (/as
paramètre):
SignTool.exe sign /f "path_to_exported_cert.pfx" /fd sha256 /p "pfx_file_password" /d "Your file description if you need it" /tr "http://timestamp.geotrust.com/tsa" /td sha256 /as /v "path_to_file_to_sign.exe"
Notez que les paramètres à signer avec SHA-256
sont différents, surtout pour le serveur d'horodatage! Utilisation du serveur d'horodatage pour SHA-1
produit des résultats étranges dans Windows 10.
F) Pour tout autre fichier, y compris: .msi
, .msp
, .js
, .vbs
, .jse
, .vbe
, .ps1
, .ps1xm
, .psm1
, .ps1xml
, .wsf
vous devrez choisir l'un ou l'autre, car ils ne prennent pas en charge la double signature. Nous devrons donc malheureusement les signer spécifiquement pour le système d'exploitation sur lequel ils sont destinés à être déployés.
J'ai utilisé osslsigncode (un outil Linux) pour signer deux fois l'installateur exe avec SHA1 et SHA256. Pour les utilisateurs de Windows, j'ai lu un Windows fork de osslsigncode. Mon certificat de signature comodo actuel 2016 est livré avec SHA1 et SHA256 à double digestion, je n'ai donc besoin que d'un seul certificat pour les deux signatures.
Vous devez d'abord utiliser la signature compatible XP:
osslsigncode sign -pkcs12 comodo-signing-2016.p12 -askpass \
-n "My-program installer" \
-i http://www.my-site.com/my-program \
-t http://timestamp.comodoca.com \
-h sha1 \
my-installer.exe my-installer-signed.exe
Puis celui compatible Win7/8/10:
osslsigncode sign -pkcs12 comodo-signing-2016.p12 -askpass \
-n "My-program installer" \
-i http://www.my-site.com/my-program \
-ts http://timestamp.comodoca.com \
-nest -h sha256 \
my-installer-signed.exe my-installer-dual-signed.exe
Notez que j'utilise l'horodatage Authenticode ( - t ) pour la première signature et l'horodatage RFC 3161 ( - ts ) pour le second. Je ne sais pas à quel point cela est utile, mais Authenticode est plus ancien et probablement plus rétrocompatible. Le résumé de l'horodatage Authenticode est sha1 par défaut et le RFC 3161 est automatiquement défini sur sha256 comme mentionné ici .
Notez également que la deuxième commande inclut le drapeau - nest afin d'ajouter la nouvelle signature au lieu de remplacer la première.
Il semble que Microsoft ait considérablement modifié sa politique de dépréciation de SHA-1 pour la signature de code, à compter du 19 octobre 2016, à 11 h 15. Avant cette date, ils ont déclaré que SHA-1 allait être déconseillé pour la signature de code ( 11:14 ); après cette heure, ils disent que la signature de code SHA-1 n'est pas affectée pour l'instant, sans date d'arrêt spécifiée pour l'avenir ( 11:16 ).
Voici les détails en date du 25 février 2017 ( lien vers la version actuelle ):
TLS Server-Authentication Certificates
Today: No lock icon Microsoft Edge and Internet Explorer 11
Mid-2017: Invalid Certificate
Code Signing Certificates
Today: Unaffected
Mid-2017: Unaffected
Timestamping Certificates
Today: Unaffected
Mid-2017: Unaffected
À long terme, bien sûr, SHA-1 est un risque; cette question concerne cependant la dépréciation des certificats de signature de code sous Windows, et le changement de Microsoft en octobre 2016 est significatif par rapport aux plans précédemment publiés. Ils disent actuellement "À long terme, Microsoft a l'intention de se méfier de SHA-1 dans Windows dans tous les contextes", et le plan pour cela est en "Phase 3", "après 2017".
Bien que votre certificat ne renvoie aucun signe d'avertissement sur les plates-formes et les navigateurs plus anciens, vous verrez des signes d'avertissement sur tous les systèmes mis à niveau. Le meilleur exemple à vous donner est Windows 10. Windows 10 affichera un avertissement pour tout certificat de signature de code qui IS PAS un certificat EV-SHA-256.
Si la plate-forme a été mise à jour selon les nouvelles recommandations des directives du forum CA/B, votre certificat n'éliminera pas les signes d'avertissement.
Si vous souhaitez parler à quelqu'un plus en détail, faites-le moi savoir et je vous mettrai en contact avec quelqu'un de GlobalSign qui pourra vous délivrer un nouveau certificat ou tout simplement vous parler plus en détail de la compatibilité. Sinon, cet article peut en effet aider: https://support.globalsign.com/customer/en/portal/articles/1499561-sha-256-compatibility
Pas en tant que réponse complète, mais pour des informations de présentation supplémentaires, y compris des exemples de lignes de signature pour la double signature (compatibilité XP/Vista)
J'ai réussi à passer gentiment à la double signature dans ma chaîne de construction selon ce très bon article de blog de ksoftware.net , notre fournisseur de certificats.
J'ai écrit un petit fichier batch pour signer deux fois un fichier avec les deux certificats et l'appeler depuis mon script de déploiement:
set SIGNTOOL_CMD=F:\FuH\dev\Docklight1\Installer\signtool\signtool.exe
set DL_WWW=http://docklight.de
set DL_PROJ_NAME=Docklight
set TIMESERVER_SHA1=http://timestamp.comodoca.com
set TIMESERVER_SHA256=http://timestamp.comodoca.com/?td=sha256
"%SIGNTOOL_CMD%" sign /v /sha1 D35C... /t %TIMESERVER_SHA1% /du %DL_WWW% /d "%DL_PROJ_NAME%" "%1"
"%SIGNTOOL_CMD%" sign /v /sha1 7FD7... /as /fd sha256 /tr %TIMESERVER_SHA256% /td sha256 /du %DL_WWW% /d "%DL_PROJ_NAME%" "%1"
Au lieu de télécharger le SDK Windows complet pour un signtool mis à jour, je viens de saisir le lien de téléchargement signtool du blog KSoftware
J'ai testé cela sur Windows 10 x64/Edge et tout semble bon.