- Let's Encrypt va bientôt prendre en charge l’émission de certificats incluant des SAN d’adresses IP ; dans un premier temps, ils ne seront proposés que via un profil shortlived à expiration de 6 jours, avec une exploitation limitée par liste blanche pendant une certaine période
- Avant l’ouverture officielle, aucun calendrier précis ni procédure de demande ne sont encore communiqués, les tests internes et les préparatifs étant toujours en cours
- Dans l’environnement de staging, un certificat d’exemple incluant une adresse IPv6 ainsi qu’un site l’utilisant ont été publiés, avec un appel à la communauté pour signaler toute anomalie ou partager des retours
- Un bug dans Firefox lié à l’affichage des SAN IP (BZ #1973855) a été identifié, et les tests se poursuivent
- Des tests réels ont confirmé un risque de confusion dans les cas mêlant DNS SAN et IP SAN, en montrant que certains TLD et la notation IPv6 peuvent se ressembler
Let's Encrypt, Getting ready to issue IP address certificates
État de préparation pour la prise en charge des SAN d’adresses IP
- Let's Encrypt prévoit bientôt de prendre en charge en production l’émission de certificats contenant des SAN d’adresses IP
- Ces certificats ne seront émis que via le profil shortlived avec une durée de validité de 6 jours, et leur utilisation sera limitée par allowlist pendant un certain temps
- La date de lancement officielle et la méthode de demande d’inscription sur l’allowlist ne sont pas encore définies, car des préparatifs internes supplémentaires sont nécessaires
Tests et certificats d’exemple
- Des certificats d’exemple incluant un IP SAN et un site réellement configuré avec ceux-ci (adresse IPv6) ont été publiés dans l’environnement de staging
- Les membres de la communauté sont invités à partager toute anomalie, observation intéressante ou problème identifié
Cas de mélange entre IP SAN et DNS SAN
- Les tests ont permis de démontrer la possibilité d’émettre des certificats contenant à la fois des DNS SAN et des IP SAN, ainsi que des cas de confusion d’affichage
- Il peut y avoir un risque de confusion, car certains TLD comme
.cafe peuvent ressembler à la notation d’une adresse IPv6
- Un bug de Firefox lié à l’affichage des SAN d’adresses IP (BZ #1973855) a également été confirmé
Résumé
- La prise en charge des certificats pour adresses IP par Let's Encrypt sera d’abord déployée de manière limitée, avec liste blanche et certificats de courte durée
- Avant une utilisation en production réelle, divers cas de test et les retours de la communauté serviront à vérifier la stabilité et la compatibilité
- Les problèmes d’affichage dans les navigateurs liés à la coexistence de SAN de noms DNS et d’adresses IP font également partie des discussions en cours
1 commentaires
Avis sur Hacker News
Je pense aussi que des certificats pour adresses IP peuvent être utiles
Mais je pense que l’impact serait bien plus important si Let’s Encrypt prenait en charge les certificats S/MIME
Depuis des années, la situation autour du chiffrement des e-mails est presque comique
Désormais, la plupart des grands clients e-mail prennent en charge nativement le chiffrement S/MIME, mais comme pour le web, il faut obtenir un certificat auprès d’une AC pour offrir une expérience fluide
Il n’existe plus vraiment d’AC qui fournisse des certificats S/MIME fiables, gratuits et valables plus d’un an
Résultat : les particuliers n’utilisent pratiquement pas le chiffrement des e-mails
PGP est trop peu pratique pour être utilisé par autre chose que des passionnés de technique
Je pense qu’il est temps de chiffrer aussi nos e-mails
Au passage, si l’AC génère elle-même la clé privée, je considère que le certificat n’est pas digne de confiance
Et comme S/MIME impose de conserver les anciens certificats pour déchiffrer les anciens messages, des certificats qui changent trop souvent sont peu pratiques
Concernant l’idée qu’il faut l’ancien certificat pour déchiffrer les vieux e-mails avec S/MIME, je pense qu’on n’est pas obligé de faire des rotations fréquentes puisque la clé de déchiffrement elle-même peut être réutilisée dans un nouveau certificat (par exemple avec l’option
--reuse-keyde certbot)Cela dit, savoir si c’est une bonne pratique est une autre question
Ce qu’il faut vraiment, à mon avis, c’est une automatisation de l’émission des certificats à la manière d’ACME
Aujourd’hui, le renouvellement des certificats est trop pénible, donc presque personne ne l’utilise
Pour PGP, il existe maintenant WKD (Web Key Directory)lien, ce qui permet d’appliquer au courrier électronique la toile de confiance de TLS
Les certificats TLS sont bien plus faciles à obtenir que les certificats S/MIME
Le fait qu’un tiers prenne en charge la gestion d’identité peut aider, mais beaucoup de gens travaillent dans des entreprises où ce modèle convient mal
S’il s’agit d’une entreprise, je pense qu’il est plus approprié de gérer l’identité en interne
Le récent épisode Signalgate 1.0lien a, à mon sens, été très instructif comme échec de gestion d’identité dans le chiffrement de bout en bout
C’est le genre de point qui pourrait aussi rendre des systèmes comme les certificats S/MIME ou WKD utiles pour les administrations, s’ils étaient adoptés de manière réellement exploitable
Personnellement, je vois d’un bon œil le chiffrement des e-mails basé sur S/MIME, mais je doute de sa faisabilité
Les utilisateurs ordinaires ont déjà souvent du mal à gérer une clé privée, et même un simple mot de passe e-mail est parfois mal géré
Au final, soit il faut une émission centralisée des certificats par domaine, soit les utilisateurs ne peuvent pas obtenir de certificat, pendant que des cybercriminels envoient des e-mails signés S/MIME
Quand les passkeys seront devenues courantes et que le renouvellement générationnel aura fait son œuvre, ce sera probablement le bon moment pour demander aux gens de manipuler eux-mêmes des paires de clés
À mon avis, le chiffrement des e-mails devrait simplement disparaître
Référence : Stop using encrypted email
Je connais mal le chiffrement S/MIME, donc j’ai une question
Pourquoi faut-il déchiffrer les anciens e-mails avec le même protocole ?
J’avais toujours pensé que les certificats servaient au transport, et qu’au stockage il y aurait un chiffrement distinct côté serveur ou hôte ; il semblerait donc logique d’utiliser, par exemple, des certificats courts pour le transport et un autre mode de chiffrement pour le stockage. Je me demande si je rate quelque chose
Je me demande si tous les organismes qui gèrent des adresses, comme les FAI ou les fournisseurs cloud, vont eux aussi devoir suivre ce mouvement
Ils font parfois tourner les IP très vite, parfois en moins de 6 jours
Je comprendrais si les fournisseurs cloud imposaient une période de refroidissement avant de réattribuer une IP, ou vérifiaient et révoquaient les certificats associés à cette IP, mais sinon cela crée une complexité où l’utilisateur doit vérifier l’en-tête Host, refuser les connexions IP non souhaitées ou attendre la disparition complète des anciens certificats
Je me demande aussi combien de certificats IP on pourra obtenir chez chaque fournisseur cloud, et à quel prix
En réalité, je pense que ce n’est pas si différent de la fourniture de domaines personnalisés/vanity par les fournisseurs cloud
Par exemple, dans Azure, on peut lier à une VM un DNS du type
myapp.westus.cloudapp.azure.com, et n’importe qui peut obtenir auprès d’une AC un certificat pour ce domaine référenceLà aussi, quand la VM disparaît, quelqu’un d’autre peut récupérer immédiatement ce domaine sans période de refroidissement particulière
Un certificat HTTPS peut être renouvelé pour 90 jours la veille de l’expiration du domaine, et l’AC ne connaît même pas la limite de la carte bancaire
Ceux qui utiliseront des certificats IP seront sans doute rarement les mêmes que ceux qui jettent vite leur IP et passent à autre chose
Les cas les plus utiles sont probablement des logiciels legacy très particuliers, ou le besoin de prendre en charge ECH (Encrypted Client Hello) ou ESNI (Encrypted SNI) sans IP partagée, comme chez Cloudflare
Dans le premier cas (legacy), on abandonnera difficilement l’IP ; dans le second (ECH/ESNI), je pense qu’il sera difficile d’établir une connexion vers le vrai domaine
À la question de savoir si les FAI doivent suivre, je dirais même plutôt l’inverse
Le rôle des FAI n’est pas d’attribuer des IP selon les contraintes des standards TLS ; c’est plutôt aux fournisseurs de certificats TLS d’assurer la « vérification d’identité » en fonction de la manière dont l’écosystème relie les identités (domaines, IP, etc.)
On ne sait pas encore exactement comment cela sera mis en œuvre, mais mon intuition est que Let’s Encrypt va établir une liste des IP durablement transférées par ASN (numéros de système autonome), un peu comme une base publique co-maintenue à la manière de la Mozilla Public Suffix List, et n’émettre des certificats que pour les IP présentes dans cette liste, avec gestion d’invalidation en cas de passage à un autre ASN
J’espère que ce mécanisme sera aussi partagé avec d’autres autorités ACME
Si l’on se demande combien de certificats IP on pourra obtenir sur différents clouds, et à quel prix, on peut aussi se demander si un support des certificats wildcard arrivera un jour
Dans mon cas, avoir un certificat IP ne serait-ce qu’une seule journée suffirait pour tester des URL en
https, donc je trouve ce changement très bienvenuTechniquement, je comprends comment cela fonctionne, mais je me demande quel est le cas d’usage réellement visé
Rien que la prise en charge d’ECH (Encrypted Client Hello) ou d’ESNI (Encrypted SNI) me semble déjà très importante
Au début d’ESNI, seuls de gros proxies HTTPS comme Cloudflare pouvaient l’utiliser, donc l’idée de certificats IP relevait presque du rêve, mais désormais tous les serveurs peuvent participer à ESNI/ECH
Si les clients commencent à supposer que tous les serveurs ont des certificats IP et tentent ESNI, cela pourrait grandement améliorer la confidentialité sur l’ensemble d’Internet
Plusieurs bonnes réponses ont déjà donné des exemples, mais NTS (Network Time Security) mérite aussi d’être mentionné
Sans certificat IP, NTS dépend aussi du DNS, donc si le DNS tombe, la synchronisation horaire authentifiée devient impossible
DNSSEC échoue à valider sans heure correcte, donc avec une dépendance DNS + NTS, il n’y a plus de voie de récupération
Si un certificat contenant l’IP permettait de distribuer une heure authentifiée sans dépendre du DNS, cela résoudrait ce problème
Cela peut servir si l’on doit conserver un certificat valide pendant une période où le DNS change beaucoup, par exemple pour maintenir l’accès à un tableau de bord ou éviter qu’une ancienne automatisation s’arrête à cause d’une erreur DNS
Autre cas : mettre en place plus simplement un environnement de test ou exposer rapidement un service comme Cockpit sans dépendre du DNS
En pratique, les usages possibles ne sont limités que par l’imagination
Cela pourrait aussi être intéressant pour du DoTLS (requêtes DNS sur TLS) « opportuniste » vers des authdns (serveurs DNS faisant autorité)
Un serveur DNS faisant autorité pourrait servir sur son port DoTLS avec un certificat contenant son IP publique dans le SAN (Subject Alternative Name)
C’est déjà possible aujourd’hui avec un nom d’hôte, mais comme plusieurs noms différents peuvent pointer vers une même IP publique, un SAN basé sur l’IP crée un lien plus clair
Je pense que c’est adapté à ceux qui veulent connecter un projet directement à une IP plutôt qu’à un nom d’hôte, par loisir ou pour un usage ponctuel sans domaine
Je me demande pourquoi ce ne sont pas les registres Internet régionaux (RIR) ou locaux (LIR) qui émettent les certificats
Pourquoi faut-il qu’un tiers vérifie les titulaires enregistrés auprès des RIR ou LIR ? Est-ce simplement parce que les registres de domaines ont déjà trop de travail ?
Je me demande si la raison est vraiment la même
J’ai l’impression que cela ouvre de nouvelles façons d’abuser de TLS
Jusqu’ici, le problème était l’émission de certificats pour des domaines qu’on ne possède pas ; maintenant, on pourrait aussi imaginer des certificats pour des IP qu’on ne possède pas
Les black hats vont sans doute s’en donner à cœur joie sur Telegram
Je me demande si cela permettra d’accéder en
httpsaux interfaces d’administration de routeurs locaux (par exemple192.168.0.1) sans erreur de certificat auto-signéNon, mais cela pourrait peut-être devenir possible un jour
Les adresses locales ne sont pas attribuées de manière universelle et ne sont pas routées globalement, donc il n’existe pas de moyen intrinsèque de les valider
Mais si le fabricant du routeur le voulait vraiment, il serait possible de demander un certificat pour l’adresse publique sur les équipements qui ne sont pas derrière du CG-NAT et disposent d’une IPv4 publique
Avec IPv6, c’est encore plus simple, puisque la plupart des adresses sont routées globalement
Non, et cela ne devrait pas être le cas
En pratique, on peut déjà très bien s’en sortir avec un proxy, un vrai domaine, un vrai certificat et une fonction de réécriture DNS
Par exemple avec l’interface nginx manager et adguard pour le DNS
On limite le DNS du routeur à adguard, on réécrit son domaine vers le proxy
Il suffit ensuite d’enregistrer le domaine et d’obtenir un vrai certificat
J’utilise moi-même
httpspour tous mes services locauxLes certificats ne sont pas émis pour les IP privées
La même IP privée peut, dans d’autres réseaux, désigner à tout moment des équipements complètement différents, donc il n’y a pas de garantie de possession exclusive
C’est même l’inverse
Sans IP publique, impossible d’obtenir un certificat valide
On peut déjà obtenir un certificat de domaine et faire pointer ce domaine vers
192.168.0.1Pour obtenir un certificat, il faut réellement posséder cette IP, donc une IP publique
Je me demande s’il sera possible d’avoir des certificats pour des IPv4 internes (
192.168.x.x,172.16.x.x,10.x.x.x), ou si les navigateurs ont raison d’ignorer ces adresses, et à défaut s’il serait possible d’obtenir au moins un certificat wildcard pour un réseau interneDans le contexte de certificats émis par une AC publique, la question n’a pas vraiment de sens
Contrairement aux domaines, une IP privée comme
10.10.10.10est simultanément « possédée » par d’innombrables personnesPour du développement interne, il existe des outils comme
mkcert, et pour des ressources partagées en entreprise, des certificats TLS basés sur des noms de domaine sont plus simplesSi l’on pouvait prouver que la clé privée de l’équipement ne fuitera jamais, on pourrait même tenter quelque chose avec une AC classique
Mais pour des certificats d’adresses internes, si quelqu’un achète un appareil et récupère sa clé privée, la révocation de cette clé devient immédiatement problématique
C’est pourquoi, avec des appareils de confiance, il est plus réaliste d’importer manuellement un certificat pour éviter les avertissements, ou, s’il y a plusieurs appareils, de déployer sa propre AC pour distribuer des certificats
Avec un serveur ACME open source, on peut aussi automatiser en interne l’émission de certificats de la même façon que Let’s Encrypt
Il est possible de faire passer temporairement le DNS par un serveur public pour obtenir le certificat, puis de faire redescendre ensuite le DNS vers une adresse interne
192.168…et d’y copier le certificat et la cléAttention cependant : certains routeurs peuvent blackholer les réponses DNS qui pointent vers des adresses internes, donc il vaut mieux tester avant
Je ne pense pas que les navigateurs devraient ignorer les réseaux privés
Dans mon cas, un réseau privé n’est guère plus que mon routeur local, mais pour d’autres il peut s’agir d’un réseau à l’échelle mondiale
Je trouve intéressant que le certificat d’exemple n’ait pas de champ subject
Je me demande si c’est parce qu’il est demandé pour une IP et que le DNS figure dans le SAN
C’est déjà le cas dans leur profil de certificats courts de 6 jours, mais pas encore dans le profil « classique » de 90 jours
Quelqu’un plaisante en se demandant si c’est le moment où la vulnérabilité CVE-2010-3170 va refaire parler d’elle
Dommage qu’il soit impossible d’émettre des certificats d’adresse IP via le mécanisme DNS challenge
Mais je comprends pourquoi