ça me semble problématique, mais je ne suis pas un expert
Le TOFU à ses inconvénients: si le site est frauduleux dès le début, on peut pas protéger. Si le site est un squat de domaine, idem.
Ceci dit, une faille dans la chaîne des CA, et c'est tous les maillons descendants qui sont cassés, on a déjà vu le cas, et pas qu'une fois.
En plus de ça, que risque-t-on?
Avec gemini, pas de cookies, pour commencer.
Et l'idée, c'est d'avoir des sites gemini simples, pas de cross-domain, pas de contenu qui s'exécute au hasard (dans l'esprit, hein, parce que je doute que ça soit impossible de le faire, me souviens plus)… contrairement au web.
Je pense personnellement que les chaînes de sécurités des CA sont d'une utilité plus que douteuse dans le cas d'un site type blog, ou le but est juste de communiquer sur un sujet qui intéresse l'auteur, ou qui permets le téléchargement d'un fichier.
Il n'y a pas de login, pas (besoin) de cookie, pas de langage turing-complet embarqué dans le document…
Pour ce qui est du typo-squatting… au final, le système de CA ne l'empêche pas non plus, il suffit de voir tous ces gestionnaires de paquets pour language de programmation qui se font exploiter.
Bref, sauf pour des sites sensibles, qui servent a interagir (type linuxfr), je ne vois pas trop l'intérêt des chaînes de certificats. Et même dans ce cas précis, je ne suis pas entièrement convaincu.
Bon, certes, dans le cas de ma banque, avoir un certificat qui soit validé par une autorité supérieure en laquelle j'ai confiance est un plus.
Mais justement… puis-je avoir confiance dans l'autorité certificatrice de ma banque? Ça serait mon gouvernement, peut-être (et encore, on pourrait arguer que certains gouvernements de certaines nations ne sont pas nécessairement dignes de confiance).
En l'occurrence, il s'agit de «Sectigo Limited». Tout semble indiquer une entreprise des USA, alors, la confiance, comment dire…
Le TOFU empêche aussi d'avoir plusieurs instances qui répondent, sauf si elle partage le même secret (ce qui n'est pas terrible). Avec la chaîne des CA, tu peux en avoir deux certificats différents pour le même site et cela fonctionne (bon, souvent, on le fait plutôt par datacenter, sinon c'est trop le bordel).
Sinon, un avantage des CA actuellement, c'est les CRL et OCSP pour pouvoir révoquer une clef volée (bon, c'est un avantage assez léger vu que personne ne l'utilise).
Mais justement… puis-je avoir confiance dans l'autorité certificatrice de ma banque?
Le problème, c'est surtout qu'il faut avoir confiance dans toutes les autorités installées sur ta machine.
« 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
Sinon, un avantage des CA actuellement, c'est les CRL et OCSP pour pouvoir révoquer une clef volée
Euh, présenter les CRL et OCSP comme un avantage des CA, c’est un peu fort, sachant que
les CRL n’ont jamais vraiment été pratiques, au point que la plupart des navigateurs modernes ne les supportent plus ;
OCSP pose au moins autant de problème qu’il n’en résout, entre le fait que la CA prend connaissance des visiteurs des sites pour lesquels elle a émis un certificat et le fait que le serveur OCSP est un SPOF.
Il a fallu inventer l’OCSP Stapling pour avoir un truc qui tienne à peu près la route et fasse à peu près ce qu’on attend.
(bon, c'est un avantage assez léger vu que personne ne l'utilise).
Pour une fois que des technos pourries ne sont pas utilisées, je ne vais pas m’en plaindre, perso. Si Certificate Transparency pouvait connaître le même sort, ce serait parfait.
Pour une fois que des technos pourries ne sont pas utilisées, je ne vais pas m’en plaindre, perso. Si Certificate Transparency pouvait connaître le même sort, ce serait parfait.
Ça ne résout aucun des problèmes posés par le système des CA et ne sert en fait qu’à assoir un peu plus ce système en coupant l’herbe sous le pied à toute tentative facilitant l’utilisation de certificats non-émis par une CA du cartel (par exemple DANE ou HPKP).
C’est une énorme arnaque, mais comme elle a été poussée par Google, ben on doit se la farcir…
CT a des défauts (par exemple il facilite le renseignement économique, en surveillant les certificats des concurrents) mais, si, il résoud un problème : avant, n'importe quelle AC pouvait émettre un certificat pour n'importe qui. Maintenant, elle peut toujours mais ça se voit.
Posté par gouttegd .
Évalué à 4.
Dernière modification le 04 décembre 2020 à 11:09.
Maintenant, elle peut toujours mais ça se voit.
Super. Et ça change quoi au juste ?
Mettons que mon site a un certificat émis par la CA X. La CA Y émet aussi un certificat pour mon domaine. Grâce à CT, tout le monde peut voir que deux CA ont émis un certificat pour mon domaine. Et après ?
CT ne dit pas quelle CA a émis le certificat illégitime (on ne peut pas se baser sur la date d’émission du certificat, le premier certificat n’est pas forcément le certificat légitime, par exemple si j’ai renouvellé mon certificat depuis que la CA frauduleuse a émis le sien). CT ne dit même pas si un des certificats est réellement illégitime — si ça se trouve c’est moi-même qui ai demandé un certificat à une autre CA, il y a des raisons parfaitement légitimes de vouloir faire ça.
Alors certes, moi je sais que la CA Y a émis un certificat frauduleux (c’est mon site, je sais encore à quelle CA je demande un certificat, je ne suis pas gâteux à ce point — pas encore, du moins). Mais à quoi ça me sert ? Tu crois que si je signale à Microsoft, Google, Mozilla, Apple que la CA Y a émis un certificat frauduleux ils vont la virer de la liste des CA de confiance ?
Les visiteurs qui tombent sur un site qui se fait passer par le mien grâce au certificat de la CA Y, ils sont protégés comment ? Par rapport à HPKP ou DANE, que Google au mieux a fait mine d’ignorer, voire a saboté activement ?
Non, Gemini ne recommande pas cela (tout le monde peut vérifier que le site de référence a un certificat Let's Encrypt), c'est juste l'opinion de DeVault.
C’est dans les spécifications, à la section 4.2, Server certificate validation :
Clients can validate TLS connections however they like (including not at all) but the strongly RECOMMENDED approach is to implement a lightweight "TOFU" certificate-pinning system which treats self-signed certificates as first- class citizens.
Je comprends que la spec recommande aux clients d'accepter les certificats auto-signés comme parfaitement valides. Ce n'est pas une recommandation pour les serveurs.
J'ai toujours trouvé ça ridicule que pendant longtemps les navigateurs web mettent une alerte qui fait peur pour un certificat auto-signé, mais ne disent rien pour les sites en http (ça a évolué depuis, maintenant les navigateurs affichent des avertissement si tu envois un formulaire avec un mot de passe en HTTP).
Et vu la proposition de Drew DeVault, à savoir de pin le certificat complet (pas seulement la clef publique), ça veut dire qu’un changement de certificat affichera un avertissement à l’utilisateur.
Autant dire que les administrateurs vont faire des certificats valident pour 1000 ans, et ne jamais les révoquer.
Oui, le but, c'est de distribuer de l'information. (Comme le Web à l'origine.) Par exemple une encyclopédie en ligne, une documentation, des textes politiques ou littéraires.
Any text following the leading "```" of a preformat toggle line which toggles preformatted mode on MAY be interpreted by the client as "alt text" pertaining to the preformatted text lines which follow the toggle line. Use of alt text is at the client's discretion, and simple clients may ignore it. Alt text is recommended for ASCII art or similar non-textual content which, for example, cannot be meaningfully understood when rendered through a screen reader or usefully indexed by a search engine.
Dans le format de Gemini (text/gemini) les liens sont séparés du texte, et il ne peut y en avoir qu’un seul par ligne. Ça donne un peu le même fonctionnement que le courriel :
Après, si on prend le premier exemple de md2gemini, on pourrait imaginer que quand un client voit <text>\n<lien avec titre>\n<text>, il affiche ça inline.
Le but est que l'utilisateur ne puisse pas être suivi facilement d'un site à l'autre.
Mais si l'utilisateur doit être authentifié, il y a une mécanique prévu. C'est à base de certificat (les logiciels clients sont incités à rendre ça simple), et la façon dont c'est gaulé permet de gérer une session sans avoir besoin de token comme ceux qui sont utilisés en cookie sur le web. (en gros : quand le serveur réponds qu'un certif est nécessaire, le client doit le fournir dans les requêtes suivantes)
C'est marrant, est ce que c'est utilisé quelque part? Je crois me souvenir qu'à une époque c'était utilisé pour déclarer ses impôts en France, si on faisait la déclaration depuis un autre ordinateur l'année suivant ça posait problème.
De mémoire c'était comme ça que marchait l'interface de StartSLL (un site qui fournissait des certificats gratuits avant Let's Encrypt), et c'était galère pour une utilisation ponctuelle.
Je crois me souvenir qu'à une époque c'était utilisé pour déclarer ses impôts en France, si on faisait la déclaration depuis un autre ordinateur l'année suivant ça posait problème.
Oui, ça a été utilisé par le fisc aux alentours de 2008–2010, et oui, ça a posé pas mal de problèmes. En gros ça ne marchait bien que dans le cas idéal (même machine utilisée d’une année sur l’autre, sans réinstallation entre deux déclarations, et un utilisateur qui n’oublie pas le mot de passe du fichier PKCS#12 contenant le certificat et sa clef privée). Dommage, un tout petit peu plus d’explications de la part du service des impôts aurait pu rendre ça viable.
C’est un des trucs qui aurait du être clairement expliqué, oui. « Vous aurez besoin de ce certificat pour votre déclaration de l’année prochaine, conservez-le précieusement et n’oubliez pas le mot de passe associé ».
Une partie du problème vient probablement de ce que l’interface de gestion des certificats clients est entièrement à la charge du navigateur, c’est hors de contrôle du site web visité.
Si le navigateur a une interface non-intuitive pour gérer les certificats (spoiler : c’est le cas de tous les navigateurs ; les certificats clients sont tellement peu usités que ceux qui s’en servent sont automatiquement supposés être des connaisseurs qui savent ce qu’ils font), ben… le site web qui choisit d’utiliser des certificats pour authentifier ses visiteurs ne peut pas y faire grand’chose, à part peut-être avoir une page d’aide la plus claire possible (ce qui n’était pas le cas, me semble-t-il, de impots.gouv.fr à l’époque où ils utilisaient ce système).
C'est pas simple non plus à implanter dans une application. Souvent, le serveur qui fait la terminaison TLS n'est pas celui qui est proche du service. Je ne connais pas aujourd'hui de méthode standarde d'interaction pour gérer des certificats clients depuis des script fcgi ou autres.
Dans Puppet, le reverse proxy a la charge de placer des en-têtes avec les bonnes informations (d’ailleurs le certificat du client est transmis au complet au backend).
En cherchant le code HTTP équivalent au 60 de Gemini (Client Certificate Required), j'ai trouvé le 496. Mais apparemment, c'est spécifique à Nginx.
En lisant cette partie sur l'authentification dans Gemini, ça m'a plutôt fait penser au système d'http avec le code 401. Mais avec un certif plutôt qu'un login/mdp.
# Discussion
Posté par Anonyme . Évalué à 5.
Il y a aussi eu une discussion sur Mastodon où Drew DeVault a notamment expliqué à Stéphane Bortzmeyer qu’il ne devrait pas utiliser de certificat signé par une CA.
Apparemment Gemini recommande de suivre le comportement Trust On First Use (TOFU) de SSH (ça me semble problématique, mais je ne suis pas un expert).
[^] # Re: Discussion
Posté par freem . Évalué à 6.
Le TOFU à ses inconvénients: si le site est frauduleux dès le début, on peut pas protéger. Si le site est un squat de domaine, idem.
Ceci dit, une faille dans la chaîne des CA, et c'est tous les maillons descendants qui sont cassés, on a déjà vu le cas, et pas qu'une fois.
En plus de ça, que risque-t-on?
Avec gemini, pas de cookies, pour commencer.
Et l'idée, c'est d'avoir des sites gemini simples, pas de cross-domain, pas de contenu qui s'exécute au hasard (dans l'esprit, hein, parce que je doute que ça soit impossible de le faire, me souviens plus)… contrairement au web.
Je pense personnellement que les chaînes de sécurités des CA sont d'une utilité plus que douteuse dans le cas d'un site type blog, ou le but est juste de communiquer sur un sujet qui intéresse l'auteur, ou qui permets le téléchargement d'un fichier.
Il n'y a pas de login, pas (besoin) de cookie, pas de langage turing-complet embarqué dans le document…
Pour ce qui est du typo-squatting… au final, le système de CA ne l'empêche pas non plus, il suffit de voir tous ces gestionnaires de paquets pour language de programmation qui se font exploiter.
Bref, sauf pour des sites sensibles, qui servent a interagir (type linuxfr), je ne vois pas trop l'intérêt des chaînes de certificats. Et même dans ce cas précis, je ne suis pas entièrement convaincu.
Bon, certes, dans le cas de ma banque, avoir un certificat qui soit validé par une autorité supérieure en laquelle j'ai confiance est un plus.
Mais justement… puis-je avoir confiance dans l'autorité certificatrice de ma banque? Ça serait mon gouvernement, peut-être (et encore, on pourrait arguer que certains gouvernements de certaines nations ne sont pas nécessairement dignes de confiance).
En l'occurrence, il s'agit de «Sectigo Limited». Tout semble indiquer une entreprise des USA, alors, la confiance, comment dire…
[^] # Re: Discussion
Posté par claudex . Évalué à 5.
Le TOFU empêche aussi d'avoir plusieurs instances qui répondent, sauf si elle partage le même secret (ce qui n'est pas terrible). Avec la chaîne des CA, tu peux en avoir deux certificats différents pour le même site et cela fonctionne (bon, souvent, on le fait plutôt par datacenter, sinon c'est trop le bordel).
Sinon, un avantage des CA actuellement, c'est les CRL et OCSP pour pouvoir révoquer une clef volée (bon, c'est un avantage assez léger vu que personne ne l'utilise).
Le problème, c'est surtout qu'il faut avoir confiance dans toutes les autorités installées sur ta machine.
« 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: Discussion
Posté par gouttegd . Évalué à 3.
Euh, présenter les CRL et OCSP comme un avantage des CA, c’est un peu fort, sachant que
Il a fallu inventer l’OCSP Stapling pour avoir un truc qui tienne à peu près la route et fasse à peu près ce qu’on attend.
Pour une fois que des technos pourries ne sont pas utilisées, je ne vais pas m’en plaindre, perso. Si Certificate Transparency pouvait connaître le même sort, ce serait parfait.
[^] # Re: Discussion
Posté par Anonyme . Évalué à 4.
C’est quoi le soucis avec CT ?
[^] # Re: Discussion
Posté par gouttegd . Évalué à 2.
Ça ne résout aucun des problèmes posés par le système des CA et ne sert en fait qu’à assoir un peu plus ce système en coupant l’herbe sous le pied à toute tentative facilitant l’utilisation de certificats non-émis par une CA du cartel (par exemple DANE ou HPKP).
C’est une énorme arnaque, mais comme elle a été poussée par Google, ben on doit se la farcir…
[^] # Re: Discussion
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 3.
CT a des défauts (par exemple il facilite le renseignement économique, en surveillant les certificats des concurrents) mais, si, il résoud un problème : avant, n'importe quelle AC pouvait émettre un certificat pour n'importe qui. Maintenant, elle peut toujours mais ça se voit.
Et ce n'est pas que Google, un RFC a été publié https://www.bortzmeyer.org/6962.html et la version normalisée est en cours https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ les objections étant surtout du détail https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ballot/
[^] # Re: Discussion
Posté par gouttegd . Évalué à 4. Dernière modification le 04 décembre 2020 à 11:09.
Super. Et ça change quoi au juste ?
Mettons que mon site a un certificat émis par la CA X. La CA Y émet aussi un certificat pour mon domaine. Grâce à CT, tout le monde peut voir que deux CA ont émis un certificat pour mon domaine. Et après ?
CT ne dit pas quelle CA a émis le certificat illégitime (on ne peut pas se baser sur la date d’émission du certificat, le premier certificat n’est pas forcément le certificat légitime, par exemple si j’ai renouvellé mon certificat depuis que la CA frauduleuse a émis le sien). CT ne dit même pas si un des certificats est réellement illégitime — si ça se trouve c’est moi-même qui ai demandé un certificat à une autre CA, il y a des raisons parfaitement légitimes de vouloir faire ça.
Alors certes, moi je sais que la CA Y a émis un certificat frauduleux (c’est mon site, je sais encore à quelle CA je demande un certificat, je ne suis pas gâteux à ce point — pas encore, du moins). Mais à quoi ça me sert ? Tu crois que si je signale à Microsoft, Google, Mozilla, Apple que la CA Y a émis un certificat frauduleux ils vont la virer de la liste des CA de confiance ?
Les visiteurs qui tombent sur un site qui se fait passer par le mien grâce au certificat de la CA Y, ils sont protégés comment ? Par rapport à HPKP ou DANE, que Google au mieux a fait mine d’ignorer, voire a saboté activement ?
[^] # Re: Discussion
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 5.
Non, Gemini ne recommande pas cela (tout le monde peut vérifier que le site de référence a un certificat Let's Encrypt), c'est juste l'opinion de DeVault.
[^] # Re: Discussion
Posté par Anonyme . Évalué à 3.
C’est dans les spécifications, à la section 4.2, Server certificate validation :
[^] # Re: Discussion
Posté par Wawet76 . Évalué à 3.
Je comprends que la spec recommande aux clients d'accepter les certificats auto-signés comme parfaitement valides. Ce n'est pas une recommandation pour les serveurs.
J'ai toujours trouvé ça ridicule que pendant longtemps les navigateurs web mettent une alerte qui fait peur pour un certificat auto-signé, mais ne disent rien pour les sites en http (ça a évolué depuis, maintenant les navigateurs affichent des avertissement si tu envois un formulaire avec un mot de passe en HTTP).
[^] # Re: Discussion
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 2.
Justement, depuis Firefox 83 tu peux faire afficher une alerte pour tous les sites sans certificats.
[^] # Re: Discussion
Posté par barmic 🦦 . Évalué à 3.
Tu fais comment avec TOFU si ton serveur crash du coup ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Discussion
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Tu t'en fous !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Discussion
Posté par gUI (Mastodon) . Évalué à 2.
T'es fou !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Discussion
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 4.
C'est en effet l'un des gros problèmes du TOFU, le remplacement de clé.
[^] # Re: Discussion
Posté par Anonyme . Évalué à 8.
Et vu la proposition de Drew DeVault, à savoir de pin le certificat complet (pas seulement la clef publique), ça veut dire qu’un changement de certificat affichera un avertissement à l’utilisateur.
Autant dire que les administrateurs vont faire des certificats valident pour 1000 ans, et ne jamais les révoquer.
# le but ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
J'ai du mal à voir le but de gemini, si il n'y a pas moyen d'identifier une personne, toute application web qui authentifie ne peut plus marcher.
Il ne reste que les sites d'information public sans interaction (pas de commentaire ?) et sans image (?).
J'ai l'impression que l'on ne peut faire que des sites statiques sans image, et sans lien hypertexte ?!
"La première sécurité est la liberté"
[^] # Re: le but ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 3.
Oui, le but, c'est de distribuer de l'information. (Comme le Web à l'origine.) Par exemple une encyclopédie en ligne, une documentation, des textes politiques ou littéraires.
[^] # Re: le but ?
Posté par barmic 🦦 . Évalué à 6.
Même l'encyclopédie de Diderot avait des images. Ça me parait plutôt pratique d'avoir image et schémas pour distribuer de l'information.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: le but ?
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 2.
Mais l'encyclopédie de Diderot était-elle elle-même pratique à distribuer ?
(tu peux tout à fait mettre des liens vers des images, le client pourra choisir de les afficher à même la page, comme sur l'exemple ci-dessous)
[^] # Re: le but ?
Posté par Anonyme . Évalué à 6.
Et c’est quoi l’équivalent du
altdans Gemini du coup ?Même question pour l’absence d’hypertexte qui semble pourtant être une bonne chose du point de vue de l’accessibilité.
Comment les lecteurs d’écrans s’en sorte avec Gemini et ses liens séparés du texte ?
[^] # Re: le but ?
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 3.
Voilà ce qu'en dit (le brouillon de) la spec officielle :
[^] # Re: le but ?
Posté par barmic 🦦 . Évalué à 3.
Ben il me semble qu'il était à l'état de l'art de son époque.
D'acc c'est le billet donné en haut qui m'a induit en erreur.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: le but ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Que veut-tu dire par l'absence d'hypertexte ? Il y a des liens (un par ligne ?), ce n'est pas ça l'hypertexte pour toi ?
"La première sécurité est la liberté"
[^] # Re: le but ?
Posté par Anonyme . Évalué à 4.
C’est expliqué succinctement dans What is HyperText.
Dans le format de Gemini (
text/gemini) les liens sont séparés du texte, et il ne peut y en avoir qu’un seul par ligne. Ça donne un peu le même fonctionnement que le courriel :Après, si on prend le premier exemple de
md2gemini, on pourrait imaginer que quand un client voit<text>\n<lien avec titre>\n<text>, il affiche ça inline.[^] # Re: le but ?
Posté par Wawet76 . Évalué à 5.
Le but est que l'utilisateur ne puisse pas être suivi facilement d'un site à l'autre.
Mais si l'utilisateur doit être authentifié, il y a une mécanique prévu. C'est à base de certificat (les logiciels clients sont incités à rendre ça simple), et la façon dont c'est gaulé permet de gérer une session sans avoir besoin de token comme ceux qui sont utilisés en cookie sur le web. (en gros : quand le serveur réponds qu'un certif est nécessaire, le client doit le fournir dans les requêtes suivantes)
[^] # Re: le but ?
Posté par Anonyme . Évalué à 4.
À noter que ce comportement n’est pas propre à Gemini, ça marche pareil avec HTTPS.
[^] # Re: le but ?
Posté par ted (site web personnel) . Évalué à 4.
C'est marrant, est ce que c'est utilisé quelque part? Je crois me souvenir qu'à une époque c'était utilisé pour déclarer ses impôts en France, si on faisait la déclaration depuis un autre ordinateur l'année suivant ça posait problème.
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: le but ?
Posté par Anonyme . Évalué à 3.
C’est implémenté dans Nginx et Apache et c’est la méthode utilisé par Puppet pour authentifier les agents, et une des méthodes d’authentification disponible dans Vault.
Ça c’est juste des exemples qui me viennent de tête.
[^] # Re: le but ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Le problème est que l'installation du certificat n'est pas pratique du tout. j'imagine que coupler cela avec une clef usb serait plus simple.
"La première sécurité est la liberté"
[^] # Re: le but ?
Posté par Wawet76 . Évalué à 3.
De mémoire c'était comme ça que marchait l'interface de StartSLL (un site qui fournissait des certificats gratuits avant Let's Encrypt), et c'était galère pour une utilisation ponctuelle.
[^] # Re: le but ?
Posté par gouttegd . Évalué à 3.
Oui, ça a été utilisé par le fisc aux alentours de 2008–2010, et oui, ça a posé pas mal de problèmes. En gros ça ne marchait bien que dans le cas idéal (même machine utilisée d’une année sur l’autre, sans réinstallation entre deux déclarations, et un utilisateur qui n’oublie pas le mot de passe du fichier PKCS#12 contenant le certificat et sa clef privée). Dommage, un tout petit peu plus d’explications de la part du service des impôts aurait pu rendre ça viable.
[^] # Re: le but ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Quelle probabilité de se rappeler d'un mot de passe utilisé une fois par an ?
"La première sécurité est la liberté"
[^] # Re: le but ?
Posté par gouttegd . Évalué à 3.
C’est un des trucs qui aurait du être clairement expliqué, oui. « Vous aurez besoin de ce certificat pour votre déclaration de l’année prochaine, conservez-le précieusement et n’oubliez pas le mot de passe associé ».
[^] # Re: le but ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Cela reste un ux/cx tout pourri :)
"La première sécurité est la liberté"
[^] # Re: le but ?
Posté par gouttegd . Évalué à 5.
Une partie du problème vient probablement de ce que l’interface de gestion des certificats clients est entièrement à la charge du navigateur, c’est hors de contrôle du site web visité.
Si le navigateur a une interface non-intuitive pour gérer les certificats (spoiler : c’est le cas de tous les navigateurs ; les certificats clients sont tellement peu usités que ceux qui s’en servent sont automatiquement supposés être des connaisseurs qui savent ce qu’ils font), ben… le site web qui choisit d’utiliser des certificats pour authentifier ses visiteurs ne peut pas y faire grand’chose, à part peut-être avoir une page d’aide la plus claire possible (ce qui n’était pas le cas, me semble-t-il, de impots.gouv.fr à l’époque où ils utilisaient ce système).
[^] # Re: le but ?
Posté par Pol' uX (site web personnel) . Évalué à 3.
C'est pas simple non plus à implanter dans une application. Souvent, le serveur qui fait la terminaison TLS n'est pas celui qui est proche du service. Je ne connais pas aujourd'hui de méthode standarde d'interaction pour gérer des certificats clients depuis des script fcgi ou autres.
Adhérer à l'April, ça vous tente ?
[^] # Re: le but ?
Posté par Anonyme . Évalué à 2.
Dans Puppet, le reverse proxy a la charge de placer des en-têtes avec les bonnes informations (d’ailleurs le certificat du client est transmis au complet au backend).
[^] # Re: le but ?
Posté par barmic 🦦 . Évalué à 3.
La terminaison TLS positionne les entêtes qui t'intéresse (et vire les éventuelles passé par un client coquin).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: le but ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
J'imagine qu'il faudra un plugin correctement fait avant de donner l'idée au navigateur de le mettre en place nativement.
"La première sécurité est la liberté"
[^] # Re: le but ?
Posté par Wawet76 . Évalué à 2.
En cherchant le code HTTP équivalent au 60 de Gemini (Client Certificate Required), j'ai trouvé le 496. Mais apparemment, c'est spécifique à Nginx.
En lisant cette partie sur l'authentification dans Gemini, ça m'a plutôt fait penser au système d'http avec le code 401. Mais avec un certif plutôt qu'un login/mdp.
[^] # Re: le but ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 2.
Oui, normalement, en HTTPS, la demande d'un certificat client est faite par TLS, pas par HTTP. (Message CertificateRequest, RFC 8446, section 4.3.2.)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.