Journal Auto-hébergement et sécurisation des accès via HTTPS

Posté par  . Licence CC By‑SA.
Étiquettes :
19
7
nov.
2013

On parle beaucoup d'auto-hébergement par ici et un sujet n'a pas été abordé suffisament à mon sens : la sécurisation des accès à ses services auto-hébergés via HTTPS.

A quoi bon reprendre ses billes (carnet d'adresse, agenda, emails, fichiers, etc.) aux géants du cloud NSA-compatibles, si c'est pour tout faire transiter en clair (mots de passe, contenus)  ?

J'ai posé quelques questions sur le forum (http://linuxfr.org/forums/general-general/posts/self-hosting-et-https ) et continué mes recherches.

Voici une synthèse non exhaustive des possibilités simples et pas cher qui s'offrent à nous :

Pour ceux qui ont la main sur leur serveur

Concerne les serveurs hébergés à la maison, serveurs hébergés ou serveurs privés virtuels.

1) utiliser des certificats auto-signés
  • Avantages : il est facile et gratuit de générer soi-même un certificat grâce à OpenSSH
  • Contraintes : il faut communiquer la clef privée par un canal sécurisé à chacun des utilisateurs des services hébergés et effectuer un paramétrage spécifique sur chaque application qui va se connecter au serveur
  • Usages propices : accès depuis des machines spécifiquement paramétrées (ex: client SSH, navigateur éduqué pour reconnaître le certificat, etc.)
2) utiliser un certificat de chez startssl.com
  • Avantages : demander un certificat ou son renouvellement est facile et gratuit. Le certificat sera reconnu par la plupart des clients "out of the box" (99% des navigateurs, etc.)
  • Contraintes : le certificat ne marchera que pour 1 seul domaine (il faut générer autant de certificat que de sous-domaines)
  • Usages propices : hébergement d'applications web ou de services *DAV (synchro de carnet d'adresses via CardDAV, d'agenda via CalDAV, etc.)

Pour ceux qui utilisent un hébergement mutualisé

1) utiliser un service de SSL mutualisé

C'est ce que propose par exemple OVH. Le principe : au lieu d'aller sur https://www.monsite.com, il faut aller sur https://ssl10.ovh.net/~monsite

  • Avantages : c'est gratuit et ne demande aucun effort; le certificat est reconnu par la plupart des clients "out of the box" (99% des navigateurs)
  • Contraintes : il faut utiliser des URL un peu momoches
  • Usages propices : hébergement de services de type OwnCloud ou de CMS/Wikis destinés à une population restreinte
  • Qui le propose ? : OVH , Claranet, Host Gator et d'autres aussi ?
2) souscrire à l'option "certificat SSL"
  • Avantages : c'est assez rapide et le certificat est reconnu par la plupart des clients "out of the box" (99% des navigateurs)
  • Contraintes : c'est payant et les prix augmentent si on veut aussi sécuriser ses sous-domaines
  • Usages propices : hébergement de services de type OwnCloud et/ou de tout site avec authentification accessible à un large public
  • Qui le propose : Gandi est le moins cher à 12€HT/an, la plupart des hébergeurs proposent la même chose à environ 60€/an, un peu moins chez chez les américains; les certificats wildcard (valides pour les sous-domaines) coûtent beaucoup plus cher.

  • # CACert

    Posté par  (site web personnel) . Évalué à 7. Dernière modification le 07 novembre 2013 à 14:29.

    Bien présent dans les distribs linux, mais pas du tout ailleur, mais on peux générer des certificats wildcard pour tous les sous-domaines de niveau inférieur !

  • # CAcert

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

    Tu as oublié de mentionner CAcert. Je complète donc.

    utiliser un certificat de chez CAcert

    • Avantages : demander un certificat ou son renouvellement est facile et gratuit.
    • Contraintes : les utilisateurs doivent récupérer le certificat racine de CAcert par un canal sécurisé, par exemple en installant le paquet Debian ca-certificates puis en important le certificat en question dans leur navigateur depuis leur système de fichier. À noter que même si ce n'est pas automatique, c'est déjà plus sérieux que d'accepter aveuglément un certificat auto-signé.
    • Usage propices : hébergements de services avec volonté libriste ou sécuritaire ou rejet des autorités de certification commerciales.

    On peut également mentionner le fait que la vérification d'identité par les membres de la communauté CAcert est nettement plus sérieuse que celle qu'effectuent les autorités de certification commerciales, dont l'intérêt est en fait de ne rien vérifier du tout pour éviter de devoir refuser des ventes. Mais cet avantage concerne le (mauvais) système X.509 en général et non les utilisateurs.

    • [^] # Re: CAcert

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

      Contraintes : les utilisateurs doivent récupérer le certificat racine de CAcert par un canal sécurisé,

      Ca ressemble fortement au cas 1 cette histoire…

      On peut également mentionner le fait que la vérification d'identité par les membres de la communauté CAcert est nettement plus sérieuse que celle qu'effectuent les autorités de certification commerciales,

      Tellement sérieux que CACert n'ose pas se soumettre à un audit de leur sérieux par Mozilla, que CetnOS et Ubuntu rejettent ce certificat (pour parler du libre)…

      • [^] # Re: CAcert

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

        Ca ressemble fortement au cas 1 cette histoire…

        En un peu plus sérieux.

        • [^] # Re: CAcert

          Posté par  . Évalué à 9.

          Comment qualifierais-tu les avantages d'un certificat CAcert par rapport à l'auto-signé d'un point de vue pratico-pratique ?

          BeOS le faisait il y a 20 ans !

    • [^] # Re: CAcert

      Posté par  . Évalué à 5.

      Je l'avais écarté à dessein ;)

      D'un point de vue purement pragmatique, un certificat CAcert est aussi utile pour les usages d'auto-hébergement vu qu'il faut faire une manipulation technique pour le faire reconnaître à une machine.

      Ça a l'air facile sous Debian, qu'en est-il sur un poste Windows, un Mac, un smartphone, une tablette ?

      BeOS le faisait il y a 20 ans !

      • [^] # Re: CAcert

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

        Je l'avais écarté à dessein ;)

        Je ne comprends pas la raison. Autant écarter l'auto-signé dans ce cas.

        D'un point de vue purement pragmatique, un certificat CAcert est aussi utile pour les usages d'auto-hébergement vu qu'il faut faire une manipulation technique pour le faire reconnaître à une machine.

        Pas compris.

        Ça a l'air facile sous Debian, qu'en est-il sur un poste Windows, un Mac, un smartphone, une tablette ?

        Aller sur le site de CAcert, installer le certificat racine, sans garantie sur son intégrité.

    • [^] # Re: CAcert

      Posté par  . Évalué à 4.

      Valide 6 mois pour le niveau le plus bas …

      Par contre j'ai vraiment du mal a comprendre pourquoi il faut absolument vérifier la véracité de l'identité de la personne. Pourquoi ne pas simplement se borner a vérifier que l'on est bien le locataire/gérant du nom de domaine ?
      C'est une vrai question pas un troll

      • [^] # Re: CAcert

        Posté par  (site web personnel) . Évalué à 3. Dernière modification le 08 novembre 2013 à 00:15.

        Par contre j'ai vraiment du mal a comprendre pourquoi il faut absolument vérifier la véracité de l'identité de la personne. Pourquoi ne pas simplement se borner a vérifier que l'on est bien le locataire/gérant du nom de domaine ?

        C'est la seule chose qui est vérifiée pour les certificats de six mois. Et je suis d'accord, il n'y a pas de raison de vérifier l'identité, à moins de la mettre dans le certificat, ce qui n'est pas fait aujourd'hui. C'est d'ailleurs une absurdité du modèle actuel : quand tu vas sur le site de ta banque, ou que tu consultes ton courrier, tu te moques du nom de domaine, ce qui t'intéresse, c'est en réalité l'identité de la personne qui possède les serveurs auxquels tu te connectes.

        • [^] # Re: CAcert

          Posté par  (Mastodon) . Évalué à 2.

          Et je suis d'accord, il n'y a pas de raison de vérifier l'identité, à moins de la mettre dans le certificat, ce qui n'est pas fait aujourd'hui.

          C'est fait pour les certificats EV (extended validation), qui sont signalés par les navigateurs (passage en vert de la barre d'adresse, par exemple). Pour obtenir un tel certificat, il y a bien une vérification de l'identité du demandeur (alors qu'effectivement, pour un certificat normal, on vérifie au mieux que le demandeur possède bien le nom de domaine)

          Par exemple, si je vais sur le site de ma banque (https://www.postfinance.ch/), en 1 click je peux voir que le certificat a été fourni à l'entreprise Postfinance AG, à Berne, en Suisse.

          • [^] # Re: CAcert

            Posté par  (site web personnel) . Évalué à 2. Dernière modification le 08 novembre 2013 à 13:33.

            C'est fait pour les certificats EV (extended validation)

            Pas besoin d'EV. On peut mettre son nom comme CN du sujet du certificat, et les noms de domaines comme subjectAltName. La convention, universelle et seule prise en charge partout, de mettre le nom de domaine en CN est une aberration.

            • [^] # Re: CAcert

              Posté par  . Évalué à 4.

              On peut mettre son nom comme CN du sujet du certificat, et les noms de domaines comme subjectAltName. La convention, universelle et seule prise en charge partout, de mettre le nom de domaine en CN est une aberration.

              Oui, donc on peut mais on peut pas.

              • [^] # Re: CAcert

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

                Euh, je me suis très mal exprimé. Aujourd'hui, on peut sans problème mettre son nom en CN, et les noms de domaine en subjectAltName. Ce sera pris en charge sur tous les logiciels, sauf les antiquités telles que Windows XP.

                En revanche, ce n'est pas ce qui se fait habituellement, qui consiste à mettre un nom de domaine dans le CN. C'est une pratique issue d'une contrainte historique — un seul nom par certificat —, pratique tout à fait aberrante.

        • [^] # Re: CAcert

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

          quand tu vas sur le site de ta banque, ou que tu consultes ton courrier, tu te moques du nom de domaine,

          Le nom de domaine ayant été fourni par la banque, le lien est OK (c'est toi qui le tape! donc c'est bien ce lien entre proprio du domaine et le serveur atteint qui compte le plus), vérifier que le tu es bien sur le serveur de proprio du nom de domaine suffit pour une bonne relation de confiance.

          Mais en fait :

          c'est en réalité l'identité de la personne qui possède les serveurs auxquels tu te connectes.

          Les certificats étendus (EV) font justement ça, pour encore plus de confiance (il faut continuer à avoir confiance dans les organismes de certifications, tous, certes, ça ne change pas ça)
          Pour les grosses banques en France, SG, LCL, BNP ne le font certes pas (la honte pour des banques), mais CIC le fait, pour ce que j'ai vérifié vite fait.

          • [^] # Re: CAcert

            Posté par  . Évalué à 5.

            avoir confiance dans les organismes de certifications, tous

            Ce qui rend un peu vain tout effort qui n'irait pas s'occuper de ce problème-là. DANE est une piste intéressante.

            Peut-être qu'au final, on prend le problème à l'envers, et que c'est aux navigateurs (ou à leurs utilisateurs, s'ils ne jouent pas le jeu) de faire le ménage dans leurs CAs.

  • # Mixer les méthodes ?

    Posté par  . Évalué à 9.

    1) Créer sa CA personnelle avec OpenSSL

    2) Distribuer le certificat racine de notre CA via un site en https en utilisant un certificat généré chez une CA qui ne provoque pas d'avertissement de sécurité dans les navigateurs.

    3) Générer à l'aide de notre CA les certificats dont on a besoin

    • [^] # Re: Mixer les méthodes ?

      Posté par  . Évalué à 3.

      Pour un usage individuel, est-ce que ça a un avantage par rapport à un certificat autosigné ?

      BeOS le faisait il y a 20 ans !

      • [^] # Re: Mixer les méthodes ?

        Posté par  (site web personnel) . Évalué à 1. Dernière modification le 07 novembre 2013 à 14:58.

        Édit : non rien (j'avais mis un commentaire qui n'était pas pertinent parce que répondant à aurte chose en fait).

      • [^] # Re: Mixer les méthodes ?

        Posté par  . Évalué à 2.

        En toute logique, à moins d'être totalement bipolaire, tu dois pouvoir assez facilement faire confiance à un certificat que tu t'es auto-signé sans avoir à recourir à une autorité "de confiance" tierce :)

        • [^] # Re: Mixer les méthodes ?

          Posté par  . Évalué à 2.

          En important le certificat de ta propre CA dans tes logiciels, tu n'as pas le message d'alerte à la première connexion alors que tu l'as avec un certificat auto-signé.

          C'est la solution que j'utilise. La CA sert aussi au serveur SMTP, IMAP, XMPP, etc.

  • # Auto-signé

    Posté par  . Évalué à 6.

    Quitte à s'auto-signer, ça peut valoir le coup de mettre en place le schéma suivant :

    • une CA, à très longue durée de vie, dont la clé privée est rangée très soigneusement.
    • des certificats signés par cette CA, déployés sur les serveurs.
    • la clé publique de la CA est à faire accepter par les utilisateurs, plutôt que chaque certificat individuellement.

    Inconvénient : on demande une plus grande confiance de la part des utilisateurs (on peut potentiellement signer un certificat au nom de google.com sans qu'ils s'en rendent compte).

    Avantage : c'est nettement plus souple qu'un simple certificat (final) auto-signé, on peut déployer une chiée de services, renouveler un certificat, etc… sans rien modifier sur les postes clients.

    Conclusion : à réserver à des usages restreints à une communauté qui se fait confiance (entreprise, cercle familial, etc.).

  • # SSL mutualisé, c'est vraiment sécurisé ?

    Posté par  . Évalué à 3. Dernière modification le 07 novembre 2013 à 15:10.

    Si on utilise un service SSL mutualisé, ça veut donc dire qu'on ne maitrise pas la clé privée.

    Du coup OVH (ou autre) peut très bien l'avoir communiquée à diverses organismes (gouvernementaux ou pas), non ? Ou alors j'ai loupé quelque chose.

    • [^] # Re: SSL mutualisé, c'est vraiment sécurisé ?

      Posté par  . Évalué à 2.

      C'est un autre débat : la confiance dans un prestataire d'hébergement.
      Le sujet a été largement débattu sur LinuxFr, laissons chacun faire son choix :)

      D'un point de vue pragmatique, le SSL mutualisé permet de s'assurer qu'on parle bien au bon serveur et que les échanges seront chiffrés.
      Donc oui, c'est vraiment sécurisant.

      BeOS le faisait il y a 20 ans !

    • [^] # Re: SSL mutualisé, c'est vraiment sécurisé ?

      Posté par  . Évalué à 2.

      Même sur un dédié, tu ne maitrises pas la clef privée puisque tu ne maitrises pas l'accès physique à la machine.

      • [^] # Re: SSL mutualisé, c'est vraiment sécurisé ?

        Posté par  . Évalué à 1.

        sauf si tu chiffres tous tes disques

        • [^] # Re: SSL mutualisé, c'est vraiment sécurisé ?

          Posté par  . Évalué à 1.

          Non, ça ne sert a rien de chiffrer les disques d'un dédié: la clef doit être stockée en clair, ou tu dois la transmettre en clair par reseau à chaque boot.
          De toute façon, les machines utilisées pour faire serveur ont probablement la possibilité de faire des snapshot de la ram à chaud via une interface d'administration…

          • [^] # Re: SSL mutualisé, c'est vraiment sécurisé ?

            Posté par  . Évalué à 3.

            bah non: debian (et certainement d'autres) te permet d'installer un initrd avec un dropbear pour envoyer ta passphrase par ssh avant de continuer le démarrage de ta machine

            pour le snapshot de ta ram à chaud, je ne suis pas assez renseigné pour t'opposer quoique ce soit.

  • # Attention quand même.

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

    SSL/TLS c'est bien, mais ce n'est pas suffisant. Il faut aussi être très attentif à toute la chaine de chiffrement (hash, algos, clés, protocoles…)
    Il y a pas mal d'attaques Mitm sur SSL et là on est pas dans le monde badbios.
    Cf. Beast, Crime, Lucky13 etc. Voir à ce sujet http://www.isg.rhul.ac.uk/tls/
    Bref il faut savoir correctement paramétrer son serveur en conséquence.
    Pour Apache par ex:

    SSLProtocol -ALL +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:HIGH:!MD5:!aNULL:!EDH:!RC4
SSLCompression off

    Cependant n'appliquez aucune recette sans comprendre exactement ce que vous faites; ie. ne faites pas un bête c/c de ce que j'ai mis ci-dessus. D'autant plus si vous utilisez aussi SSL pour d'autres protocoles que le http (smtp/imap par ex).

    En vrac qq liens utiles pour avancer:

    Une petite feuille d'aide à propos de TLS:
    https://www.owasp.org/index.php?title=Transport_Layer_Protection_Cheat_Sheet

    Les recommandations de Mozilla:
    https://wiki.mozilla.org/Security/Server_Side_TLS

    L'avis d'un monsieur qui sait de quoi il parle (Peter Gutmann)
    http://www.cs.auckland.ac.nz/~pgut001/tutorial/index.html

    Pour finir je dirais que j'utilise un certificat Cacert depuis belle lurette et que je ne suis pas près de faire confiance à quelqu'un d'autre et certainement pas à Startssl.com

    • [^] # Re: Attention quand même.

      Posté par  . Évalué à 4.

      Concrètement, pour sécuriser son petit serveur OwnCloud (ou assimilable), qu'est-ce qu'il faut faire pour avoir un niveau de sécurité adapté ? (c'est à dire pas trop moisi, mais pas nécessairement à l'état de l'art vu le niveau de menace faible pour une si petite cible)

      BeOS le faisait il y a 20 ans !

    • [^] # Re: Attention quand même.

      Posté par  . Évalué à 1.

      Alors je suis pas sur de moi mais il me semble (bortzmeyer à l'appui http://www.bortzmeyer.org/beast-tls.html) que la bibliothèque NSS ne supporte pas TLSv1.1 et 1.2 et que c'est pour ça que ta config me paraît très optimiste :)

      Perso je vois SSL TLS comme une barrière de plus (ACL, chroot, virtualisation, sépa des privilèges, pare-feu, proxy, DPI etc …) dans l'arsenal permettant de barrer la routes des sacripants de tout poil.

      TLS assure la "sécurité de la communication" :
      1. Authentification : Donc c'est mal barré quand on clique "Faire confiance à ce site" sans avoir au moins jeté un œil au certificat…
      1. Intégrité : L'intégrité est assuré par les algorithmes utilisés dans SSL TLS mais ils ne servent à rien si on est pas sûr de l'authenticité du correspondant
      1. Confidentialité : On ne commence a s'occuper de ça qu'une fois qu'on est absolument sûr des deux premiers, c'est la cerise, les tiers ne peuvent percevoir ce qu'il y a dans la communication.

      TLS n'a jamais protégé contre les failles du code, les élévations de privilèges, ou la destruction de données… Donc c'est bien un outil "en plus" pas une solution unique (vous allez me dire "com'd'hab"). Notez que je conçois volontiers que se soit un service "inévitable" dès qu'on parle de transfert de mot de passe ou d'informations sensibles.

      "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"

    • [^] # Re: Attention quand même.

      Posté par  . Évalué à 2.

      Concernant SSL, TLS, TLSA, les algos, les autorités de certifications etc… , il y a une conf de Benjamin Sonntag sur tout ça.
      Je vous la conseille, ça permet de mieux cerner SSL et tout ce qui gravite autour ainsi que mieux choisir ses algos.
      Il y a de la théorie, et de la pratique avec des exemples de config, ça c'est cool!

      confs.fr

      Celles sur DNS/DNSSEC et sur l'infra physique des télécoms sont vraiment bien aussi.

  • # Et du vrai mutualisé ?

    Posté par  . Évalué à 2.

    Une idée en l'air, mais qui pourrait faire boule,

    Pourquoi ne pas faire un système comme avec les clés GPG ? Après tout je fais confiance à la "clé publique" pardon au "certificat" de linuxfr.org, si ce site me fait confiance en retour il signe mon certificat, et les personne qui viennent sur mon site ont le certificat linuxfr.org, peuvent donc signer mon certificat et me laisser signer le leurs, et de proche en proche on ruine Verisign …

    L'idée c'est de signer les gens auxquels ont fait confiance, et mon certificat est signé par ceux qui me font confiance, au bout d'un moment les certificats prennent du poids car je reconnais un certains nombre de leur signataires… C'est toujours mieux que de tout centraliser chez une vingtaine "d'huissiers du net" ou de "notaires du net" qui se gavent à coup de 1000$/an le certif…

    Je sais GPG c'est pas super populaire, mais avec un petit script web qui permette de réaliser les opérations en ligne… Avec un espèce de truc à la réseau social, genre bitcoin, je sais pas mais y a un POC à creuser…

    "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"

    • [^] # Re: Et du vrai mutualisé ?

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

      Pourquoi ne pas faire un système comme avec les clés GPG ?

      Je crois que c’est l’idée derrière monkeysphere.

      • [^] # Re: Et du vrai mutualisé ?

        Posté par  . Évalué à 1.

        Malheureusement l'esthétique me rappelle les tentatives de réseau sociaux estampillé "GNU" ou "FSF" avec le succès qu'on ne connaît pas…
        Faudrait un truc un peu plus sexy pour décoller la rétine des facebookers et autre googleplusser :
        on veut pas qu'ils comprennent on veut qu'ils l'utilisent ;) Comme un peu l'effet bitcoins…

        "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"

      • [^] # Re: Et du vrai mutualisé ?

        Posté par  . Évalué à 2.

        Cela dit l'idée est là, c'est bien de ça que je parlais ;)

        "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"

    • [^] # Re: Et du vrai mutualisé ?

      Posté par  . Évalué à 2.

      Pourquoi ne pas faire un système comme avec les clés GPG ?

      Il existe une extension TLS permettant d'utiliser des certificats OpenPGP au lieu des habituels certificats X.509. Bon, en termes d'implémentations existantes, c'est encore assez restreint malheureusement.

  • # Hein ?

    Posté par  . Évalué à 5.

    il faut communiquer la clef privée par un canal sécurisé à chacun des utilisateurs des services hébergés

    Pourquoi distribuer la clef privée ? Les clients ont juste besoin du certificat (= clef publique). Bon, il vaut mieux diffuser le certificat aux clients de façon sécurisée (ou au moins son empreinte, pour qu’ils puissent la vérifier quand leur navigateur leur demandera d’accepter le certificat). Mais publique.

    Si tes clients ont besoin d’une clef privée, ce serait pour du TLS mutuel. Et tu n’en parles pas dans les autres cas…

    • [^] # Re: Hein ?

      Posté par  . Évalué à 1.

      J'ai aussi tiqué à cette phrase. Il suffit de communiquer le certificat public aux utilisateurs, surtout pas la clé privée..!

  • # DNSSEC & DANE

    Posté par  . Évalué à 6.

    Tu pourra peut-être bientôt diffuser ta clé sur ton DNS(SEC) avec DANE si la RFC est validée.

    • [^] # Re: DNSSEC & DANE

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

      Et si les logiciels le mettent en œuvre. Comme on parle surtout du web, je vous rappelle que cette application d'Internet est restée fossilisée à une époque antérieure à la simple introduction des enregistrements DNS dédiés aux protocoles, le premier étant le MX pour le courrier électronique, et n'a pas évolué depuis. HTML a évolué, HTTP est resté figé. Donc l'adoption d'un truc pareil, ce n'est pas pour demain, enfin dans Firefox il y a peut-être une chance, encore que, mais alors dans les autres…

    • [^] # Re: DNSSEC & DANE

      Posté par  . Évalué à 2.

      C'est la meilleure info que j'ai eu sur le sujet, merci :)

      Si ça passe, il devient possible sans contraintes de combiner les avantages d'un certificat CAcert et la reconnaissance par "tout le monde" du certificat, le tout pour pas très cher.

      BeOS le faisait il y a 20 ans !

    • [^] # Re: DNSSEC & DANE

      Posté par  . Évalué à 1.

      Salut,

      Apparemment, la techno a l'air déjà fonctionnelle, même si il faut installer un module complémentaire pour que Firefox la supporte.

      Du coup, j’aimerai bien tester… J'ai cherché un How-To expliquant comment mettre en place DANE et j'ai trouvé ça:

      Apparemment, ça n'a pas l'air très compliqué à mettre en place, j'essayerai peut-être ce week-end…

      Envoyé depuis ma Debian avec Firefox

      • [^] # Re: DNSSEC & DANE

        Posté par  . Évalué à 4.

        La problématique, c'est déjà d'avoir DNSSEC qui marche, ce qui n'est pas (encore) gagné sur tous les TLDs.

        • [^] # Re: DNSSEC & DANE

          Posté par  . Évalué à 4.

          Sans compter que les gérant des serveurs de noms de domaines doivent aussi l'implémenter. Et pour l'instant, il ne me semble pas que ce soit très répandu. Si on prend Gandi par exemple, on peut faire du DNSSEC si on utilise pas les serveur de gandi pour le serveur de nom.

          « 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

Suivre le flux des commentaires

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