Cet article est la partie 3 sur trois de ma série sur le cryptage SSL/TLS. La partie 1 couvre les bases des concepts de chiffrement bien connus. La partie 2 donne une brève introduction à OpenSSL et PKI. Cette partie aborde le problème de la faiblesse de l'infrastructure à clé publique et présente deux contre-mesures.
Tout d'abord, je voudrais vous présenter le terme partie utilisatrice . Une partie de confiance est un navigateur Web, un client de messagerie, une application de chat, etc., qui tente de valider un certificat x.509. La plupart du temps, la partie utilisatrice y parvient en vérifiant si une autorité de certification dans ses ancres de confiance a signé le certificat.
[ Vous pourriez également aimer : Comment gérer plusieurs paires de clés SSH ]
Excursion :Protégez votre clé privée
Comme vous le savez peut-être dans la partie 1, la clé privée est celle que vous devez protéger. Cela commence par la création, qui doit avoir lieu sur une machine digne de confiance.
Maintenant, vous pourriez vous demander :"Qu'est-ce qu'une machine digne de confiance ?"
Eh bien, un service en ligne géré par quelqu'un que vous ne connaissez pas n'est certainement pas digne de confiance. Vous ne devez jamais créer votre clé privée à l'aide d'un service Web dans votre navigateur, car vous ne savez tout simplement pas si le fournisseur de services conserve une copie de la clé créée. Pour éviter que cela ne se produise, vous pouvez utiliser une machine hors ligne à la place.
Stockez votre clé privée uniquement là où vous en avez besoin et conservez-la en lieu sûr. Un répertoire sur un serveur FTP anonyme n'est certainement pas un endroit sûr. Un partage réseau où seuls les utilisateurs privilégiés ont accès ou un gestionnaire de mots de passe permettant de stocker des pièces jointes est certainement un meilleur endroit pour le mettre.
Si vous avez accidentellement copié votre clé privée non protégée sur un partage réseau ou un dépôt Git public, déposez-la simplement et créez-en une nouvelle. Vous ne pouvez pas être certain qu'il n'a pas été compromis. Même si vous le supprimez immédiatement, vous ne pouvez pas être sûr qu'un mécanisme d'instantané ne l'a pas déjà stocké.
Faiblesses de l'ICP
Ce qu'est PKI et son fonctionnement ont été abordés dans la partie 2 de cette série. Au cas où vous ne le sauriez pas, lisez d'abord cette partie.
En un mot, la raison pour laquelle nous traitons ce gâchis de certificats est que nous voulons aider la partie utilisatrice à s'assurer qu'elle communique avec le bon serveur et non avec une fraude. Nous obtenons donc un certificat signé par une autorité de certification en laquelle la partie utilisatrice fait confiance, et nous sommes tous satisfaits, n'est-ce pas ?
Eh bien, nous pourrions l'être s'il n'y avait pas un grave défaut de conception dans PKI.
Il existe plusieurs centaines d'autorités de certification qui ont la confiance de notre partie utilisatrice sur Internet. Certaines de ces autorités de certification ont même des sous-autorités de certification capables de signer des certificats et d'avoir la confiance de la partie utilisatrice. Et toutes ces autorités de certification peuvent émettre un certificat pour n'importe quel nom de domaine valide.
Ainsi, en général, n'importe quelle autorité de certification pourrait émettre un certificat pour votre domaine, et vous ne le sauriez même pas. Ce certificat pourrait être utilisé pour des attaques de type "man-in-the-middle" sur votre domaine, car la partie utilisatrice ferait confiance à ce certificat puisqu'il a été signé par une autorité de certification de confiance.
Et ce n'est pas une menace théorique. En mars 2015, certains certificats non autorisés émis par le CNNIC étaient utilisés pour déchiffrer le trafic passant par le Grand Pare-feu. En 2012, une société de sécurité a reconnu avoir délivré au moins un certificat à une entreprise privée qui l'utilisait pour espionner ses employés. Et en 2011, une société d'autorité de certification a été victime d'un piratage dévastateur au cours duquel certains de ses certificats de signature ont été volés.
Contre-mesures possibles
Les trois exemples ci-dessus vous montrent ce qui ne va pas avec PKI en son cœur. La conception est défectueuse. Alors comment y remédier ? Voici deux techniques qui pourraient aider à atténuer le problème.
Autorisation de l'autorité de certification (CAA)
D'après le résumé de l'enregistrement de ressource d'autorisation de l'autorité de certification DNS (CAA) dans la RFC 8659 :"L'enregistrement de ressource DNS de l'autorisation de l'autorité de certification (CAA) permet au titulaire d'un nom de domaine DNS de spécifier une ou plusieurs autorités de certification (CA) autorisées à émettre des certificats pour cette nom de domaine. Les enregistrements de ressources CAA permettent à une autorité de certification publique de mettre en œuvre des contrôles supplémentaires pour réduire le risque d'erreur d'émission de certificat involontaire."
Eh bien, je n'aurais pas pu mieux l'expliquer. CAA permet aux titulaires de noms de domaine de spécifier quelles CA sont autorisées à émettre des certificats pour notre domaine, et les CA elles-mêmes nous promettent de respecter nos enregistrements CAA. La RFC 8659 définit les trois propriétés suivantes :
- issue contient comme valeur le domaine de l'autorité de certification, qui est autorisée par l'enregistrement CAA à émettre des certificats pour un certain domaine.
- issuewild est fondamentalement identique à issue mais pour les certificats génériques. Si aucun issuewild n'est défini, la valeur de issue est utilisée à la place.
- iodef contient les coordonnées à utiliser en cas de problème concernant la politique de la CAA.
Examinons les exemples d'enregistrements suivants :
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:[email protected]" La première ligne de l'exemple ci-dessus signifie que seule l'autorité de certification Let's Encrypt serait autorisée à émettre des certificats pour n'importe quel hôte sous le domaine example.com. Toute autre autorité de certification NE DOIT PAS émettre de certificats pour ce domaine. La deuxième ligne vous donne une adresse e-mail que vous pouvez contacter en cas de problème.
Étant donné que le DNS est organisé de manière hiérarchique, l'enregistrement CAA ci-dessus s'applique à web.example.com ainsi qu'à host.web.example.com et host.sub.web.example.com. Prenons un autre exemple :
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:[email protected]"
sub.web.example.com IN CAA 0 issue "example-pki.org" Ici, seule la CA example-pki.org est autorisée à émettre des certificats pour, par exemple, host.sub.web.example.com. L'enregistrement de la troisième ligne remplace la stratégie de example.com. Je pense que vous avez saisi l'idée.
Bien sûr, les enregistrements de ressources CAA n'empêcheraient pas les autorités de certification non conformes d'émettre des certificats pour les domaines pour lesquels elles n'ont pas l'autorisation. Mais ils risqueraient d'être supprimés des ancres de confiance intégrées, ce qui signifierait la faillite dans la plupart des cas.
Et il est toujours possible qu'une autorité de certification autorisée délivre un certificat à une personne qui n'est pas autorisée à l'utiliser. Choisissez une autorité de certification de confiance et choisissez judicieusement.
Comme vous le voyez, CAA n'apporte pas une sécurité à 100 %, mais il est facile à mettre en œuvre et atténue le risque d'erreur d'émission de certificat.
Transparence des certificats (CT)
La transparence des certificats est "... un protocole expérimental pour consigner publiquement l'existence de certificats Transport Layer Security (TLS) au fur et à mesure qu'ils sont émis ou observés, de manière à permettre à quiconque de vérifier l'activité de l'autorité de certification (CA) et de remarquer l'émission de certificats suspects. certificats ainsi que pour auditer les journaux de certificats eux-mêmes. L'intention est qu'éventuellement, les clients refuseraient d'honorer les certificats qui n'apparaissent pas dans un journal, forçant ainsi les autorités de certification à ajouter tous les certificats émis aux journaux. (Résumé RFC 6962)
CT propose une forme de comptabilisation des certificats TLS et vous permet d'examiner les certificats émis par l'autorité de certification pour vos noms de domaine. Pour ce faire, vous pouvez utiliser des services tels que Cert Spotter de sslmate, qui est également disponible en version sur site. J'avais l'habitude d'exécuter la version sur site sur mon serveur privé virtuel, mais en raison de la croissance des journaux au cours des deux dernières années, il semble impossible d'explorer les journaux du début à la fin. Le travail a duré des semaines et ne s'est pas terminé; il a été abandonné lorsque j'ai dû redémarrer mon hôte pour terminer les mises à jour.
Aujourd'hui, aucune autorité de certification n'est obligée d'ajouter des certificats émis aux journaux CT, mais la croissance des journaux suggère que nombre d'entre elles ajoutent déjà leurs certificats. À mon avis, ce n'est qu'une question de temps avant que les principaux navigateurs ne commencent à faire confiance aux certificats avec une entrée de journal CT et à les rendre obligatoires.
[ Obtenez cet ebook gratuit :Gérer vos clusters Kubernetes pour les nuls. ]
Conclusion
La conception originale de l'ICP est défectueuse et n'est plus très fiable. Avec RFC 8659 et RFC 6962, deux méthodes sont proposées pour regagner la confiance et aider les détenteurs de noms de domaine à savoir qui a émis des certificats pour leurs domaines.
À partir de maintenant, n'oubliez pas de protéger vos clés privées, de définir des enregistrements de ressources CAA pour vos domaines et de commencer à surveiller les journaux CT.