From 2a3a818ee28367b149c482b5a302a3ae638d76cd Mon Sep 17 00:00:00 2001 From: Yorick Barbanneau Date: Fri, 9 Dec 2022 23:47:08 +0100 Subject: [PATCH] First par of certificates course --- content/secu_reseaux/6_certificats/index.md | 116 ++++++++++++++++++++ 1 file changed, 116 insertions(+) create mode 100644 content/secu_reseaux/6_certificats/index.md diff --git a/content/secu_reseaux/6_certificats/index.md b/content/secu_reseaux/6_certificats/index.md new file mode 100644 index 0000000..577c709 --- /dev/null +++ b/content/secu_reseaux/6_certificats/index.md @@ -0,0 +1,116 @@ +--- +title: "Sécurité des réseaux : les certificats" +date: 2022-10-18 +tags: ["TLS", "certificats", "PGP"] +categories: ["Sécurité des réseaux", "Cours"] +matjax: true +--- + +Un certificat est une pièce d'identitApé comprenant: + + * une clé publique; + * un émetteur; + * des information sur le détenteur; + +Le tout est signé par l'émetteur. + +Lors de la réception d'un certificat, le client vérifie: + + * l'autorité l'ayant signé (*Certificate Authority*) + * la validité + * l'identité + +Dans le cas du CA, il est possible de se référerà une chaine de certification +(on parle alors de certificats intermédiaire.) + +## La norme x509 + +x509 est une norme définissant les formats pour les certificats à clé publique, +leus attributs, un algorithme de validation de chemin et les liste de révocation +de certificat. + +Cette norme fait parti de x500, elle repose sur une hiérarchie d'autorité de +certification et la **cryptographie asymétrique** (clé publique / clé privée) + +## Anatomie d'un certificat + +Un certificat se compose des élémemts suivants: + + * la **version** du format de certificat + * un **numéro de série** unique pour l'autorité émettrice + * **identifiant de l'algorithme de chiffrement** utilisé + * **nom de l'émetteur** qui est donc celui de l'autorité de certification + * une **période de validité** composé d'une date de début et une date de fin + * **nom du sujet** qui peut être un nom d'utilisateur ou un sujet plus + complexe respectant la norme x500 + * **clé publique du sujet** ainsi que l'algorithme utilisé + * **identifiant unique de l'émetteur**, c'est un élément facultatif qui permet + d'identifier sans ambiguïté l'autorité de certification émettrice. + * **identifiant unique du sujet** élément facultatif qui permet d'identifier + sans ambiguïté le sujet du certificat + * un ensemble de champs permettant d'ajouter des **extensions** + * enfin la **signature** qui couvre tous les autres champs du certificat : ce + champ contient le code de *hachage* de ces champs chiffrés avec la clé privée + de l'autorité de certification. + +La notation suivante est utilisée: + +\\[ CA << A >> = CA{V,SN,AI,CA,TA,A,Ap }\\] + +Dans cette notation, \\(CA << A >>\\) est le certificat de \\(A\\) émis par +\\(CA\\) et \\(CA{SN}\\) représente la signature de \\(SN\\) par \\(CA\\) + +L'autorité de certification **signe** le certificat **avec sa clé privée**. Si +l'utilisateur détiens la clé publique correspondante dans son magasin de +certificat, il pourra alors vérifier la validité. + +## Sécuriser les certificats et leurs chaînes + +Lorsqu'un utilisateur reçoit un certificat depuis un serveur, il doit s'assurer +que celui-ci est le bon. + + +### HPKP - certificate pinning + +Comme pour le *SSH*, il peu mémoriser son empreinte lors de la première +connexion. Il peut utiliser *HPKP* -- **HTTP Public Key Pinning** -- pour la +mémoriser, le tout couplé à *HSTS* -- HTTP Strict Transport Security. + +Mais celle solution est loi d'être parfaite : quid du changement de certificat. +En plus l'attaquant pourrait être présent dès la première connexion. + +### Certificate transparency + +C'est une solution poussée par Google. Il reprend en quelque sorte le principe +du *HPKP* en l'améliorant. + +Dès qu'une autorité de certification émet un certificat, elle envoie un +condensat de celui-ci sur un dépôt public contrôlé par un tiers (Google en +fait). Le client peut **demander au dépôt** la validité du certificat. + +Problème ici : les dépôts (Google donc) deviennent tout puissant en concentrant +les pouvoirs. Ils pourraient par exemple refuser d'ajouter les certificats +venant de telle autorité ou portant sur tel sujet. + +### Certificat Autority Authorization + +Ce mécanisme prend la forme d'un enregistrement DNS `CAA` donnant **la liste des +autorité de certification** pouvant émettre des certificat pour la zone. + +Cette protection est donc sensible aux attaque sur le DNS. + +### DANE -- DNS-based Authentication of Named Entities + +Contrairement à *Certificate Transparency* ou la sécurité est déléguée à un +tiers, avec *DANE* (et *DNSSEC) on en prend le contrôle. *DANE* dépends de +*DNSSEC* qui se révèle compliqué à implémenter (et administrer). + +*DANE* permet de se passer d'autorité de certification. + +### DoH, DoT + +Ces deux mécanismes permettent de sécuriser le protocole DNS en le passant sur +du HTTPS (*DNS over HTTPS*) ou en l'en capsulant dans TLS (*DNS over TLS*). + +Les certificats assurent deux propriétés: l'autentification du résolveur qui +répond et le chiffrement des messages.