# Protocole ACME (Let's Encrypt)
@HugoCo et @SandrineRoux
## Résumé

Le protocole ACME *(Automatic Certificate Management Environment)* vise à automatiser l'émission d'un certificat d'une autorité de certification (CA). Il a été normalisé dans *le RFC 8555* et est principalement utilisé par un AC très connu : *Let's Encrypt*.
L'utilisation d'un certificat est très importante pour la sécurité de l'utilisateur sur un site internet. Pour obtenir un certifcat grâce à ce protocole et à la CA Let's Encrypt, le nom de domaine doit d'abord être validé. L'apport en sécurité du protocole réside sur le fait de vérifier qu'un partenaire est capable de faire des modifications uniques sur son site, appelés **défis**. Il y a plusieurs types : des [défis](https://www.iana.org/assignments/acme/acme.xml#acme-validation-methods) HTTP, DNS... et d'autres défis pourront être ajoutés dans le futur.

## Fonctionnement du protocole

### Vérification des domaines

La vérification de domaine nécessite l'utilisation de clé publique. En effet, l'administrateur d'un serveur web va être identifié auprès de Let's Encrypt (CA) grâce à sa clé publique.
Lors de la première connexion du site web (via son agent de gestion de certificat) avec Let's encrypt, des clés sont générées et l'agent doit prouver qu'il possède un ou plusieurs noms de domaine pour son serveur web. Pour cela, l'agent de contrôle va se voir attribuer un ensemble de défis par Let's Encrypt. Il devra soit réaliser, par exemple, le défi DNS-01 ou le défi HTTP-01.
De plus, l'agent doit également prouver qu'il possède et contrôle bien les clés qu'il a générées. C'est pourquoi la CA demande à l'agent de chiffrer un nonce avec sa clé privée.

Lorsque l'agent a réussi un défi et a signé le nonce, il demande à l'AC de poursuivre la validation de domaine. Si les défis et le chiffrement du nonce ont été correctement réalisés, l'agent est autorisé à gérer les certificats de son nom de domaine. Il possède dans ce cas une paire de clés autorisée par nom de domaine. Il doit ensuite faire une demande pour récupérer son certificat.

### Explication des deux défis les plus utilisés
* Dans le défi `http-01`, le client ACME a pour tâche de configurer un serveur http avec une page spécifique demandée par le protocole avec comme nom le contenu du jeton (souvent dans `http://DOMAINE-DEMANDÉ/.well-known/acme-challenge/JETON`). Le serveur ACME va ainsi pouvoir récupérer cette ressource et si il y arrive, on pourra prouver que le client contrôle bien le site Web.

* Dans le défi `dns-01`, le client a pour tâche de mettre dans le DNS un enregistrement TXT `_acme-challenge.DOMAINE-DEMANDÉ` qui contient le jeton. Le client doit donc avoir accès au serveur DNS qui fait autorité.

### Délivrance du certificat

Pour réaliser une demande de certificat, l'agent va envoyer un message de gestion de certificat qui sera chiffré par sa paire de clé autorisée. Il s'agit d'un message CSR (Certificate Signing Request) de type PKCS#10. Le message envoyé à l'AC contient le nom de domaine et une clé publique spécifiée. Ce message est chiffré par la clé privée de la clé publique spécifiée. Le tout est chiffré par la paire de clé autorisée (cf. étape précédente). Let's Encrypt va vérifier grâce à la clé autorisée que la demande est légitime. Il va ensuite vérifier la signature de la clé spécifiée. Si les deux signatures sont correctes, il va alors délivrer un certificat pour le nom de domaine avec la clé publique spécifiée qu'il va renvoyer à l'agent.
Le schéma ci-dessous présente le mécanisme de demande de certificat. S représente la clé spécifiée et A la clé autorisée. Le schéma a été réalisé par le site suivant : https://letsencrypt.org/fr/how-it-works/


### Révocation du certificat
Pour faire une demande de révocation de certificat, l'agent doit envoyer un message à l'AC et le signer avec sa paire de clé autorisée. Si l'AC reconnaît la signature, elle publie dans les canaux de révocation le fait que le certificat a été révoqué. Cela permet de "prévenir" les navigateurs que le certifcat de ce nom de domaine a été révoqué.
Le schéma ci-dessous présente le mécanisme de révocation. Il a été réalisé par le même site que le schéma précédent.


## Usages

Ces certificats de sécurité, pouvant être délivrés par ce protocole ACME, servent à de nombreux protocoles comme TLS.

Le protocole ACME est particulièrement utile pour les petits sites utilisant des CMS comme Wordpress ou Wix qui permettent à des particuliers n'ayant pas de grandes compétences informatiques de réaliser un site. Il est ainsi nécessaire de sécuriser leur site le plus simplement possible.

Il est recommandé d'utiliser des clés pendant seulement 3 mois pour la sécurité du systeme.

Le protocole est pour l'instant utilisé par un seul CA mais n'importe qui voulant le faire peut monter un CA avec [Boulder](https://github.com/letsencrypt/boulder), un logiciel gratuit.

## Limites
- le protocole authentifie le serveur mais ne prouve pas la confiance dans le site
- la liste des CA faisant autorité est choisie par une poignée d'acteurs très influents (systèmes d'exploitation, navigateurs web...)
- le protocole est sensible à certains types d'attaques (plusieurs utilisateurs sur le serveur sans sécurité, attaque [Kaminsky](https://www.bortzmeyer.org/comment-fonctionne-la-faille-kaminsky.html))
- l'AC utilisée reste maitresse de sa politique d'émission des certificats
- Vulnérable aux attaques DNS
- Vulnérable aux attaques BGP

Le protocole ACME est donc une partie de la protection nécessaire mais ne saurait se substituer à d'autres compléments de sécurité. Sa seule présence sur un serveur web ne garantit pas, à elle seule, la sécurité de l'utilisateur.

*L'automatisation de l'émission des certificats peut être dangereuse. La diversité des CA est une bonne chose car elle permet, entre autres, de ne pas compromettre l'ensemble des certificats lorsqu'une CA est compromise. Ainsi, de par la facilité d'obtention d'un certificat, il est probable que beaucoup de domaines dépendent de la sécurité du système de gestion des clés de Let's Encrypt.*

## Sources
[Bortzmeyer](https://bortzmeyer.org/8555.html), Explication du RFC 8555 - Protocole ACME

[Let's Encrypt](https://letsencrypt.org/fr/how-it-works/), Comment fonctionne Let's Encrypt

[IETF](https://tools.ietf.org/html/rfc8555), RFC 8555

## Propositions NST :
- [x] Détailler un peu plus les limites du protocole, notamment face aux attaques mises en place en TP.
- [X] Quelle durée de vie conseillée pour les clefs et pourquoi ?
- [ ] "Lors de la première connexion du site web" -> donc quid du renouvellement d'un certificat ? idem que première création ?