5. Security Considerations

5. Security Considerations

La conception de ce défi repose sur certaines hypothèses centrées sur le comportement d'un serveur HTTPS pendant la validation.

La première hypothèse est que lorsqu'un serveur HTTPS sert du contenu pour plusieurs noms DNS à partir d'une seule adresse IP, il sépare correctement le contrôle de ces noms entre les utilisateurs qui les possèdent. Cela signifie que si l'utilisateur A enregistre l'hôte A et l'utilisateur B l'hôte B, le serveur HTTPS ne doit pas permettre qu'une requête TLS utilisant une valeur SNI pour l'hôte A soit servie par l'utilisateur B ni qu'une connexion TLS avec une extension server_name identifiant l'hôte B soit répondue par l'utilisateur A. Si le serveur HTTPS permet à l'utilisateur B de servir cette requête, cela lui permet de valider de façon illégitime le contrôle de l'hôte A auprès du serveur ACME.

La deuxième hypothèse est qu'un serveur ne violera pas [RFC7301] en acceptant d'utiliser le protocole acme-tls/1 sans réellement le comprendre.

Pour atténuer davantage le risque que des utilisateurs revendiquent des noms de domaine utilisés par d'autres utilisateurs sur la même infrastructure, les hébergeurs, les CDN et autres fournisseurs de services NE DEVRAIENT PAS permettre aux utilisateurs de fournir leurs propres certificats pour le processus de validation TLS ALPN. Si les fournisseurs souhaitent mettre en œuvre la validation TLS ALPN, ils DEVRAIENT uniquement générer eux-mêmes les certificats utilisés pour la validation et ne pas exposer cette fonctionnalité aux utilisateurs.

Les extensions au protocole ACME décrites dans ce document s'appuient sur les considérations de sécurité et le modèle de menace définis à la section 10.1 de [RFC8555].