Journal Letsencrypt désactive l'authentification tls-sni

Posté par  . Licence CC By‑SA.
Étiquettes :
56
19
jan.
2018

Let's Encrypt (LE) est une autorité de certifications qui a bousculé l’écosystème en fournissant gratuitement des certificats SSL reconnus par la plupart des navigateurs.
Ces certificats ont une durée de validité assez courte (quelques mois), mais des scripts permettent de les générer et de les renouveler automatiquement.

Pour obtenir ou renouveler un certificat il faut réussir à démontrer que le demandeur est bien le propriétaire du nom domaine rattaché au certificat.

Pour se faire il existait trois méthodes (challenges):

  • Challenge http-01: nécessite que le port 80 soit disponible

    • le client demande un certificat pour le domaine X au serveur Let's Encrypt (LE), le serveur retourne une chaîne aléatoire de caractères,
    • cette chaîne doit être publiée à l'url http://X/.well-known/acme/chaine,
    • si LE parvient à joindre cette url, l'authenticité du domaine est validée et le certificat est délivré par LE.

  • Challenge dns: la chaîne retournée par LE doit être rendue disponible via une requête DNS

  • Challenge tls-sni:

    • le client utilise la chaîne pour générer un certificat tls auto-signé invalide contenant la chaîne et le rend disponible sur le serveur web,
    • LE effectue une requête tls à l'adresse IP du domaine, en positionnant l'extension Server_Name_Indication à la valeur de la chaîne.

Ce challenge sni ouvre une faille de sécurité pour les hébergements mutualisés. Certains gros hébergeurs autorisent leurs clients à mettre en place n'importe quel certificat sni, sans aucune vérification.
Le résultat est qu'un client peut alors obtenir un certificat ssl pour un domaine dont il n'est pas propriétaire mais qui est hébergé à la même adresse IP.

Let's Encrypt a donc décidé de suspendre l'obtention de nouveaux certificats avec le challenge tls-sni [1], le renouvellement de certificats existants via ce challenge semble être encore possible.

Le script officiel auto-certbot peut donc ne plus fonctionner et certaines modifications peuvent être nécessaires dans votre infrastructure si vous utilisiez le mécanisme tls-sni pour générer des nouveaux certificats ssl.

[1] https://community.letsencrypt.org/t/important-what-you-need-to-know-about-tls-sni-validation-issues/50811

  • # Challenge http-01

    Posté par  (site web personnel) . Évalué à 5.

    Pour les personnes qui se disent juste "oh zut ça marche plus", il y a toujours moyen d'utiliser l'option webroot du challenge http-01 qui nécessite pas de couper son serveur web pour donner le port 80 à certbot.

    En gros, on indique à certbot où se trouve la racine du site web qu'on veut sécuriser. Certbot y dépose son .well-known (le challenge), et ainsi le serveur ACME peut accepter la demande.

    Par exemple :

    certbot --authenticator webroot --installer nginx -d domaine.truc.net -w /var/www/domaine.truc.net/public

    Note: l'option --installer nginx ici sert seulement à reconfigurer semi-automatiquement nginx après que le challenge a été accepté et le certificat créé.

    • [^] # Re: Challenge http-01

      Posté par  . Évalué à 2.

      il y a toujours moyen d'utiliser l'option webroot du challenge http-01 qui nécessite pas de couper son serveur web pour donner le port 80 à certbot.

      J’utilise TLS-SNI en coupant Apache parce que mon FAI bloque le port 80. J’imagine que je vais devoir bricoler un peu plus encore.

      • [^] # Re: Challenge http-01

        Posté par  . Évalué à 4.

        mon FAI bloque le port 80.

        WTF !! C'est quoi ce FAI moisi ?!

        • [^] # Re: Challenge http-01

          Posté par  . Évalué à 2.

          Vidéotron :)

          • [^] # Re: Challenge http-01

            Posté par  . Évalué à 0.

            Je suis dans la même situation.

            Je crois que le seul moyen restant est avec le challenge DNS!
            Je tente le truc mais je n'ai pas trouvé comment ajouter un TXT record avec Google Domains…

    • [^] # Re: Challenge http-01

      Posté par  . Évalué à 2.

      D'autre part certbot a un pre-hook et un post-hook.
      Je m'en sers pour ouvrir le port 80 puis le fermer.

  • # Nom de domaine intranet?

    Posté par  (site web personnel) . Évalué à 2.

    Je me demandais dernièrement si LetsEncrypt permettait de signer des certificats pour un domaine interne, quand l'endroit où tu bosses a eu la mauvaise idée de faire domaine.prive au lieu de in.domaine.fr.

    Du coup c'est impossible non?

    • [^] # Re: Nom de domaine intranet?

      Posté par  . Évalué à 5.

      Du coup c'est impossible non?

      C’est effectivement impossible avec Let’s Encrypt, et théoriquement avec n’importe quelle CA puisque cette pratique est désormais officiellement interdite par les consignes du CA/Browser Forum (§7.1.4.2.1) :

      [….] the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name […]

      (Internal Name s’entendant d’un nom « that cannot be verified as globally unique within the public DNS at the time of certificate issuance because it does not end with a Top Level Domain registered in IANA’s Root Zone Database. »)

      Après, si tu veux réellement un tel certificat, tu trouveras bien une CA qui pourras t’en fournir un…

    • [^] # Re: Nom de domaine intranet?

      Posté par  (site web personnel) . Évalué à 10. Dernière modification le 20 janvier 2018 à 16:19.

      Ça n’existe pas et ça ne doit pas exister, c’est une très mauvaise pratique en effet (et pas de honte à avoir, on est tous passés par là). Le problème de confiance envers les « grands » du certificat c’est aussi d’avoir certifié des domaines locaux, c’est une qualité de Let's Encrypt de ne pas le faire.

      Le seul choix viable pour un domaine local c’est d’utiliser un domaine réel (maintenant que n’importe qui avec beaucoup de sous peut devenir TLD, qui te dit que personne ne va pas réserver .prive et te mettre dans le caca ?

      Et pour des raisons pratiques le seul choix viable pour un domaine local c’est d’utiliser pour ton réseau privé un sous-domaine de ce domaine réel.

      Par exemple si tu réserves le nom de domaine example.com pour ta société, tu peux utiliser intra.example.com ou n’importe quelle variation pour tes domaines internes (comme ton exemple de in.domaine.fr), comme ça tu n’as pas de conflit de résolution en fonction que tu sois en interne ou en externe, et tu n’as pas à faire cette horreur qui consiste à avoir des dns qui ne renvoient pas les mêmes résultats en interne et en externe. Et bonus dans tout ça, tu peux certifier tous tes domaines internes. Un nom de domaine bidon ça coûte 10€/mois c’est à la portée de la plus petite micro entreprise. Et le domaine n’a pas forcément besoin de faire sens, ce n’est pas une marque, voir les 1e100.net (Google) et autres poneytelecom.eu et coucou-networks.fr (Online) par exemple.

      Bref, il faut fuir les .lan, .home etc. ça va péter à la gueule de tout le monde. Et il ne faut pas utiliser le .local soi-même (c’est réservé au mDNS et ça peut mettre un sérieux merdier à ce que j’ai compris).

      Et plus brièvement pour répondre à la question « si LetsEncrypt permettait de signer des certificats pour un domaine interne », bien sûr que non : tout le monde pourrait signer un certificat pour ton domaine interne, j’aurais autant le droit que toi de réclamer un certificat pour domaine.prive, c’est comme ne pas avoir de certificat.

      Courage, je crois plutôt que ce sont ceux qui travaillent avec des bonnes pratiques qui se sentent un peu seuls. :-)

      ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: Nom de domaine intranet?

        Posté par  . Évalué à 1.

        tu n’as pas à faire cette horreur qui consiste à avoir des dns qui ne renvoient pas les mêmes résultats en interne et en externe.

        Tu n’as pas à le faire mais tu peux le faire, malheureusement.

        J’ai travaillé dans un institut où l’intranet utilisait des noms en local.institut.example. Seul le serveur DNS local de l’institut pouvait résoudre les noms sous local.institut.example. Depuis l’extérieur, les serveurs faisant autorité pour institut.example répondaient NXDOMAIN pour local.institut.example et tous les noms en dessous.

        Je ne sais pas si c’est une pratique répandue, mais personnellement j’ai trouvé ça prodigieusement chiant.

        • [^] # Re: Nom de domaine intranet?

          Posté par  (site web personnel) . Évalué à 2.

          Ça ce n’est pas très gênant, ce qui est très très très gênant, c’est quand tu as www.example.com qui est ton site web et que le sous-domaine www est géré par un dns public, mais que tu as samba.example.com qui est un serveur CIFS dont le nom est géré par un service Active Directory à qui tu ne confieras jamais la gestion des domaines publics. En local le serveur dns qui a autorité pour samba.example.com a aussi autorité pour www.example.com. Bon, heureusement j’ai déjà entendu des situations comme ça mais je ne les ai pas (encore ?) rencontrées moi-même !

          ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: Nom de domaine intranet?

        Posté par  . Évalué à 6.

        et tu n’as pas à faire cette horreur qui consiste à avoir des dns qui ne renvoient pas les mêmes résultats en interne et en externe.

        J'ai beau essayer de le faire comprendre à beaucoup d'admins, ils sont pour la plupart convaincus que c'est au contraire un très bonne pratique. Citer des RFC ne les fait que réagir par un « TL;DR » à peine caché.

        Et il ne faut pas utiliser le .local soi-même (c’est réservé au mDNS et ça peut mettre un sérieux merdier à ce que j’ai compris).

        Effectivement, mais un admin m'a dit que « c'est une recommandation de Microsoft » (cf. https://en.wikipedia.org/wiki/.local#Microsoft_recommendations) et du coup refuse de faire autrement… sachant que j'avais « implémenté » du mDNS correctement sur le réseau juste avant. Pareil, citation de RFC, mais aucun admin n'en a jamais rien à foutre des standard, ce sont les meilleurs alliés de MS dans le trashage des standards.

        Bref, je pleure régulièrement de l'état des réseaux d'entreprise et de l'obstination insistante des admins dans leur nullité.

        PS : tout ça accompagné de NAT à gogo et d'un gros firewall qui fait du DPI pour l'accès au Net, sinon ça ne serait pas drôle. Il (un Fortinet) va même jusqu'à examiner le handshake TLS pour refuser certaines signatures, comme un client Tor, qui du coup match toutes les Debian stable, mais pas les Ubuntu, du coup je suis le vilain petit canard.

      • [^] # Re: Nom de domaine intranet?

        Posté par  . Évalué à 4.

        Je ne comprends pas ce que tu décris comme la bonne pratique.

        Disons qu'on a une PME qui a exemple.fr, un petit réseau local derrière une box de FAI grand public, des serveurs web et mail hébergés en externe et quelques serveurs en interne (disons, wiki et git).

        Mettre en place un DNS interne qui résout wiki.exemple.fr avec l'adresse IP locale est une mauvaise pratique ?

        • [^] # Re: Nom de domaine intranet?

          Posté par  . Évalué à 3.

          Non, tu peux avoir des adresses qui ne sont résolues que sur ton réseau local, ce n'est pas un problème. La mauvaise pratique, c'est d'utiliser un domaine qui ne t'appartient pas, typiquement .local (qui peut déjà poser problème avec mDNS) ou .lan

          Ce n'est pas parce que ces ressources ne sont pas accessibles de l'Internet qu'il faut leur donner un nom qui n'est pas unique, pour paraphraser un type qui parle mieux que moi de DNS : http://www.bortzmeyer.org/pourquoi-le-tld-local-n-est-pas-une-bonne-idee.html (un petit argument d'autorité pour tenter de répondre aux recommandations Microsoft).

    • [^] # Re: Nom de domaine intranet?

      Posté par  . Évalué à 4.

      Après, en interne, tu peux te faire ta propre CA dont tu installes les certificats sur les postes clients.

  • # Certbot et nginx ou apache

    Posté par  (site web personnel) . Évalué à 5.

    Pour les gens qui utilisent Certbot avec les modules nginx ou apache, pas de soucis pour le renouvellement, mais la délivrance de nouveaux certificat sera bloquée car le challenge tls-sni est le seul supporté par ces plugins.

    Une nouvelle version de Certbot est sortie pour palier ce problème, mais elle ne sera pas dispo avant des lustres dans les distributions; a fortiori celles installées sur des serveurs en prod.

    Une solution consiste à utiliser Certbot en webroot ou en standalone :

        # Webroot method
    sudo certbot --authenticator webroot --installer nginx --webroot-path <path to served directory> -d <domain>
    # Temporary outage method
    sudo certbot --authenticator standalone --installer nginx -d <domain> --pre-hook "service nginx stop" --post-hook "service nginx start"

    https://community.letsencrypt.org/t/solution-client-with-the-currently-selected-authenticator-does-not-support-any-combination-of-challenges-that-will-satisfy-the-ca/49983

    Pour voir quels challenges sont implantés dans quelles modules : https://certbot.eff.org/docs/using.html#getting-certificates-and-choosing-plugins

    Adhérer à l'April, ça vous tente ?

    • [^] # Re: Certbot et nginx ou apache

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      Une meilleure solution est d'utiliser dehydrated qui ne va pas bidouiller ta config de serveur web et faire n'importe quoi. Ça marche très bien en plus !

      https://github.com/lukas2511/dehydrated

      ça ne dépend que de bash et quelques outils shell.

      « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

      • [^] # Re: Certbot et nginx ou apache

        Posté par  . Évalué à 3.

        qui ne va pas bidouiller ta config de serveur web et faire n'importe quoi

        Certbot en mode certonly et --webroot te fourni juste un certificat.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Certbot et nginx ou apache

        Posté par  . Évalué à 3. Dernière modification le 06 février 2018 à 11:14.

        J'aurais plus tendance à faire confiance à certbot qui est fiable, testé, bien documenté et géré par l'EFF, qu'à un script bash de 1651 lignes sans tests unitaires fait par un inconnu.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.