Evolutions de la gestion des certificats SSL en 2017 et 2018

Les certificats SSL restent indispensables pour protéger les données confidentielles de nos clients. Il est donc essentiel de s'informer et de faire évoluer notre gestion des certificats, notamment dans nos navigateurs. L'année 2017 a été marquée dans le domaine des certificats SSL par les restrictions d'usages de l'algorithme SHA1 en début 2017. Mais elle ne s’est pas arrêtée sur cet évènement, car depuis septembre, les Certificate Authorities (CA) doivent aussi supporter le Certificate Authority Authorization (CAA). En 2018, d'autres évolutions sont attendues, telles que la limitation de durée de validité des certificats fournis par les CAs publiques ou le Certificat Transparency (CT) requis par Google Chrome.

Dépréciation du SHA1, c’est fini ?

La course au SHA256 anime la gestion de nos certificats depuis plusieurs années. L’année 2017 a marqué de gros changements pour la dépréciation de l’algorithme SHA-1 avec le retrait du support des navigateurs web, entrainant les erreurs SSL : "Your connection to www.mysha1cert.com is encrypted with obsolete cryptography."

Les fournisseurs de vos certificats publics peuvent vous contacter afin de renouveler vos certificats pour un niveau de signature ou d’algorithme supporté, mais pensez toujours à les superviser vous-même pour éviter une dégradation ou perte d’accès de vos clients. Des outils en ligne sont là pour vous assister dans ces vérifications, les indicateurs de résultats vous donnent la marche à suivre pour rester dans les clous. https://www.ssllabs.com/ssltest/index.htmlhttps://www.tbs-internet.com/php/HTML/testssl.php

Le support du CAA, c’est acté !

Le Certification Authority Authorization est un enregistrement DNS utilisé pour spécifier quelles sont les CAs autorisées à délivrer un certificat pour un domaine donné. Cette fonctionnalité a pour but d’améliorer le contrôle au niveau des CAs, qui aujourd’hui, peuvent toutes délivrer des certificats pour l’ensemble des domaines sans restriction. Ce nouveau type d’enregistrement DNS est défini par la RFC 6844 : https://tools.ietf.org/html/rfc6844 L’administrateur d’un domaine pourra créer des enregistrements DNS CAA pour spécifier les CA autorisés pour ses domaines et sous-domaines, mais pourra également indiquer une adresse à notifier en cas de requête d’un certificat via une CA non autorisée. Cela se traduit en configuration DNS assez simplement, par exemple :

Définition des flags :

• Issue : autorise une CA à délivrer un certificat pour le nom de domaine
• Issuewild : autorise une CA à délivrer un certificat wildcard pour le nom de domaine
• Iodel : spécifie une URL sur laquelle une CA peut remonter des violations de règles

Bien que cette fonctionnalité soit officiellement prise en charge par les CAs publiques depuis le 8 septembre 2017, elle est encore peu utilisée. Il faut dans un premier temps qu’elle soit supportée par les logiciels DNS et les fournisseurs: Who Support CAA -> https://sslmate.com/caa/suppor... Nous trouverons par exemple un CAA actif sur Google. Vous pouvez tester le CAA d’un domaine via le lien suivant : https://caatest.co.uk À noter une limitation de ce mode de contrôle DNS, qui est exposé à des attaques DNS de type « spoofing » ou « cache poisoning ».

Certificate Transparency requis, ça arrive

Google Chrome annonce pour avril 2018 (initialement fin 2017) le Certificate Transparency requis. Ce qui devrait pousser les autres navigateurs dans ce sens. L’objectif du Certificate Transparency est de lutter contre la fraude de certificat et la compromission de CAs ou Sub-CAs. Le manque de visibilité sur la vérification de certificat est un point faible dans la sécurité, car cela accentue les délais de détection d’usurpation de certificat ou les délais de révocation permettant de le bloquer au niveau des navigateurs. La norme du Certificate Transparency va imposer la publication des informations (object, organisation, autorité de certification) de tous les certificats dans des bases de données publiques. La CA émettrice du certificat devra donc mettre automatiquement à jour sa publication dans ces bases de données. Cette norme suit la RFC6962 : https://tools.ietf.org/html/rfc6962 Trois nouvelles composantes vont être introduites avec le Certificate Transparency :

• Certificate Log

Le Certificate Log implique une étape supplémentaire lors de la génération d'un certificat pour une CA publique. La CA va envoyer un pre-certificat au serveur de log, qui lui répondra avec le "Signed Certificate Timestamp" ou "SCT", confirmant ainsi qu'un log sera créé pour approuver l'association CA émettrice et certificat du domaine. Les données collectées sur les serveurs de logs sont protégées par le mécanisme de cryptographie « Merkle Tree Hashes ». Ils sont publiquement accessibles pour un audit, afin que les vérifications soient faites quant à la légitimité du certificat.

• Certificate Monitors

Le monitoring sera fait par un client ou une CA pour vérifier la légitimité d’un certificat, ses extensions, ses permissions ou autres aspects suspects de celui-ci.

• Certificate Auditors

L’auditor va s’assurer qu’un certificat n’est pas corrompu, par la cohérence du chiffrement ou l’intégrité des logs. Cette fonction va s’ajouter au mécanisme de Handshake SSL. Dans un modèle basique, la CA a obtenu un SCT du serveur de log lors de l’étape de signature du certificat, et va l’intégrer dans une extension X.509v3 du certificat délivré. Le client, via le handshake SSL, recevra le certificat, sa chaine de certification, ainsi que le SCT. Il pourra donc vérifier la chaine de certification comme c'‘est aujourd’hui le cas, mais également vérifier le SCT, en s’assurant de la validité des logs pour ce SCT (SCT bien signé pour ce certificat particulier). Les vérifications via Monitor (contrôle par la CA) et Auditor (contrôle par le navigateur web) pourront également se faire pour compléter les validations et l’authenticité du certificat.

• CAA

• Certificates transparency