Journal Public Key Pinning Extension for HTTP

Posté par (page perso) . Licence CC by-sa
27
18
avr.
2015

Cher journal,

En ces temps ou un certain nombre d'entre vous n'ont pas l'air d'avoir envie de tout partager avec leur gouvernement. Voici une annonce qui améliore un peu la sécurité du HTTPS. Tu n'es pas sans ignorer que le modèle actuel de TLS souffre un gros problème. N'importe quelle autorité de confiance peut signer un certificat pour n'importe quel domaine, même si le propriétaire actuel du nom de domaine a déjà demandé à une autre autorité de le faire. Tu me dirais que c'est très gentil de la part d'une autorité de signer gratos un certificat signé par une autre autorité. En fait, c'est souvent fait pour faire du Man In the Middle ou de l'usurpation d'identité.

Le problème, c'est qu'il faut des autorités de confiance et qu'on se rend souvent compte qu'une telle autorité de l'était pas quand il est trop tard. La solution, c'est que le site annonce par qui il est signé (tu me diras que c'est déjà le cas, vu que c'est comme ça que fonctionne TLS), sauf qu'au lieu de l'annoncer à chaque requête, on peut se permettre de l'annoncer une fois pour toute. Le seul problème, c'est la première fois qu'on se connecte au site, il faut être sûr de ne pas avoir quelqu'un sur la ligne qui modifie le trafic qui passe.

La technique actuelle pour associer une CA à un domaine (qui s'appelle le pinning) est faite manuellement par développeur de web browser. C'est déjà en place dans Chromium et Firefox mais seulement pour les sites connus (Google, Twitter, Facebook…). Mais ça ne passe pas à l'échelle. J'ai envoyé ma CA pour mon site web via la RFC 6214 et j'attends toujours la réponse.

En résumé, comment ça se passe pour cette nouvelle technique: la RFC définit un nouveau header HTTP qui permet de spécifier la fingerprint de la CA ainsi qu'un TTL (pour pouvoir quand même changer de CA à un moment). À la connexion l'user agent (donc, le navigateur web dans la plupart des cas) récupère ce header (vérifie que ça correspond bien à l'actuel déjà) et stocker l'association domain → CA, à la prochaine connexion, il ne regardera pas le header, seulement si la CA est bien là.

Par contre, pour l'analyse détaillée, il faudra attendre Monsieur Bortzmeyer, moi, j'écris des journaux sur dlfp, je n'ai pas le temps de lire les RFC.

Bien sûr, ce n'est pas parfait. Le risque à la première connexion (ou à l'expiration du TTL) est bien réel. Mais pour tous les gens en déplacement dans des environnements peu sûrs, c'est un plus.

  • # L'analyse détaillée

    Posté par . Évalué à 10.

    Depuis 15h, aujourd'hui : https://www.bortzmeyer.org/7469.html

    • [^] # Re: L'analyse détaillée

      Posté par (page perso) . Évalué à 5.

      Merci pour le lien. Je constate du coup que j'ai des mails de seenthis dans les spam.

      « 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

  • # Politique de confiance client

    Posté par . Évalué à 1. Dernière modification le 18/04/15 à 23:16.

    En même temps, le navigateur pourrait tout aussi bien épingler par défaut les certificats serveur et alerter l'utilisateur dans le cas où le certificat a changé et qu'il n'a pas été révoqué.

    La directive includeSubDomains me semble être un brin doublon avec le champ SubjectAltName des certificats.
    Quant à la directive report-uri, elle me fait l'effet d'une issue de secours mitoyenne de la porte équipée des derniers modèles de serrure tip-top inviolable qui doit toujours être fermée.

    • [^] # Re: Politique de confiance client

      Posté par (page perso) . Évalué à 4.

      En même temps, le navigateur pourrait tout aussi bien épingler par défaut les certificats serveur et alerter l'utilisateur dans le cas où le certificat a changé et qu'il n'a pas été révoqué.

      Ce ne serait pas user-friendly, la plupart des sites changes avant la date d'expiration du certificat. Et des sites à haut trafic ont des certificats différents en fonction de la ferme de serveur sur laquelle tu tappe. Au final, ça ferrait beaucoup de faux positif pour rien.

      La directive includeSubDomains me semble être un brin doublon avec le champ SubjectAltName des certificats.

      Je ne vois pas pourquoi. Typiquement, tu peux avoir un certificat wildcard mais cnd.example.com qui utilise un tout autre certificat.

      Quant à la directive report-uri, elle me fait l'effet d'une une issue de secours mitoyenne de la porte équipée des derniers modèles de serrure tip-top inviolable qui doit toujours être fermée.

      Je ne comprend pas non plus. Typiquement, c'est ce genre de mécanisme qui a permis de détecter les dernière usurpations de Google. En plus, pour du debug c'est très bien.

      « 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: Politique de confiance client

        Posté par . Évalué à 1.

        Ce ne serait pas user-friendly, la plupart des sites changes avant la date d'expiration du certificat.

        En fait, cela n'impacterait pas, dans la mesure où je parlai de révocation et non pas d'expiration.

        Ceci étant dit, ta remarque sur les certificats différents pour chaque instance d'un même service met, effectivement, le point sur un problème. Même si je ne suis pas, a priori, convaincu de l'intérêt de ce genre de configuration.
        Tout comme je ne le suis pas d'avoir un certificat wildcard doublé d'un certificat nominatif et de manière générale : d'avoir plusieurs certificats matchant les mêmes cibles.

        Quant à la directive report-uri, elle me fait l'effet d'une une issue de secours mitoyenne de la porte équipée des derniers modèles de serrure tip-top inviolable qui doit toujours être fermée.

        Je ne comprend pas non plus. […]

        Effectivement, cela mérite précision : j'imagine un MITM qui souhaite s'interposer, sans report-uri il n'a aucun moyen de connaitre la situation du client et il a le choix de tenter d'imposer ses certificats (quitte à les annoncer avant dans un PKP) et donc de, potentiellement, lever une alerte ou d'abandonner.
        Par contre, avec la directive et l'en-tête PKP-RO, il peut demander, sans lever d'alerte, le moment précis pour lancer une attaque qui réussira.

        • [^] # Re: Politique de confiance client

          Posté par (page perso) . Évalué à 4.

          En fait, cela n'impacterait pas, dans la mesure où je parlai de révocation et non pas d'expiration.

          Et donc, pendant la période de transition vers le nouveau certif, il y a un changement de certif sans révocation, avec ta technique, une alerte sera levé pour rien. (on ne révoque pas un certif dans la seconde du changement, et on change bien avant la date)

          Par contre, avec la directive et l'en-tête PKP-RO, il peut demander, sans lever d'alerte, le moment précis pour lancer une attaque qui réussira.

          S'il arrive à ajouter une entête ou voir le trafic qui part sur une URL donnée, c'est qu'il fait déjà du MitM qui fonctionne. Donc, je ne comprends toujours pas le problème.

          « 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: Politique de confiance client

            Posté par . Évalué à 0.

            pendant la période de transition vers le nouveau certif

            Le serveur demanderai une renégociation avec le nouveau certificat après l'établissement avec l'ancien.
            Bien évidemment c'est plus lourd, mais c'est une possibilité. Il y en a peut-être d'autres.

            Quoiqu'il en soit, c'est effectivement une problématique qui donne un intérêt à ces nouveaux en-tête, ce qui est dommage car l'épinglage devrait être un choix de client non dépendant de celui du serveur quitte à être moins user-friendly.

            S'il arrive à ajouter une entête ou voir le trafic qui part sur une URL donnée, c'est qu'il fait déjà du MitM qui fonctionne.

            Quelque chose m'avait échappé : le fait que le PKP-RO doit être envoyé après l'établissement du canal sécurisé ce qui ne permet pas à l'attaquant de demander les infos.
            Du coup l'attaque nécessiterai une configuration très précise, où notamment, l'accès à la report-uri se ferait en clair et le client ne contacterai pas le serveur entre le moment du report et la date d'expiration de son épinglage.

            • [^] # Re: Politique de confiance client

              Posté par (page perso) . Évalué à 3.

              Le serveur demanderai une renégociation avec le nouveau certificat après l'établissement avec l'ancien.

              Justement, ce n'est pas comme ça que ça se passe. Pendant la période de transition, on contacte des serveurs avec l'un ou l'autre des certificats, mais pas les deux. On peut pas utiliser l'ancien.

              l'épinglage devrait être un choix de client

              Le client n'a pas suffisamment d'information pour pouvoir faire ça. Notamment, il ne connaît pas la fréquence du renouvellement des certificats.

              « 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: Politique de confiance client

                Posté par . Évalué à 0. Dernière modification le 19/04/15 à 17:12.

                Pendant la période de transition, on contacte des serveurs avec l'un ou l'autre des certificats, mais pas les deux. On peut pas utiliser l'ancien.

                En apparence, les deux phrases se contredisent ; mais je comprends ce que tu entends par là : une partie des instances présentent l'ancien une autre le nouveau.

                Si il est toujours possible de présenter l'ancien, on peux utiliser la méthode que je décris précédemment : utilisation de l'ancien certificat pendant le premier handshake puis, après l'établissement du canal sécurisé, demande de renégociation [1] en présentant un nouveau certificat.

                Par contre, la fausse alerte apparaît s'il n'est, réellement, plus possible de présenter l'ancien (typiquement par perte de la clé privée) et qu'il n'est pas encore révoqué par la CA.
                De plus, cette solution souffre du problème dont je parle précédemment puisque le serveur doit être configuré de manière à permettre l'épinglage.

                [1]: rfc5246 section-7.4.1.1 The HelloRequest message MAY be sent by the server at any time.

  • # TACK

    Posté par (page perso) . Évalué à 6.

    Le pinnage c'est très bien, ça permet de repérer assez rapidement quand quelque chose de louche se passe sur le réseau, mais c'est dommage de limiter ça à HTTP; il y a une proposition "concurrente" sous la forme de TACK, qui cette fois fournit la possibilité de pinner mais directement au niveau TLS, du coup:

    • TACK est dispo pour toutes les applications, pas seulement pour HTTP
    • Ça garde les couches bien séparées proprement. Chacun chez soi et les sessions seront bien sécurisées
    • Lorsque le certificat doit être changé légitimement (parce que la clé privée a fuité, par exemple), HPKP empêche tout accès (impossible de lire de potentiels nouveaux en-têtes HTTP puisque la couche TLS est totalement bloquée); TACK se limite à la couche TLS, et est ainsi capable de fournir les nouveaux éléments indiquant "le certificat a changé, update ton pin"

    Malheureusement c'est pas tout rose:

    • TACK est un peu plus radical et propose de se passer complètement de X.509 en signant directement les clés TLS des serveurs. Du coup ça doit être assez indigeste à déployer sur un gros domaine avec des serveurs qui doivent être changés un minimum fréquemment. En fait TACK se veut un système alternatif aux CAs [1]. Techniquement TACK pourrait être utilisé pour pinner les certificats dans la chaîne plutôt que les serveurs eux-même, mais c'est pas
    • Comme c'est niveau TLS, c'est autrement plus dur à déployer que 3 lignes dans un nginx.conf.

    "Malheureusement" au rythme où vont les choses c'est HPKP qui gagnera, et tout ce qui n'est pas HTTP se retrouvera, une fois de plus, relégué au second rang.

    [1] Pour digresser un peu, TACK a l'air de vouloir jeter le bébé avec l'eau du bain. Le système actuel d'autorités de certifications est mauvais parce que les acteurs en haut de la chaine sont mauvais, mais le reste de l'infrastructure reste quand même solide; typiquement ici, ça aurait totalement du sens de ne gérer la confiance qu'au niveau du domaine, pas au niveau de chacun des serveurs, et ça c'est déjà fourni par le système de CAs.

    • [^] # Re: TACK

      Posté par (page perso) . Évalué à 7.

      Oui, comme très souvent, ce sont les changements les moins radicaux qui réussissent le mieux.

      « 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: TACK

      Posté par (page perso) . Évalué à 1. Dernière modification le 20/04/15 à 12:14.

      Pour digresser un peu, TACK a l'air de vouloir jeter le bébé avec l'eau du bain.

      Sauf erreur de ma part, TACK n'interdit pas l'usage des CAs et surtout pas X509.

      Il stipule simplement que tu peux te passer des CAs si tu acceptes une protection "TOFU" contre les attaques man in the middle.

      HPKP est comme souvent avec Google, une solution simple(iste) mais efficace aux problèmes qui les touche plutôt qu'une tentative de résoudre le problème dans son ensemble.

      • [^] # Re: TACK

        Posté par (page perso) . Évalué à 2.

        C'est surtout que TACK ne réutilise pas les CAs en fait: est-ce que tu imagines avoir une TSK par serveur Google, y compris les CDNs un peu partout dans le monde ? (et ne me dit pas que les serveurs devraient partager leur cles TLS…). Ça resterait quand même plus simple de ne pin qu'un seul truc au niveau de Google.

        • [^] # Re: TACK

          Posté par (page perso) . Évalué à 1.

          C'est surtout que TACK ne réutilise pas les CAs en fait: est-ce que tu imagines avoir une TSK par serveur Google, y compris les CDNs un peu partout dans le monde

          Il y a aucun souci à ça.
          Tu peux utiliser une même TACK key pour signer plusieurs certificats X509.
          Etant donné que les certificats de Google/facebook sont déja signé par un CA à leur génération, rajouter une signature devrait être un jeu d'enfant.

          Le gros problème de TACK est qu'il rend l'architecture X509/CA/TLS encore plus monstrueuse, confuse et bordélique qu'elle ne l'est déja.

  • # Et DANE simplement

    Posté par . Évalué à 9.

    Il y a déjà une norme qui marche très bien, n'utilise pas les CA, est pensé pour s'assurer qu'il n'y a pas de MITM facilement :
    DANE
    On met les signatures (soit des CA, soit du certificat) correspondant au nom de domaine et protocole et port dans le DNS.
    La sécurité/confiance de la chaine est assuré par DNSSEC.

    ET voila : facile a gérer, à mettre à jour , et sur tous les protocoles.

    Cette norme comment tranquillement sa vie entre autre sur les serveurs SMTP, ou avec l'extension TLSA/DANE de firefox, qui check à la fois le DNSSEC, et les records DANE.

    Que demande le peuple ?

    • [^] # Re: Et DANE simplement

      Posté par (page perso) . Évalué à 1.

      Je me suis déjà demandé comment se déploie DNSSEC, cette fois je me suis motivé à sortir mon wikipedia adoré:

      La clé peut être récupérée via le DNS lui-même (ce qui pose un problème d'œuf et de poule) ou bien par un autre moyen (diffusée via le Web et signée avec PGP par exemple).

      et

      Contrairement à d'autres protocoles comme SSL, il ne sécurise pas juste un canal de communication mais il protège les données, les enregistrements DNS, de bout en bout.

      J'en déduis que pour chaque site que je visite il faut que je le whitelist ?

      Ça parait trop aberrant, donc ça doit être autre chose. Il a une notion de CA ?

      Et du coup il y a même problème de pining au niveau de DNSSEC, soit c'est piné par le client, soit ça utilise un CA ?
      Et comment est géré le MITM qui supprime les enregistrements DNSSEC ?
      On fait confiance au cache des DNS, donc il faut systématiquement un serveur DNS local à la machine ?

      • [^] # Re: Et DANE simplement

        Posté par (page perso) . Évalué à 4.

        On fait confiance au cache des DNS, donc il faut systématiquement un serveur DNS local à la machine ?

        Pas forcément « systématiquement », mais c’est recommandé, en effet. Au minimum, il faut que le résolveur DNS validant soit sur le réseau local, et que celui-ci soit de confiance. C’est le problème dit de la « sécurité du dernier kilomètre », qui sort du cadre de DNSSEC. Si le résolveur validant est distant, il faut un mécanisme de protection supplémentaire, comme TSIG par exemple.

        Ça parait trop aberrant, donc ça doit être autre chose. Il a une notion de CA ?
        Et du coup il y a même problème de pining au niveau de DNSSEC, soit c'est piné par le client, soit ça utilise un CA ?

        Dans le cas idéal, le résolveur validant n’a besoin d’épingler que la clef de la racine. La plupart des logiciels résolveurs la connaissent déjà (tout comme ils connaissent les adresses des serveurs de noms de la racine).

        J'en déduis que pour chaque site que je visite il faut que je le whitelist ?

        Seulement si on ne peut pas remonter jusqu’à la racine, c’est-à-dire dans le cas (non idéal) où une des zones parentes n’est pas signée.

        Par exemple, si la zone fille.example.com. est signée mais que sa zone parente example.com. ne l’est pas, il est impossible de remonter jusqu’au TLD com. (signé) et a fortiori jusqu’à la racine (dont le résolveur connaît la clef). Jusqu’à ce que le gérant de example.com. signe sa zone (et communique sa clef au gérant de com.), la seule solution pour le résolveur souhaitant valider les données de fille.example.com. est d’ajouter directement la clef de cette zone dans la liste des clefs de confiance.

        • [^] # Re: Et DANE simplement

          Posté par (page perso) . Évalué à 2.

          Du coup on transfert le problème de CA à .com en fait ?

          • [^] # Re: Et DANE simplement

            Posté par (page perso) . Évalué à 6.

            Seulement en partie, parce que Verisign (gestionnaire du .com) ne peut pas signer un certif pour un .be avec DANE alors qu'il le peut avec le modèle actuelle de TLS.

            « 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: Et DANE simplement

            Posté par (page perso) . Évalué à 3.

            Plus haut encore: on transfère le problème de CA à l'ICANN, donc au gouvernement américain.

            Tiens, voici un article bien biaisé par un expert en crypto qui soulève quelques problèmes avec DNSSEC. J'ai tendance à être d'accord avec lui, même si ça ne résout toujours pas le problème.

            • [^] # Re: Et DANE simplement

              Posté par (page perso) . Évalué à 9.

              Je ne suis pas d'accord. Bien sûr, un gouvernement peut signer n'importe quoi pour son TLD mais, c'est limité à son TLD. Avec DANE, la Chine ne peut pas signer un certif pour google.com alors qu'elle le peut (et le fait) avec l'implémentation actuelle.

              « 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: Et DANE simplement

                Posté par . Évalué à 9.

                Je ne suis pas d'accord non plus avec l'article.
                Il semble confondre beaucoup de choses et surtout se baser sur des "on dit".

                dnssec existe depuis longtemps… Son déployement à grande échelle reste récent (après les failles kaminski) et est mis à jour (dernière RFC sur des allocations d'algorithm : 2010).

                N'est pas sécurisé … Ben autant que TLS , il se basent sur les même algo. Et les clés sont modifié beaucoup beaucoup plus souvent que celles de TLS (une zsk est modifié entre 2 semaines et 1 mois, à comparer à 2 ans avec un certificat).

                Est compliqué à mettre en place… un script, un répertoire spécifique , et une clé à poussé à son registrar tous les 2 ans, c'est pas plus compliqué que la PKI/TLS.

                Est cher … à 200-400€ le certificat simple pour une pki standard, vs 0€ en dnssec le calcul est vite fait.
                Ne protège pas le "last mile" … pas plus que le TLS. Cf le besoin de clé pinning.

                DNSSEC est controlé par les gouvernements… Ni plus, ni moins que les CA, voir même plutot moins.
                Il dit que Kadhafi aurait pu utiliser son controle sur le DNSSEC… Si je ne m'abuse les certificats COMODO etc… ont été utilisé par ce même gouvernement, et on parle pas des certificats CA de l'ANSSI pour faire du MITM dans un ministère.
                (pour la petite histoire, l'ANSSI ne met pas de tls ni de dnssec sur ses sites ce qui fait qu'il est impossible d'être sur des référentiels de sécurité du gouvernement XD).
                Je ne parle pas du patriot act ou de FISA et de ses gag order(NSA inside)

                bref, pas convaincu par son argumentaire, d'autant plus qu'il oublit un problème fondamental : c'est la seule solution actuellement contre le cache poisonning qui sera de plus en plus possible avec l'augmentation des débits.

              • [^] # Re: Et DANE simplement

                Posté par (page perso) . Évalué à 0. Dernière modification le 20/04/15 à 15:53.

                Je ne suis pas d'accord. Bien sûr, un gouvernement peut signer n'importe quoi pour son TLD mais, c'est limité à son TLD. Avec DANE, la Chine ne peut pas signer un certif pour google.com alors qu'elle le peut (et le fait) avec l'implémentation actuelle.

                Donc la Chine pourra signer uniquement le .cn et les USA pourront signer la moitié du monde car ils contrôlent le .us et le 3/4 des domaines non-nationaux ( .com, .org, etc..)

                Mais comme les USA sont une nation exemplaire qui jamais, au non, jamais n'autoriseront leur agence de renseignement, la NSA, à intercepter les communications privées des gens: Tout va bien, vous pouvez dormir tranquille braves gens…

                Nan, nan je déconne: c'est la même merde.

                DANE remplace un schéma cassé par un autre. Il ne règle pas absolument pas le problème des attaques MitM en cas d'authorité corrompues.

                Il transforme juste un schéma cassé de certification à deux niveaux, en un schéma cassé de certifications à X niveaux.

                • [^] # Re: Et DANE simplement

                  Posté par (page perso) . Évalué à 6.

                  Sauf les USA contrôlent déjà pleins d'autorités de certification. Donc, ils peuvent déjà signer pour le monde entier. Là, on limite à ¾. C'est un progrès. Il ne reste plus qu'à avoir un script qui permet de vérifier que .com, le .be, le .br, le .ru et le .cn sont bien les mêmes et tu as beaucoup de chance que le contenu n'ait pas été modifié ☺.

                  Après, tu oublie un point important aussi. Cibler une machine en DNS est bien plus difficile qu'en HTTPS à cause des nombreux caches (bien sûr, si tu as la main sur l'infrastructure du FAI, c'est plus facile1). Tu risque donc que le propriétaire de la clef modifiée s'en rende compte et donc d'être bien moins discret.


                  1. si tu as la main en local, tu ajoute ton autorité ou désactive DNSSEC en fonction du cas. 

                  « 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: Et DANE simplement

                    Posté par (page perso) . Évalué à -1. Dernière modification le 20/04/15 à 16:35.

                    Sauf les USA contrôlent déjà pleins d'autorités de certification. Donc, ils peuvent déjà signer pour le monde entier. Là, on limite à ¾.

                    En pratique, tous les noms de domaines des sites à gros trafic sont en .com sous leur control, tu changes uniquement 100% par 99%. Sans parler du fait que la "racine" elle-même a besoin d'être signée

                    Il ne reste plus qu'à avoir un script qui permet de vérifier que .com, le .be, le .br, le .ru et le .cn sont bien les mêmes et tu as beaucoup de chance que le contenu n'ait pas été modifié ☺.

                    Ils n'ont pas besoin de changer l'enregistrement de .com et ton script n'y changera pas grand chose. Si ils ont la clé privée qui sert à certifier les sous-domaines de .com, alors ils peuvent très bien falsifier la résolution de google.com et tu n'y verras que du feu. Tout comme avec le système de CA actuel.

                    La seul solution à ça est de ré implémenter encore une fois le pinning, mais cette fois avec DANE, comme mentionné dans l'article originel.

                    J'ai par ailleurs de gros problème avec l'association 1-1 entre DNS et autorité de certification de DANE.
                    Je veux choisir à qui je fais confiance.
                    Avec le système actuel, je peux: je l’enlève simplement de la liste des CA de confiance de mon application.

                    Avec DNSSEC, je ne peux pas : cette autorité est liée d'office à mon nom de domaine.

                    A mon sens, les hypothétiques avantages de DNSSEC/DANE ne justifient pas sa complexité de déploiement ni les problèmes annexes qu'il génerent :

                    • Quid des portails captifs qui faussent la résolution de noms de domaine ?
                    • Quid de l'abandon de UDP pour TCP/TLS sur la latence / charge des serveurs DNS ?
                    • Quid de la transitions entre les deux ? on va encore se taper les CA pour 10 ans en parallel ?

                    Des solutions comme TACKs, certificate transparency, ou convergence sont bien plus prometteuse que DANE à mon humble avis.

                    • [^] # Re: Et DANE simplement

                      Posté par (page perso) . Évalué à 5.

                      Je veux choisir à qui je fais confiance.

                      Et pour la majorité des utilisateurs. On fait quoi ? Parce que pour eux, il en suffit d'une pour foutre la merde partout.

                      Ils n'ont pas besoin de changer l'enregistrement de .com et ton script n'y changera pas grand chose. Si ils ont la clé privée qui sert à certifier les sous-domaines de .com, alors ils peuvent très bien falsifier la résolution de google.com

                      Sans que ça ce voit, c'est bien plus dur, vu que dans la plupart des cas, tu auras plusieurs personnes impactées. D'ailleurs, ce n'est pas que la résolution de google.com, c'est aussi la clef publique.

                      Quid des portails captifs qui faussent la résolution de noms de domaine ?

                      Ils posent déjà problème avec le HTTPS (accentué par HSTS), l'utilisateur voit un gros warning quand il essaye de se connecté à ses sites préférés.

                      Des solutions comme TACKs, certificate transparency

                      Des trucs comme certificate transparency seraient bien, malheureusement les CA n'ont pas l'air de se bouger. Peut-être que si leur business se voit menacé par DANE, elles s'y mettront.

                      « 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: Et DANE simplement

                        Posté par (page perso) . Évalué à 1. Dernière modification le 20/04/15 à 21:23.

                        Et pour la majorité des utilisateurs. On fait quoi ? Parce que pour eux, il en suffit d'une pour foutre la merde partout.

                        On implémente le pinning proprement au niveau de TLS ? Et on mets en place le certificate transparency sur le long terme ?

                        Des trucs comme certificate transparency seraient bien, malheureusement les CA n'ont pas l'air de se bouger. Peut-être que si leur business se voit menacé par DANE, elles s'y mettront.

                        Tu es très optimiste.

                        Admettons que IE, Opera, Chrome, Safari et Firefox se décident d'implémenter DANE et de l'activer par défaut disons….la semaine prochaine.
                        Admettons que les infrastructures DNS de TOUS les FAI (même ceux du boudjikistan), les réseaux d'entreprises et TOUS les opérateurs mobiles se décident à forwarder correctement DNSSEC et DANE (ce qui est déjà hautement improbable, ça prendrait des années).

                        Tout comme IE6 ont pourrit la vie des devs Web pendant 10 ans, tu vas forcément continuer à avoir des utilisateurs sous IE9 ou Android 2.3 qui ne géreront pas correctement DANE pendant des années et des années. Donc rien que pour ceux là, tu devras aussi faire signer ton certificat par une autorité de certification et rentrer dans le business juteux des CAs qui continueroent de vivre paisiblement.

                        DANE/DNSSEC n'est pas en soit un mauvais standard. Mais c'est un standard qui arrive bien trop tard, quand le système de CA est déja le centre du monde et presque impossible à déloger.

                        • [^] # Re: Et DANE simplement

                          Posté par (page perso) . Évalué à 5.

                          On implémente le pinning proprement au niveau de TLS ? Et on mets en place le certificate transparency sur le long terme ?

                          Pourquoi pas ? Implémenter DNSSEC/DANE n’interdit pas les autres méthodes. Personne n’a jamais dit que DANE devait être le seul moyen d’authentifier un serveur TLS.

                          Tout comme IE6 ont pourrit la vie des devs Web pendant 10 ans, tu vas forcément continuer à avoir des utilisateurs sous IE9 ou Android 2.3 qui ne géreront pas correctement DANE pendant des années et des années.

                          Avec cet argument là, autant ne rien faire du tout…

                          Donc rien que pour ceux là, tu devras aussi faire signer ton certificat par une autorité de certification et rentrer dans le business juteux des CAs qui continueroent de vivre paisiblement.

                          Encore une fois, DANE n’a pas la prétention de remplacer d’un coup tout le reste. Au contraire, DANE prévoit explicitement la possibilité d’être utilisé en complément du système PKIX. Ceux qui le souhaitent peuvent utiliser DANE exclusivement (sélecteur TLSA sur DANE-TA ou DANE-EE), mais ce n’est pas une obligation.

                          Au passage, Certificate Transparency est beaucoup moins flexible sur ce plan, puisqu’il interdit explicitement tout certificat qui n’aurait pas été émis par le cartel des CA.

                          • [^] # Re: Et DANE simplement

                            Posté par (page perso) . Évalué à 1.

                            Pourquoi pas ? Implémenter DNSSEC/DANE n’interdit pas les autres méthodes. Personne n’a jamais dit que DANE devait être le seul moyen d’authentifier un serveur TLS.

                            Bien, comme ça au lieu d'avoir une surface d'attaque pour faire du MitM, on en aura deux.

                            Avec cet argument là, autant ne rien faire du tout…

                            Non, on fait simplement des choses avec des étapes de transitions raisonnables.

                            Au passage, Certificate Transparency est beaucoup moins flexible sur ce plan, puisqu’il interdit explicitement tout certificat qui n’aurait pas été émis par le cartel des CA.

                            Il n'a jamais été designé pour les remplacer, uniquement corriger leur problèmes: ce qui est le plus urgent à faire.

                            Je n'aime pas plus les certificate authority que vous: elles coûtent cher, ont un monopole honteux, une éthiques douteuses pour certaines d'entre elles. Je les verrai avec joie disparaitre.

                            Mais deployer DANE est juste remplacer un monstre par un autre qui ne corrige pas les problèmes du précédents et qui apporte son propre lot d'emmerdes. Le seul avantage de DANE est la réduction des couts pour les particuliers: plus besoin de payer le CA.

                            Un internet sans CA viendra bien plus probablement de choses comme :
                            - convergence, qui introduit le concept de notaries
                            - monkey-sphere, qui veut authoriser les signatures multiples et donc le création d'un Web-of-trust avec SSL
                            - namecoin, qui autorise la publication irrévocable via blockchain du fingerprint de tout certificat.
                            - TACKs, qui permet de faire du Trust-On-First-Use avec TLS/SSL.

                            Maintenant vous pouvez moinsé.

                            • [^] # Re: Et DANE simplement

                              Posté par (page perso) . Évalué à 5.

                              Non, on fait simplement des choses avec des étapes de transitions raisonnables.

                              Tu as ton certificat traditionnel émis par une CA reconnue qui autorise les visiteurs à consulter ton site sans avertissements (mais sans sécurité non plus, merci le modèle PKIX…), en quoi est-il déraisonnable d’épingler ce certificat dans un enregistrement TLSA ? Tu ne perturbes en rien le fonctionnement des navigateurs qui ne connaissent pas DANE.

                              Il n'a jamais été designé pour les remplacer, uniquement corriger leur problèmes: ce qui est le plus urgent à faire.

                              Certificate Transparency corrige quoi au juste ?

                              Autant le dire : Certificate Transparency ne sert à rien, et surtout pas à « corriger les problèmes des CA ».

                              L’objectif de Certificate Transparency est de pouvoir détecter quand une « rogue CA » émet un certificat illégitime. Quand tous les navigateurs exigeront que les certificats soient affublés d’un ou plusieurs SCT pour être acceptés, une CA ne pourra pas émettre de certificats sans l’enregistrer dans les logs de Certificate Transparency (nécessaire pour obtenir le SCT), ce qui permettra à tout le monde de découvrir ce certificat illégitime.

                              Et après ? Ben rien. Certificate Transparency ne dit absolument rien quand à ce qui doit se passer ensuite. La vision bisounours est que les éditeurs de navigateurs, en constatant que la CA a émis des certificats frauduleux, prendront immédiatement la décision qui s’impose, à savoir virer la CA indélicate de leurs magasins d’autorité de confiance.

                              C’est tellement naïf que je ne peux pas imaginer une seule seconde que les promoteurs de Certificate Transparency y croient réellement.

                              On n’a jamais viré sans ménagements une CA des magasins des navigateurs. Quand une CA indélicate est prise la main dans le sac, on s’indigne, on crie (surtout si la CA est chinoise, beaucoup moins si elle est américaine…), mais on tergiverse beaucoup et au final on ne fait pas grand’chose.

                              (De toute façon une action en suppression immédiate et inconditionnelle au moindre certificat émis en doublon ne serait pas mieux : il peut y avoir des raisons légitimes pour qu’une CA émette un certificat pour un domaine qui en a déjà un ailleurs… par exemple pour fournir le backup pin requis par HPKP.)

                              La seule raison d’être de Certificate Transparency est d’asseoir un peu plus le cartel des CA, en exigeant :

                              • de la part des navigateurs, qu’un certificat possède un ou plusieurs SCT pour être accepté ;

                              • de la part des journaux Certificate Transparency, qu’un certificat soit émis par une CA reconnue pour l’enregistrer et lui donner son SCT (en particulier, les certificats auto-signés sont explicitement exclus).

                              Et je ne parle pas du bordel que représente l’implémentation de Certificate Transparency, qui demande des modifications à peu près à tous les niveaux.

                              Je n'aime pas plus les certificate authority que vous: elles coûtent cher, ont un monopole honteux, une éthiques douteuses pour certaines d'entre elles. Je les verrai avec joie disparaitre.

                              Certificate Transparency est justement conçu pour s’assurer qu’elles ne disparaissent pas.

                              Un internet sans CA viendra bien plus probablement de choses comme :

                              Toutes ces méthodes sont intéressantes et la meilleure solution est à mon avis de permettre d’utiliser toutes ces méthodes selon ses besoins et convenances, plutôt que de vouloir absolument une méthode unique. DANE est une des méthodes possibles. Encore une fois, personne n’a prétendu que ça devait être la seule. Contrairement aux CA, qui ont pris soin de se rendre indispensable.

                              • [^] # Re: Et DANE simplement

                                Posté par (page perso) . Évalué à 1.

                                Merci pour ta réponse, j'aime particulièrement ton point de vue sur CA transparency.

                                Juste quelques points :

                                en quoi est-il déraisonnable d’épingler ce certificat dans un enregistrement TLSA ?

                                Parce que ça force l'infrastructure et l'intégralité des clients à supporter le bousin ?
                                TLSA tout seul sans DNSSEC est inutile.
                                Et DNSSEC est un monstre à déployer et supporter. Un monstre qui actuellement n'est supporter par personne, ni coté client, ni coté serveur.

                                Je suis actuellement dans une organisation de 15000 personnes où ni DNSSEC ni DANE ne peut pas marcher, et ne marchera sûrement jamais. Simplement parce que les requètes DNS sont filtrées, comme dans beaucoup d'environnement pro.

                                Certificate Transparency corrige quoi au juste ?

                                Autant le dire : Certificate Transparency ne sert à rien, et surtout pas à « corriger les problèmes des CA ».

                                L'idée derrière Certificate Transparency est de créer une base publique de tous les certificats émis existants.

                                Si l'utiliser pour détecter les conneries des CA peut être un premier cas d'utilisation évident.
                                L'idée sur le long terme est de pouvoir "pinner" dynamiquement chaque certificat sur ces databases, et ça çareglerait pas mal de problèmes.

                                Certificate Transparency est justement conçu pour s’assurer qu’elles ne disparaissent pas.

                                Ça l'est. Et je n'ai jamais dit que j'aimais particulièrement cette solution. cf mon commentaires précédents sur les alternatives.

                                C'est DANE/DNSSEC que je n'aime pas pour tout un tas de raisons evidentes expliquées plus haut.

                                Toutes ces méthodes sont intéressantes et la meilleure solution est à mon avis de permettre d’utiliser toutes ces méthodes selon ses besoins et convenances, plutôt que de vouloir absolument une méthode unique. DANE est une des méthodes possibles. Encore une fois, personne n’a prétendu que ça devait être la seule. Contrairement aux CA, qui ont pris soin de se rendre indispensable.

                                Nous sommes d'accord.
                                ```

                                • [^] # Re: Et DANE simplement

                                  Posté par . Évalué à 3.

                                  Et DNSSEC est un monstre à déployer et supporter. Un monstre qui actuellement n'est supporter par personne, ni coté client, ni coté serveur.

                                  Euh… tu parles en connaissance de cause ou juste ce que tu crois?

                                  En connaissance de cause, parce que j'ai mon domaine perso avec dnssec.
                                  C'est tellement compliqué à déployer que j'ai mis plus de temps à configurer exim et dovecot au petit oignons comme je le voulais que dnssec.
                                  Tellement compliqué à administrer que cela me demande 1 à 2j tous les 2ans (la KSK rollover), et est absolument transparent pour tous les workflow existant.

                                  Aucun serveur ni client ne le supporte … Juste bind, qui est le serveur dns de référence.
                                  Bind supporte même maintenant la gestion automatique des clés. Mais ca doit être parce que c'est trop compliqué …

                                  Bon si un admin esseulé peut le faire tranquillement dans son coin sur sa machine perso, je doute qu'on puisse expliquer que c'est une usine à gaz (comme un MS exchange par ex…)

                                  Je suis actuellement dans une organisation de 15000 personnes où ni DNSSEC ni DANE ne peut pas marcher, et ne marchera sûrement jamais. Simplement parce que les requètes DNS sont filtrées, comme dans beaucoup d'environnement pro.

                                  Euh dans très peu d'organisation pro on filtre les dns.
                                  On gère les résolveurs suivant les zones. Mais on ne filtre (comprendre autoriser certains records et pas d'autres) pas les DNS.
                                  C'est une mauvaise pratique.

                                  Si on veut jouer à celui qui a la plus grosse. Certaines organisations bien plus grosses (d'un ou deux ordres de magnitudes) commencent à utiliser dnssec sur une partie de leur infrastructure. Je présume que c'est parce qu'elles n'y connaissent rien ?

                                • [^] # Re: Et DANE simplement

                                  Posté par (page perso) . Évalué à 4.

                                  Parce que ça force l'infrastructure et l'intégralité des clients à supporter le bousin ?

                                  DANE est une des méthodes les moins intrusives (beaucoup moins que CT). Tout est déjà en place pour la supporter. Tous les serveurs et résolveurs DNS dignes de ce nom supportent déjà DNSSEC (et DANE n’a pas besoin d’être explicitement pris en charge, les enregistrements TLSA ne sont que des enregistrements DNS comme les autres). Aucun protocole n’a besoin d’être modifié. Tout ce qu’il manque est le support des navigateurs.

                                  Et DNSSEC est un monstre à déployer et supporter. Un monstre qui actuellement n'est supporter par personne, ni coté client, ni coté serveur.

                                  Ça c’est complètement faux. Côté serveurs, je le répète, tous les serveurs DNS dignes de ce nom gèrent DNSSEC. Côté client, ce n’est pas parce que les navigateurs regardent ailleurs que personne d’autre n’est intéressé. DNSSEC a bien d’autres intérêts au-delà du seul web.

                                  Les serveurs de courrier électronique y ont un intérêt pour chiffrer les communications SMTP de serveur à serveur (en utilisant DANE pour authentifier le pair d’en face, et donc faire un peu mieux que du chiffrement à l’aveugle sans savoir à qui on parle). Les clients SSH y ont un intérêt pour authentifier les serveurs SSH (enregistrements SSHFP, seulement fiables si on est sûr que l’enregistrement n’est pas frauduleux).

                                  Je ne dis pas que DNSSEC n’est pas monstrueux. Personne ne peut lire le RFC décrivant NSEC3 et ne pas penser que c’est une monstrueuse usine à gaz. Mais d’une part, ce n’est pas plus une usine à gaz que bien d’autres protocoles que l’on utilise sans même y penser (dont, au passage, X.509 et TLS, dont la complexité effare bien des experts en sécurité), et d’autre part, c’est complètement déployable et même déployé.

                                  Simplement parce que les requètes DNS sont filtrées, comme dans beaucoup d'environnement pro.

                                  C’est du même niveau que les magouilles consistant à fabriquer des faux certificats à la volée. Que DNSSEC contrarie ce genre d’agissements est une feature, pas un bug. Les responsables « d’environnements pro » qui veulent contrôler le moindre traffic de leurs utilisateurs devront le faire de manière ouverte et assumée, pas dans le dos des utilisateurs.

                                  L'idée sur le long terme est de pouvoir "pinner" dynamiquement chaque certificat sur ces databases, et ça çareglerait pas mal de problèmes.

                                  Lesquels, et comment ? Par ailleurs, rien dans la description de CT ne laisse transparaître une telle « idée sur le long terme ».

                              • [^] # Re: Et DANE simplement

                                Posté par (page perso) . Évalué à 4.

                                On n’a jamais viré sans ménagements une CA des magasins des navigateurs.

                                Ah bah si justement: CNNIC a été supprimé du magasin Chrome et du magasin Firefox, a peine 1 semaine après les faits. Après je suis a peu près sur qu'une racine américaine n'aurait jamais été enlevé aussi vite.

                              • [^] # Re: Et DANE simplement

                                Posté par (page perso) . Évalué à 2.

                                Certificate Transparency ne sert à rien

                                Je corrige mon propos, Certificate Transparency pourrait être utile dans un cas : celui des magouilles du genre Superfish, où un logiciel malveillant ajoute son propre certificat au magasin du système et s’en sert pour forger des faux certificats à la volée. Les faux certificats ne pourraient pas obtenir de SCT et seraient donc refusés.

                                Cette technique étant assez répandue (outre le cas emblématique de Lenovo, elle est semble-t-il courante en entreprise, pour déchiffrer le traffic des employés), c’est un cas d’utilisation non-négligeable.

                                Néanmoins :

                                • D’une part, CT n’est pas la seule technique potentiellement efficace contre cette attaque (DANE, Convergence, Monkeysphere, éventuellement le pinning si la première connexion au site se fait avant l’installation du malware, …).

                                • D’autre part, en fait aucune technique ne peut être réellement efficace contre cette attaque (CT pas plus que les autres), puisque qu’elle part du principe que l’attaquant a la main-mise sur la machine du client (via un malware, ou si l’attaquant est l’administrateur de l’entreprise). C’est une conclusion établie en matière de sécurité qu’il n’y a pas de sécurité qui tienne la route si la machine terminale est compromise. Les nouveaux Superfish en puissance pourront toujours s’adapter pour contourner n’importe laquelle des méthodes envisagées ici (CT ? On désactive la vérification des jetons SCT. DANE ? On falsifie les réponses DNS — rappelez-vous que DNSSEC ne sécurise pas le dernier kilomètre et suppose que le résolveur validant est de confiance. Convergence ? Je n’ai pas assez étudié le principe, mais je ne doute aucunement qu’un contournement soit possible, peut-être en manipulant la liste des notaries. Etc, etc).

    • [^] # Re: Et DANE simplement

      Posté par . Évalué à 2. Dernière modification le 20/04/15 à 09:18.

      Que demande le peuple ?

      Être implémenté quelque part ?

    • [^] # Re: Et DANE simplement

      Posté par (page perso) . Évalué à 3.

      On parle du Web, là, qui est quelque chose de complètement fossilisé. Les éditeurs de navigateurs Web ne sont pas assez aventureux et réactifs pour implémenter un truc pareil avant vingt ans, je dirais.

  • # Configuration du serveur web et anticipation du changement d'autorité

    Posté par (page perso) . Évalué à 3.

    Des exemples de configuration Lighttpd, Apache httpd et Nginx sur https://raymii.org/s/articles/HTTP_Public_Key_Pinning_Extension_HPKP.html

    À voir ces exemples, j'en déduis que le max-age n'est pas géré dynamiquement à l'approche de l'expiration du certificat : si on a pris par exemple la valeur suggérée par la RFC de 60 jours pour le max-age, pendant les deux mois précédant l'expiration du certificat, on continue à annoncer un épinglage sur 60 jours. Le jour de l'expiration :

    • soit on n'a rien fait, le certificat est invalide et le client ne se posera même pas la question de l'épinglage
    • soit le certificat a été renouvelé (y compris en avance pendant les 60j avant l'expiration) et dans ce cas là tout dépend du fait que l'on ait changé ou non d'autorité de certification :
      • si on a gardé la même autorité que celle précédemment annoncée dans l'épinglage, tout va bien se passer
      • si on a changé d'autorité, alors le client va râler sur l'épinglage.

    Bref ça nécessite d'anticiper un peu les changements d'autorité.

Suivre le flux des commentaires

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