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 superna (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 !
[^] # Re: CACert
Posté par Zenitram (site web personnel) . Évalué à 1.
Certaines.
(par exemple : Debian l'a, CentOS 6 ou Ubuntu ne l'ont pas)
On passe de "les distribs Linux" à "quelques rares Linux, qui sont déjà rares eux-mêmes"…
[^] # Re: CACert
Posté par gnujsa . Évalué à 6.
Ubuntu ?
Et c'est quoi ce fichier : /usr/share/ca-certificates/cacert.org/cacert.org_root.crt ?
http://packages.ubuntu.com/saucy/all/ca-certificates/filelist
[^] # Re: CACert
Posté par Zenitram (site web personnel) . Évalué à 2.
Il semble nouveau dans 13.10, pas dans 13.04 :
http://packages.ubuntu.com/raring/all/ca-certificates/filelist
(de souvenir, le fichier cacert.org.crt seul ne permet pas d'authentifier les autres sites, du moins dans mes précédents tests ça ne marchait pas)
Je me met à jour. (j'tais resté à https://wiki.ubuntu.com/CAcert )
Euh… en fait, pour confirmer, ce fichier suffit pour que Firefox d'Ubuntu accepte LinuxFr sans râler?
[^] # Re: CACert
Posté par gnujsa . Évalué à 4.
oui … en 2005
Sinon, il semble aussi présent dans fedora
(je n'arrive pas à voir le contenu des paquets sur https://apps.fedoraproject.org/packages/ca-certificates/contents, ça ne marche pas, par contre dans le source du script qui récupère les certificats, les lignes concernant cacert ne sont pas commentées)
ou encore Slackware:
http://packages.slackware.com/?r=slackware-current&p=ca-certificates-20130906-noarch-1.txz&f
Également Gentoo aussi, car c'est le paquet debian qui est récupéré :
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-misc/ca-certificates/ca-certificates-20130906.ebuild?view=markup
Idem, sur Archlinux, c'est le paquet Debian qui est récupéré, donc il y a le certificat cacert:
https://www.archlinux.org/packages/core/any/ca-certificates/
Finalement, le certificat cacert est plutôt bien présent dans les distributions Linux, pour peu qu'on se donne la peine de chercher un peu.
Si des utilisateurs d'autres distrib' peuvent profiter de ce journal pour faire le point de la disponibilité des certificats cacert dans leur ditro favorite et ainsi éviter de propager inutilement « de la peur, de l'incertitude et du doute », à propos de cacert.org, ça serai pas mal.
[^] # Re: CACert
Posté par madhatter (site web personnel) . Évalué à 0.
Debian ? Tu rigoles j'espère.
There is no spoon...
[^] # Re: CACert
Posté par Sufflope (site web personnel) . Évalué à 4.
Les "déjà rares eux-mêmes" ce sont tous les Linux, et sur le desktop c'est un fait. Debian ne représentant qu'une part de ça…
[^] # Re: CACert
Posté par kebree . Évalué à 0.
Sauf que tu rigoles rarement avec des certificats pour sous-domaines sur un desktop.
# CAcert
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Tu as oublié de mentionner CAcert. Je complète donc.
utiliser un certificat de chez CAcert
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é.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 Zenitram (site web personnel) . Évalué à 0.
Ca ressemble fortement au cas 1 cette histoire…
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
En un peu plus sérieux.
[^] # Re: CAcert
Posté par dinomasque . É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 dinomasque . É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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Je ne comprends pas la raison. Autant écarter l'auto-signé dans ce cas.
Pas compris.
Aller sur le site de CAcert, installer le certificat racine, sans garantie sur son intégrité.
[^] # Re: CAcert
Posté par Mimoza . É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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3. Dernière modification le 08 novembre 2013 à 00:15.
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 Buf (Mastodon) . Évalué à 2.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2. Dernière modification le 08 novembre 2013 à 13:33.
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 Larry Cow . Évalué à 4.
Oui, donc on peut mais on peut pas.
[^] # Re: CAcert
Posté par 🚲 Tanguy Ortolo (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 Zenitram (site web personnel) . Évalué à 0.
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 :
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 Larry Cow . Évalué à 5.
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 Jokernathan . É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 dinomasque . É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 🚲 Tanguy Ortolo (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 jinbeman . É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 Flyinva . É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 Larry Cow . Évalué à 6.
Quitte à s'auto-signer, ça peut valoir le coup de mettre en place le schéma suivant :
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 jinbeman . É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 dinomasque . É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 jinbeman . Évalué à 1.
Certes…
Du coup effectivement c'est sécurisant à condition de le sélectionner correctement (il s'agit du ssl mutualisé de claranet cité dans le journal).
:]
[^] # Re: SSL mutualisé, c'est vraiment sécurisé ?
Posté par delio . É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 Anonyme . Évalué à 1.
sauf si tu chiffres tous tes disques
[^] # Re: SSL mutualisé, c'est vraiment sécurisé ?
Posté par delio . É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 Anonyme . É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.
[^] # Re: SSL mutualisé, c'est vraiment sécurisé ?
Posté par delio . Évalué à 3. Dernière modification le 07 novembre 2013 à 16:22.
et la clef serveur ssh, elle est stockée comment?
[^] # Re: SSL mutualisé, c'est vraiment sécurisé ?
Posté par Anonyme . Évalué à 0.
la clé publique est sur le serveur, la privée est chez moi bien au chaud
[^] # Re: SSL mutualisé, c'est vraiment sécurisé ?
Posté par Gauthier Monserand (site web personnel) . Évalué à 5.
Je pense que la question n'était pas la clé du client mais celle du serveur. Vu la problématique c'est la poule et l’œuf (ou l'inverse, comme tu veux), on peut argumenter mais tu ne peux pas gagner, c'est le même problème que pour les dvd :)
[^] # Re: SSL mutualisé, c'est vraiment sécurisé ?
Posté par delio . Évalué à 4.
Je parle de la clef server (host key), celle qui te permet de dire, quand tu te connectes, que tu te connectes au bon serveur.
Et cette clef elle est stockée en clair, comme le contenu complet du initrd en fait. Quand tu te connectes pour donner la passphrase, il y a peut etre un joli keylogger derriere et tu ne peux pas le savoir.
[^] # Re: SSL mutualisé, c'est vraiment sécurisé ?
Posté par Anonyme . Évalué à 3. Dernière modification le 07 novembre 2013 à 17:44.
vrai, mais c'est à cela que tripwire et tiger servent, pour vérifier que rien d'étranger n'aura été installé à mon insu
mais c'est vrai que je ne m'en apercevrai qu'une fois que j'aurai transmis ma passphrase !
[^] # Re: SSL mutualisé, c'est vraiment sécurisé ?
Posté par Kioob (site web personnel) . Évalué à 1.
On va mettre de l'EFI dans tous les serveurs ? :)
alf.life
# Attention quand même.
Posté par Raoul Volfoni (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:
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 dinomasque . É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 J Avd . É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
SSLTLS 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
SSLTLS mais ils ne servent à rien si on est pas sûr de l'authenticité du correspondant1. 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 -=[ silmaril ]=- (site web personnel) . Évalué à 1.
ce qui est vrai en 2011 ne l'est plus forcement en 2013
la librairie nss supporte maintenant tls1.1 et 1.2, bien que par exemple sous firefox ce ne soit pas encore actif par défaut (passe security.tls.version.max a 3) et va sur https://www.ssllabs.com/ssltest/viewMyClient.html
[^] # Re: Attention quand même.
Posté par Nicephor . É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 J Avd . É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 gouttegd . Évalué à 3.
Je crois que c’est l’idée derrière monkeysphere.
[^] # Re: Et du vrai mutualisé ?
Posté par J Avd . É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 J Avd . É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 Bernez . Évalué à 2.
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 Sylvain Sauvage . Évalué à 5.
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 Ely . É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 jfmartin . É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 🚲 Tanguy Ortolo (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 jfmartin . Évalué à 1.
Tu peux mettre d'autres enregistrement que le MX avec les SRV records (par exemple, du XMPP). Sinon, il y a déjà pas mal de trucs comme ça dans le DNS : https://en.wikipedia.org/wiki/List_of_DNS_record_types
Sinon, c'est vrai que ça demande l'adoption par les applications.
Mais il y a d'autres applications que DANE, il est possible de publier les clés publiques des serveurs SSH (http://www.internetsociety.org/deploy360/blog/2013/09/freebsd-10-to-include-openssh-with-dnssec-support-for-sshfp-records/).
Pour finir, HTTP n'est pas figé, on peut espérer HTTP 2.0 pour 2014 et en attendant, il y a SPDY. Puis on a pu mettre pas mal de trucs "au dessus" comme les websockets.
[^] # Re: DNSSEC & DANE
Posté par dinomasque . É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 mrr . É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 Larry Cow . É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 claudex . É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.