Comment vas-tu yau de nal,
Je t’écris pour te donner des nouvelles de Let’s Encrypt, cette nouvelle autorité de certification sponsorisée, entre autres, par Mozilla, l’Electronic Frontier Foundation, Cisco, Akamai… qui fournit des certificats SSL gratuits. Il en a déjà été question sur DLFP, pour annoncer sa création et son premier certificat.
Le projet est actuellement au stade de bêta sur invitation. Il faut remplir un formulaire et attendre quelques jours que les (sous-)domaines demandés soient passés en liste blanche pour pouvoir utiliser le service. On approche de la fin de cette période, puisque la phase de bêta publique est prévue pour le 3 décembre. Le nombre de certificats que l’on peut demander est actuellement limité à 10 par jour et par IP, et il y a aussi une limite (peu claire mais pas gênante pour tester) sur le nombre de certificats par domaine.
L’idée de Let’s Encrypt est que le chiffrement devrait être généralisé, et donc gratuit et facile à mettre en place. Pour cela, un outil en Python est mis à disposition sous licence Apache afin de pouvoir obtenir un certificat automatiquement. Presque. Bon, il faut bien dire que la peinture n’est pas encore sèche, que la documentation laisse à désirer et que les sites web ne sont pas forcément à jour, mais la bonne nouvelle est que globalement, ça marche.
En gros, on télécharge l’outil en clonant le dépôt git, on se crée un fichier de configuration comme indiqué dans la doc, et on lance la commande suivante :./letsencrypt-auto certonly -a webroot --webroot-path /var/www/example -d example.com -d www.example.com --server https://acme-v01.api.letsencrypt.org/directory --agree-dev-preview
Je n’ai eu aucun problème pour l’exécuter, mais je suis sous Debian 8, qui est explicitement prise en charge. Je ne sais pas si les utilisateurs d’autres distributions auront autant de chance.
Cet exemple montre que les certificats multidomaines (utilisant SAN) sont pris en charge. C’est intéressant dans le cas (fréquent) ci-dessus, pour avoir un même certificat pour example.com et www.example.com, mais ça peut aussi être pratique si on a example.com, fr.example.com, de.example.com pour une application web localisée en plusieurs langues. Cependant, les certificats wildcard (*.example.com) ne sont pas pris en charge, et ont fort peu de chances de l’être, d’après quelques discussions sur le projet.
Les certificats sont de bonne facture, puisqu’ils utilisent l’algorithme SHA-256 (donc SHA-2) et, si on le demande dans le fichier de configuration, une clé RSA de 4096 bits, ce qui, après un peu de configuration de nginx, permet à mon serveur perso d’afficher un joli A+ de SSL Labs. Leur durée est de 90 jours, ce qui semble peu, mais c’est fait exprès, d’abord parce qu’une durée courte réduit les dégâts en cas de vol d’une clé privée, ensuite parce que le renouvellement est censé être automatique : on met en place une tâche cron qui s’exécute une fois par mois, et on n’y pense plus.
Pour entrer un peu dans le détail du fonctionnement, l’outil letsencrypt-auto se charge de toutes les opérations : création, renouvellement, révocation de certificat. Il est censé pouvoir configurer automatiquement Apache et nginx, ce que je n’ai pas testé, mais franchement, ce n’est vraiment pas nécessaire. En mode certonly (télécharger le certificat seulement), il dépose le certificat dans /etc/letsencrypt/live/example.com/ où on trouve, au format pem, le certificat, la chaine complète telle que demandée par Apache (sans le certificat lui-même) et nginx (avec), et la clé privée. Lorsqu’un certificat est renouvelé, les nouveaux vont dans live et les anciens dans /etc/letsencrypt/archive. Il suffit donc de configurer nginx comme ceci :
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
et c’est tout.
Lors d’une création de certificat, letsencrypt-auto doit permettre au serveur de Let’s Encrypt de vérifier que le serveur d’où provient la requête contrôle le (sous)-domaine concerné. Pour cela, il y a actuellement deux méthodes :
- avec un serveur ad hoc sur le port 443, ce qui peut demander d’arrêter le serveur web (c’est dommage),
- en déposant un fichier à la racine, avec l’inconvénient que si on demande un multi-domaine, ce n’est possible que si tous les domaines partagent une même racine. Ce n’est pas grave dans la mesure où il est (censé être) facile d’automatiser la création de certificats sans limite, donc le multi-domaine n’est pas si important.
Censé, parce qu’en plus des limites en phase de bêta, l’outil a encore quelques bugs gênants. Par exemple, ./letsencrypt-auto fonctionne, mais pas /home/toto/letsencrypt-auto. Ça fait un peu tache. D’autre part, si on a bien créé son fichier de configuration, après la première exécution, on peut supposer qu’il ne demande plus de confirmation… enfin, on espère. Ça reste une bêta, il ne faut pas perdre ça de vue.
En tous cas, je n’hésiterai plus à organiser mon serveur en sous-domaines et à les servir tous en https, maintenant que c’est gratuit. Et c’est bien là le but de l’opération.
# Tout pareil
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 9.
J'ai profité de la beta aussi et c'est génial. Enfin des certificats simples à mettre en place, reconnus par (presque) tous les navigateurs.
Je n'utilise pas les certificats multi-domaines car je pars du principe que le client utilise l'extension Server Name Indication.
On peut aussi utiliser let's encrypt pour faire des certificats pour autre chose que les sites web (serveur courriel, xmpp, etc).
# Durée courte
Posté par Sytoka Modon (site web personnel) . Évalué à 8.
Je ne suis pas fanat de la durée trop courte, surtout, faut-il faire trop confiance dans l'autorité de certification ? Je trouve que le protocole devrait être changé pour avoir deux certificats et une période de recouvrement, ainsi le client pourrait vérifier que le nouveau certificat est à la fois signé par l'autorité mais aussi par l'ancien certif et ainsi de suite lors de chaque renouvellement. Sur des sites ou on va régulièrement, par exemple une fois par trimestre au moins, on aurait aussi une protection contre une attaque sur l'autorité elle même.
[^] # Re: Durée courte
Posté par aiolos . Évalué à 7.
Dans le modèle des certificats, il n'y a pas le choix : une liste de certificats racines "de confiance" est définie sur ton système ou dans ton navigateur, ceux-ci on tout pouvoir pour délivrer des certificats.
L'idée ici, ce n'est pas de faire évoluer le standard mais de permettre de généraliser l'utilisation de l'existant, ce qui serait déjà pas mal. En l'occurence, déjà simplement automatiser tout ça, c'est un grand pas en avant.
Et ce que tu propose, ce n'est pas possible dans les protocoles actuels : le format X.509 ne permet pas les signatures multiples.
[^] # Re: Durée courte
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Je sais bien mais justement, je trouve que le protocole et le format X.509 sont périmés. Il serait temps d'aller de l'avant. Le ver est dans le fruit comme on dis ;-)
[^] # Re: Durée courte
Posté par gouttegd (site web personnel) . Évalué à 6.
Là ce n’est pas le protocole ACME qu’il faut changer, mais le format des certificats. Un certificat X.509 ne peut pas porter plusieurs signatures.
Pour ça, il y a l’épinglage de certificats dans les en-têtes du serveur web (déjà implémenté dans la plupart des navigateurs) et/ou dans le DNS.
# Très intéressant !
Posté par Nanawel (site web personnel, Mastodon) . Évalué à 1.
Merci pour ton retour, j'ai eu accès à la bêta mais je n'ai pas encore eu le temps de m'y mettre.
Ce qui me rassure c'est que tu me confirmes que le renouvellement peut être entièrement automatisé et transparent, ce qui était justement une de mes interrogations initiales. Yapuka quoi.
# 4096
Posté par Zenitram (site web personnel) . Évalué à 5.
En fait, contrairement à ce que la doc dit, depuis un moment RSA-2048 suffit à avoir un A+. essaye avec les gros sites (Google, GitHub…), ils sont tous en 2048 et ont un A+.
C'est un petit retour en arrière (je ne dis pas que c'est mal, ça se comprend à cause de la perf et/ou taille de clé énorme, et pas d'attaque connue sur 2048)
[^] # Re: 4096
Posté par ɹǝıʌıʃO . Évalué à 5.
Merci de l'info. Du coup, un autre intérêt de Let's Encrypt apparait : si on trouve qu'on s'est trompé en choisissant un paramètre du certificat, on peut tout simplement en créer un autre.
# Merci
Posté par MTux . Évalué à 7.
Merci pour ce retour, ça m'a donné envie de m'inscrire ;)
Je trouve que les certificats de 90j renouvelables par cron c'est une idée géniale.
# FreeBSD
Posté par Pnchbllz . Évalué à 2.
J'ai eu accès a la bêta aussi et j'ai pu mettre en place sans aucuns soucis sous FreeBSD 10.2 et le faire fonctionner pour nginx.
Parcontre, là ou j'ai rencontré un problème c'est pour m'en servir pour faire du SSL/VPN avec OpenVPN, mais j'ai pu mal m'y prendre.
# Wildcard ?
Posté par Mimoza . Évalué à 4.
Pourrais tu nous résumer les raisons pour le refus du support du wildcard ?
Je suppose que c'est dans la même veine que la limite à 90 jours, éviter qu'un serveur compromis expose un sous-domaine usurpé mais que le certificat le valide sans alerte.
[^] # Re: Wildcard ?
Posté par Zenitram (site web personnel) . Évalué à 5.
Le wildcard est une faille (ou disons un risque inutile) de sécurité, et est donc banni des certificats "évolués" (par exemple avec vérification de l'entité, c'est interdit complet avec SSL EV).
"The ease of use when it comes to setting up a new subdomain to use the certificate is also potentially dangerous. For example, it would be easy for a disgruntled employee to setup a subdomain on the network and have it seem like a valid and secure website."
(source parmi d'autres)
Arrêtez de faire "open bar" (rarement une bonne idée en sécurité), connaissez vos sous-domaines, surtout maintenant que c'est gratuit (ça l'était déjà avec StartSLL sauf quand vous pommiez votre certification donc votre faute, mais maintenant que c'est gratuit vous n'avez plus aucune excuse),
[^] # Re: Wildcard ?
Posté par Anonyme . Évalué à 1.
Qu’est-ce que tu fais quand tu dois utiliser un wildcard DNS (je sais, c’est dégueulasse) ?
Par exemple, on travaille avec une société qui utilise
*.example.netpour pouvoir ajouter/supprimer des CTI sans avoir à faire de changement au niveau DNS.[^] # Re: Wildcard ?
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 18 novembre 2015 à 19:15.
La même chose que si on te demande de mettre du SSLv1 avec RC4 ou MD5 : tu fais de la sécurité pourrie (tant pis, mais c'est la demande, tu as prévenu) avec "un autre" jusqu'à ce qu'il n'y ai plus de "un autre" et la ton emmerdeur sera bien obligé de le faire (car tout le monde dira la même chose que toi).
Note que les vendeurs ne disent pas "c'est pour ton bien et la notre par la même occasion", mais "la règle EV nous interdit", faut imaginer comment on doit se taper la sécurité même à ce niveau…
Bref, en attendant tu prends un wildcard ailleurs et tu payes, en te disant que ta sécu a un (petit pour le moment) trou pas de ta faute.
[^] # Re: Wildcard ?
Posté par barmic . Évalué à 5.
J'ai l'impression que c'est un peu un pis-aller : « La sécurité est pourrie parce que de toute manière DNS n'est pas bien sécurisé et certaines autorités ne sont pas terribles donc on fait des châteaux de sable en faisant croire que c'est Byzance ».
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Certificat pour un usage autre que le web
Posté par Sébastien Koechlin . Évalué à 3.
Bonjour,
La méthode de vérification me semble un peu limité. Est-ce qu'il est prévu d'autres mécanismes pour les autres cas ?
Si je veux un certificat pour un annuaire LDAP, ou pour un serveur de mail ? Pour un protocole quelconque (et nouveau) ? Ca va être difficile de déposer un fichier à la racine d'un annuaire LDAP.
[^] # Re: Certificat pour un usage autre que le web
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 18 novembre 2015 à 09:47.
C'est le début, donc avec le plus classique (et un site web est 100x plus classique que LDAP), et c'est open source donc tu peux proposer un patch ;-) (le tout est que ce soit bon en sécurité et automatisable).
Si on attend de gérer tous les cas spéciaux avant de passer en beta (et même en prod)…
PS : me voila à défendre Mozilla sans aucune critique (enfin, pour le moment :) ), mais je suis certain que quand je le critiquerai de nouveau on me balancera "tu es toujours en train de cracher sur Mozilla" en oubliant certains de me commentaires :)
[^] # Re: Certificat pour un usage autre que le web
Posté par mathgl . Évalué à 1.
Je suis pas sûr que tu ne puisse pas utiliser un certificat pour un autre service qu'un service Web. La vérification doit permettre de valider que la demande provient bien de la machine dernière le domaine du certificat que tu demandes. Ils utilisent pour ça le port 80 ou 443 mais rien ne t'empêche de laisser les ports ouverts juste pour le renouvellement du certificat même si c'est effectivement pas idéal.
[^] # Re: Certificat pour un usage autre que le web
Posté par ɹǝıʌıʃO . Évalué à 3.
Les certificats sont uniquement de type « Domain Validation » (pas de signature de code ou d’email par exemple), mais en principe permettent tout ce qu’on peut faire avec DV.
Il existe une procédure pour obtenir un certificat sans ouvrir le port 443 ni donner l’accès à la racine, mais ils disent eux-mêmes que c’est « assez compliqué ». Je n’ai pas creusé pour le moment. En principe c’est possible.
[^] # Re: Certificat pour un usage autre que le web
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 3.
Il « suffit » que tu aies un serveur web qui soit accessible sur l'adresse de ton ldap. C'est faisable plus ou moins simplement selon l'architecture.
Pour ma part je me suis fait un certificat pour mon serveur de courriels avec la méthode « webroot » décrite dans le journal.
[^] # Re: Certificat pour un usage autre que le web
Posté par Tonton Benoit . Évalué à 4. Dernière modification le 18 novembre 2015 à 14:33.
La dernière fois que j'ai regardé le github du client, y'a un serveur web minimaliste inclus pour une utilisation "standalone".
Et on peut faire un cron un peu évolué genre :
- ouverture des ports
- mise à jour des certificats
- fermeture des ports
Après rien n’empêche d'utiliser le certificat pour du SMTP, du LDAP, du Postgres…
# Chaviro
Posté par klakmuf . Évalué à -8.
Pas mal, et toinal matelas ?
[^] # Re: Chaviro
Posté par DL . Évalué à -3.
toinal à matelas ?
[^] # Re: Chaviro
Posté par klakmuf . Évalué à -1.
Et toile à matelas
# Automatisme ?!?
Posté par khivapia . Évalué à 5.
La fonctionnalité de sécurité principale à laquelle répond le certificat, c'est l'association d'une clef publique à une identité (ici un site web).
Du coup il faut une vérification d'identité par un autre moyen qu'une clef publique (puisqu'il lui faut, également, un certificat…). Du coup, quelle vérification fait l'autorité avant de délivrer le certificat ?
[^] # Re: Automatisme ?!?
Posté par DL . Évalué à 1.
ça m’intéresse carrément car je commence un projet utilisant une liaison SSL sous Qt et pouvoir utiliser un certificat via Let's encrypt m'arrangerait bien.
Merci pour ce journal d'ailleurs.
[^] # Re: Automatisme ?!?
Posté par gouttegd (site web personnel) . Évalué à 3.
Que le client a bien la main sur le domaine pour lequel il demande un certificat, comme expliqué ici.
C’est peu ou prou la même chose que ce que font les autres CA pour délivrer des certificats domain-validated, juste un peu plus automatisé.
[^] # Re: Automatisme ?!?
Posté par khivapia . Évalué à 2.
OK, donc c'est largement vulnérable à une attaque man-in-the-middle à l'initialisation, puisque ça utilise le même canal (internet) que celui pour lequel on cherche à donner un certificat.
J'ignorais que c'était une technique classique, du coup l'(illusion de) sécurité supplémentaire apportée par les certificats ne consiste qu'en un déplacement temporel de l'attaque MITM pour qu'elle soit effective (plutôt que de la faire à la connexion de l'utilisateur, il faut la faire à l'initialisation de l'envoi du certificat, mais c'est la même difficulté).
Ça mine fortement ma confiance en la sécurité du web tout ça : d'après les documents fuités par Snowden, les attaques au milieu sont une réalité (et il semblerait que ce soit le cas avec tous les certificats utilisant des clefs de signature DSA de 1024 bits).
[^] # Re: Automatisme ?!?
Posté par ɹǝıʌıʃO . Évalué à 2.
Je ne vois pas en quoi c'est vulnérable.
L'application Let's Encrypt se connecte au serveur de Let's Encrypt (en https, évidemment). Le serveur de LE demande de placer à la racine un fichier avec des caractéristiques données, qui ont été transmises en https, donc chiffrées. Si ce fichier apparait à la racine tel que demandé, c'est bien que le demandeur a la contrôle de son serveur, je ne vois pas comment un MITM pourrait simuler cela.
[^] # Re: Automatisme ?!?
Posté par Sufflope (site web personnel) . Évalué à 3.
Je ne suis pas expert mais là comme ça je ne vois pas comment LE s'assure que les informations DNS qu'ils utilisent lors de la connection de contrôle vers le domaine à valider n'ont pas été usurpées.
[^] # Re: Automatisme ?!?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 2.
Vous avez raison, c'est assez vulnérable.
Le vrai problème est que la plupart des gens veulent quelque chose de peu cher et rapide, voire quasi instantané (tout en parlant sécurité). Donc les CAs font des vérifs de ce genre passant par le DNS (un autre classique est aussi d'envoyer une vérif par email à une des adresses enregistrées pour ce domaine dans le DNS, ce qui est aussi tout à fait vulnérable à une interception).
Le top de la sécurité serait bien entendu que deux personnes (un représentant le domaine, l'autre le CA) se rencontrent en vrai, physiquement, pour s'échanger des informations d'identité puis — si tout semble en ordre — des infos d'identification au service. Mais ça prendrait du temps, et surtout ça coûterait une blinde (le temps humain est ce qui coûte le plus cher!). Cela va à l'encontre du besoin.
Donc des compromis sont faits. De toutes façons peu de gens comprennent vraiment ce qu'ils font avec HTTPS, même ceux qui sont payés pour cela.
Pour minimiser le risque ceci dit, la vérification de présence du fichier est faite sur le serveur en https (c'est à dire https://example.com, et non http://example.com). Voir la page d'explication des technos. Donc tant que le renouvellement se fait avec un certificat encore valide (ce devrait être le cas, puisqu'automatique), cela assure une certaine sécurité. Le risque de MITM n'apparaît donc qu'à la demande initiale. Bien sūr, l'attaquant pourrait alors demander à passer par un canal moins sécurisé (comme un enregistrement DNS), et ce serait donc bien si un possesseur/administrateur de domaine avait la possibilité de bloquer certains canaux de vérification.
Dans tous les cas, oui. Il y a toujours à un moment donné au moins 1 instant (l'échange initial) où la sécurité est faible et sujette à attaque si toutes communications passent par Internet. C'est le coût de tout faire à distance et c'est la raison pour laquelle les geeks sécurité font des "key signing party" pour s'échanger et signer leurs clés personnelles avec rencontre physique et vérification d'identité, afin d'éliminer ce risque de l'échange initial.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Automatisme ?!?
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 3.
DNSSEC ?
[^] # Re: Automatisme ?!?
Posté par Sufflope (site web personnel) . Évalué à 2.
Oui c'est un moyen de s'assurer en général de l'authenticité des DNS. Sauf que comme on parle de LE et que LE n'exige pas DNSSEC, c'est hors de propos. Tu peux utiliser DNSSEC et alors si les résolveurs de LE l'utilisent, pour ton cas le risque sera écarté, mais tant qu'ils n'exigent pas DNSSEC leur protocole est vulnérable.
[^] # Re: Automatisme ?!?
Posté par khivapia . Évalué à 4.
Si ce fichier apparait à la racine tel que demandé, c'est bien que le demandeur a la contrôle de son serveur
Non: la CA n'ayant pas authentifié le demandeur (forcément, elle ne le connaît pas !), il peut s'agit de la NSA qui lui fait un joli MITM et reroute la connexion de Let's Encrypt pour vérification sur son propre site web.
[^] # Re: Automatisme ?!?
Posté par gouttegd (site web personnel) . Évalué à 7.
Même pas.
Le système actuel ne fournit aucune sécurité contre les attaques de type MITM. Il y a trop de moyens d’obtenir un certificat frauduleux qui sera accepté par le plus grand nombre. Trop d’autorités de certification (et encore plus de CA intermédiaires) à laquelle on accorde une confiance totale (X.509 ne connait rien d’autre que la confiance complète) et aveugle.
Tu peux bien obtenir un certificat à validation étendue (EV) en payant très cher une CA irréprochable (admettons qu’une telle CA existe)… ça n’empêchera pas un attaquant d’obtenir un certificat frauduleux pour ton domaine auprès de l’une quelconque des milliers de CA ou CA intermédiaires malhonnêtes ou incompétentes — et ce certificat sera accepté comme valide par les clients.
Les CA ne servent à rien. Tout le monde le sait, mais tout le monde fait semblant de l’ignorer.
Ce n’est que pour se protéger des attaques actives de type MITM que l’on a besoin d’autorités de certification (contre les attaques passives, un certificat auto-signé est suffisant, nul besoin de CA), et c’est précisément contre ce type d’attaque qu’elles n’apportent aucune garantie…
Ça fait longtemps que la mienne est complètement détruite.
[^] # Re: Automatisme ?!?
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Comme je le dis plus haut, il faudrait pouvoir avoir plusieurs certificats avec une période de recouvrement longue. Les attaques par MITM seraient bien plus complexe et toucherai en pratique bien moins de personne. Un système d'alerte pourrait les faire remonter afin de les signaler, ce qui permettrait de faire tomber rapidement pas mal de MITM…
Bref, il est temps de passer à autre chose que les bêtes certificats actuels…
[^] # Re: Automatisme ?!?
Posté par gouttegd (site web personnel) . Évalué à 3.
Non mais là tu rêves éveillé…
D’une part, tout nouveau protocole (ou modification d’un protocole pré-existant comme TLS/X.509) nécessitant de modifier le code des serveurs et des clients a très peu de chance d’être mis en place, et s’il l’est ce ne sera pas avant plusieurs années. Il y a une inertie énorme, il suffit de voir le temps qu’il a fallu pour déployer TLS 1.2 — on trouvait encore il y a quelques mois beaucoup de serveurs ne supportant rien de mieux que SSL 3.0, obsolète depuis plus de quinze ans (il a fallu l’attaque POODLE pour donner un coup de pied dans la fourmillière).
D’autre part, des alternatives aux « bêtes certificats actuels », ou des méthodes pour combler leurs déficiences, il y en a déjà plusieurs. Au moins deux sont particulièrement dignes d’intérêt :
les certificats OpenPGP (RFC 6091), beaucoup plus flexibles que les certificats X.509 (ils peuvent notamment porter un nombre arbitraire de signatures, et la confiance en chaque signature n’est pas binaire) ;
l’épinglage des certificats (ou des clefs brutes, RFC 7250) dans le DNS (DANE, RFC 6698).
Ni l’un ni l’autre ne sont largement supportés. À ma connaissance, seule la bibliothèque GnuTLS implémente le RFC 6091, et aucun navigateur ne supporte nativement DANE (un plugin existe pour ceux qui le veulent).
Toute proposition de solution aura besoin de l’appui d’un poids lourd du web pour s’imposer, indépendamment de ses mérites. C‘est comme ça que seul Certificate Transparency, qui est activement poussé par Google, a une chance d’aller loin (et c’est malheureux, car c’est une fausse solution qui ne résoud aucun des problèmes de X.509).
[^] # Re: Automatisme ?!?
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Je ne suis pas le seul à rêver puisque un, tu montres qu'il y a déjà des pistes et que deux, après le TLS 1.2, il y aura bien un jour un TLS 1.3. Je n'ai jamais dis qu'il fallait mettre en place un système incompatible et cela dès demain ;-)
# IPv6 / services internes
Posté par tetraf . Évalué à 3.
J'ai également testé il y a quelques jours et je note qu'il y a (actuellement hein, c'est une beta) deux limitations à prendre en compte :
si la machine sur laquelle vous testez le truc est en uniquement en IPv6 vous pouvez vous brosser : github (pour récupérer le code) ne gère pas encore IPv6, Pypi (pour les dépendances) non plus mais il existe quelques miroirs qui le font (mais ne sont pas sélectionnés automatiquement par pip) et, une fois franchies ces étapes, LE non plus ;
si vous voulez un certificat pour un service qui tourne sur une machine qui n'est pas accessible à l’extérieur ça va être compliqué à automatiser pour le moment puisque LE a besoin de joindre la machine (de l'extérieur donc) pour valider le certificat donc il faudrait utiliser une passerelle puis rapatrier le certificat (et de manière automatique parce que ça va pas être drôle de le faire à la main pour chaque domaine tous les 90 jours).
[^] # Re: IPv6 / services internes
Posté par ɹǝıʌıʃO . Évalué à 3.
C’est dommage, en effet. Ça vaudrait le coup de leur remonter le problème, si ce n’est déjà fait.
Dans quel scénario utilises-tu un certificat DV sur une machine inaccessible de l’extérieur ?
[^] # Re: IPv6 / services internes
Posté par tetraf . Évalué à 2.
Oui j'ai oublié de préciser, ils sont au courant des deux problèmes :
Je ne suis pas sûr de comprendre la question, elle porte sur le fait de chiffrer sur un réseau interne ou sur le fait de ne pas utiliser un auto-signé ?
Dans le premier cas je ne suis pas forcément tout seul sur le réseau, dans le deuxième c'est plus pratique d'avoir un certificat signé par un tiers reconnu plutôt que de faire accepter un auto-signé par toutes les machines d'un parc hétérogène (et je n'aurais pas le problème si DANE/TLSA était implémenté partout).
[^] # Re: IPv6 / services internes
Posté par ɹǝıʌıʃO . Évalué à 2.
Ton deuxième lien montre que la vérification du domaine par DNS est prévue, ce serait bien pratique et pas du tout intrusif, et ça couvrirait les cas qui posent problème actuellement.
[^] # Re: IPv6 / services internes
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 19 novembre 2015 à 09:37.
OK, mais pas encore gênant (qui n'a pas une adresse:port IPv4 pour un serveur?), c'est un début et débuter avec 99% des cas c'est déjà pas mal.
Dans ce cas tu prends un certificat auto-signé puisque tu maitrises toute la chaîne (aucun accès extérieur), tu n'as pas besoin de Let's encrypt.
Bon, et si tu en as quand même besoin : pareil que IPv6, encore un cas pas majoritaire, commençons par le plus facile.
[^] # Re: IPv6 / services internes
Posté par tetraf . Évalué à 1.
Moi j'en ai quelques uns, les IPv6 c'est très pratique pour des VM. Bon mais du coup je n'ai pas de services publics sur des VM avec seulement IPv6 donc ça limite un peu le besoin.
Pas toujours possible/voulu.
Ah mais je suis bien d'accord, je me contentais de pointer les problèmes que j'ai eu lors du test d'une solution, qui est en beta de toutes façons. Les problèmes sont connus par LE et le but c'est qu'ils soient résolus à terme donc rien de critique pour le moment.
# Des o1gn0ns chiffrés
Posté par Parleur . Évalué à 3.
Est-ce qu'il sera possible de demander des certificats SSL pour des domaines en
.onion, pour TOR ?[^] # Re: Des o1gn0ns chiffrés
Posté par ɹǝıʌıʃO . Évalué à 4.
Il en est question dans cette discussion. En tous cas pas au début ; ils l’envisagent mais ce n’est pas évident.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.