160 lines
6.2 KiB
Markdown
160 lines
6.2 KiB
Markdown
---
|
|
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'identité 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.
|
|
|
|
#### DNSSEC
|
|
|
|
DNSSEC permet de résoudre certains problèmes de sécurité liés à *DNS*. Il permet
|
|
de sécuriser les données envoyées par le DNS.
|
|
|
|
chaque entité dispose d'un couple de clés (privé / publique, on parle bien de
|
|
*cryptographie asymétrique*). Chaque enregistrement d'une zone est signé par la
|
|
clé privée du détenteur. Cette signature peut être vérifiée par sa **clé
|
|
publique**. Afin d'assurer l'authenticité de cette dernière, elle est signée par
|
|
la clé privée de la **zone au-dessus** -- et non pas la clé privée du détenteur.
|
|
|
|
Dans la pratique, chaque zone dispose de deux paire de clés :
|
|
|
|
* la *KSK*: Key Signing Key
|
|
* la *ZSK*: Zone Signing Key
|
|
|
|
le lien entre les deux est réalisée par la fonction:
|
|
|
|
\\[ crypt( priv_KSK, hash(ZSK) \\]
|
|
|
|
La *KSK* sert à signer la *ZSK*. La KSK publique est envoyée au détenteur de la
|
|
zone parente pour signature.
|
|
|
|
#### DNSSEC / DANE
|
|
|
|
Maintenant que *DNSSEC* est en place il est possible de stocker les
|
|
certificats dans un enregistrement *DNS*: **TLSA**.
|
|
|
|
Le client peut alors vérifier la validité du certificat.
|
|
|
|
### 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'authentification du résolvez qui
|
|
répond et le chiffrement des messages.
|
|
|
|
## PGP -- Pretty Good Privacy
|
|
|
|
*PGP* utilise la cryptographie asymétrique, chaque entité dispose donc d'une
|
|
paire de clés. L'utilisation la plus courante de *PGP* et la **signature**
|
|
(cryptographique) et le **chiffrement de courriels**. Il est aussi utilisé dans
|
|
la distribution logicielle et notamment dans les **dépôts de distributions**
|
|
*GNU/Linux* ou *BSD*.
|
|
|
|
Pour le chiffrement, *PGP* créé une **clé symétrique aléatoire** qui est ensuite
|
|
chiffrée avec la clé publique du destinataire.
|
|
|
|
Chaque partie publique contient un espace où d'autres personnes peuvent apposier
|
|
leurs signatures avec une note.
|