First par of certificates course

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.