Le Tue, 05 Aug 2014 10:39:39 +0200, Didier Couderc a écrit :
Oui, dans "Mission Impossible" (ou un autre documentaire, je sais plus), avec la barre d'avancement qui semble figée, et le garde qui arrive dans le couloir, et ouvre brusquement la porte, et trouve le bureau vide, ouf, la copie était terminée, mais quel suspense !
de toutes façon dans les films tu as vu les (bons) héros taper un mot de passe ? C'est pas nouveau : https://linuxfr.org/news/cl%C3%A9-web-usb-et-s%C3%A9curit%C3%A9
Le Tue, 05 Aug 2014 10:39:39 +0200, Didier Couderc a écrit :
Oui, dans "Mission Impossible" (ou un autre documentaire, je sais plus),
avec la barre d'avancement qui semble figée, et le garde qui arrive dans
le couloir, et ouvre brusquement la porte, et trouve le bureau vide,
ouf, la copie était terminée, mais quel suspense !
de toutes façon dans les films tu as vu les (bons) héros taper un mot de
passe ?
C'est pas nouveau :
https://linuxfr.org/news/cl%C3%A9-web-usb-et-s%C3%A9curit%C3%A9
Le Tue, 05 Aug 2014 10:39:39 +0200, Didier Couderc a écrit :
Oui, dans "Mission Impossible" (ou un autre documentaire, je sais plus), avec la barre d'avancement qui semble figée, et le garde qui arrive dans le couloir, et ouvre brusquement la porte, et trouve le bureau vide, ouf, la copie était terminée, mais quel suspense !
de toutes façon dans les films tu as vu les (bons) héros taper un mot de passe ? C'est pas nouveau : https://linuxfr.org/news/cl%C3%A9-web-usb-et-s%C3%A9curit%C3%A9
Nicolas George
Sergio , dans le message <53e0f2aa$0$3635$, a écrit :
Le cordonnier le plus mal chaussé ?
Non, juste le modèle de sécurité de TLS (HTTPS) qui est complètement pourri, et Firefox complètement crétin de chercher à le promouvoir.
Sergio , dans le message <53e0f2aa$0$3635$426a34cc@news.free.fr>, a
écrit :
Le cordonnier le plus mal chaussé ?
Non, juste le modèle de sécurité de TLS (HTTPS) qui est complètement pourri,
et Firefox complètement crétin de chercher à le promouvoir.
Pzarceque je n'en connais qu'une. Quelle autre alternative à PKIX et ses CA peux-tu nous indiquer ?
Ça m'intéresse fortement.
-- Les simplifications c'est trop compliqué
Nicolas George
Erwan David , dans le message , a écrit :
Pzarceque je n'en connais qu'une. Quelle autre alternative à PKIX et ses CA peux-tu nous indiquer ?
Pour un utilisateur avancé, l'équivalent de ~/.ssh/known_hosts, qui existe depuis facilement une vingtaine d'années. Ça s'implémente purement côté client, et ça laisse plein de place pour mettre en place des architectures tierces.
L'architecture actuelle, ou celle que tu as évoquée qui veut la remplacer, sont moisies à la base parce qu'elles veulent prouver la correspondance entre le no de domaine et le serveur contacté, ce qui pour la plupart des gens est totalement inutile : d'une part, on ne fait pas de MitM sur un particulier, et d'autre part, si le gus se retrouve sur paypaI.ru et ne fait pas attention, il aura un beau cadenas vert parce que le certificat est le bon.
Il serait bien plus intelligent d'avoir au niveau de TLS uniquement la crypto, et de faire des requêtes séparées auprès de différentes autorités pour s'assurer de la légitimité du certificat. À charge pour l'utilisateur de choisir les bonnes autorités, celles qui fournissent une information utile (« ce site est honnête ») plutôt qu'un résultat inutile.
Erwan David , dans le message <87egwug8pr.fsf@bibi.depot.rail.eu.org>, a
écrit :
Pzarceque je n'en connais qu'une. Quelle autre alternative à PKIX et ses
CA peux-tu nous indiquer ?
Pour un utilisateur avancé, l'équivalent de ~/.ssh/known_hosts, qui existe
depuis facilement une vingtaine d'années. Ça s'implémente purement côté
client, et ça laisse plein de place pour mettre en place des architectures
tierces.
L'architecture actuelle, ou celle que tu as évoquée qui veut la remplacer,
sont moisies à la base parce qu'elles veulent prouver la correspondance
entre le no de domaine et le serveur contacté, ce qui pour la plupart des
gens est totalement inutile : d'une part, on ne fait pas de MitM sur un
particulier, et d'autre part, si le gus se retrouve sur paypaI.ru et ne fait
pas attention, il aura un beau cadenas vert parce que le certificat est le
bon.
Il serait bien plus intelligent d'avoir au niveau de TLS uniquement la
crypto, et de faire des requêtes séparées auprès de différentes autorités
pour s'assurer de la légitimité du certificat. À charge pour l'utilisateur
de choisir les bonnes autorités, celles qui fournissent une information
utile (« ce site est honnête ») plutôt qu'un résultat inutile.
Pzarceque je n'en connais qu'une. Quelle autre alternative à PKIX et ses CA peux-tu nous indiquer ?
Pour un utilisateur avancé, l'équivalent de ~/.ssh/known_hosts, qui existe depuis facilement une vingtaine d'années. Ça s'implémente purement côté client, et ça laisse plein de place pour mettre en place des architectures tierces.
L'architecture actuelle, ou celle que tu as évoquée qui veut la remplacer, sont moisies à la base parce qu'elles veulent prouver la correspondance entre le no de domaine et le serveur contacté, ce qui pour la plupart des gens est totalement inutile : d'une part, on ne fait pas de MitM sur un particulier, et d'autre part, si le gus se retrouve sur paypaI.ru et ne fait pas attention, il aura un beau cadenas vert parce que le certificat est le bon.
Il serait bien plus intelligent d'avoir au niveau de TLS uniquement la crypto, et de faire des requêtes séparées auprès de différentes autorités pour s'assurer de la légitimité du certificat. À charge pour l'utilisateur de choisir les bonnes autorités, celles qui fournissent une information utile (« ce site est honnête ») plutôt qu'un résultat inutile.
Erwan David
Nicolas George <nicolas$ écrivait :
Erwan David , dans le message , a écrit :
Pzarceque je n'en connais qu'une. Quelle autre alternative à PKIX et ses CA peux-tu nous indiquer ?
Pour un utilisateur avancé, l'équivalent de ~/.ssh/known_hosts, qui existe depuis facilement une vingtaine d'années. Ça s'implémente purement côté client, et ça laisse plein de place pour mettre en place des architectures tierces.
Ok, maintenant explique comment je récupère la clef de linuxfr.org Le roblème n'est pas de se connecter aux sites connus, mais aux sites pas encore connus, avec une confiance minimale
L'architecture actuelle, ou celle que tu as évoquée qui veut la remplacer, sont moisies à la base parce qu'elles veulent prouver la correspondance entre le no de domaine et le serveur contacté, ce qui pour la plupart des gens est totalement inutile : d'une part, on ne fait pas de MitM sur un particulier,
On fait *tout* sur un particulier, ou plutôt sur un ensemble de particuliers...
et d'autre part, si le gus se retrouve sur paypaI.ru et ne fait pas attention, il aura un beau cadenas vert parce que le certificat est le bon.
Ça c'est un autre problème. Que ta collection de certificats de sites connus ne va pas résoudre pour autant...
Il serait bien plus intelligent d'avoir au niveau de TLS uniquement la crypto, et de faire des requêtes séparées auprès de différentes autorités pour s'assurer de la légitimité du certificat. À charge pour l'utilisateur de choisir les bonnes autorités, celles qui fournissent une information utile (« ce site est honnête ») plutôt qu'un résultat inutile.
Là tu reste dans le modèle PKIX mais avec moins d'autorités de certification...
DANE permet en plus de dire mon autorité c'est celle là, pas une autre.
-- Les simplifications c'est trop compliqué
Nicolas George <nicolas$george@salle-s.org> écrivait :
Erwan David , dans le message <87egwug8pr.fsf@bibi.depot.rail.eu.org>, a
écrit :
Pzarceque je n'en connais qu'une. Quelle autre alternative à PKIX et ses
CA peux-tu nous indiquer ?
Pour un utilisateur avancé, l'équivalent de ~/.ssh/known_hosts, qui existe
depuis facilement une vingtaine d'années. Ça s'implémente purement côté
client, et ça laisse plein de place pour mettre en place des architectures
tierces.
Ok, maintenant explique comment je récupère la clef de linuxfr.org
Le roblème n'est pas de se connecter aux sites connus, mais aux sites
pas encore connus, avec une confiance minimale
L'architecture actuelle, ou celle que tu as évoquée qui veut la remplacer,
sont moisies à la base parce qu'elles veulent prouver la correspondance
entre le no de domaine et le serveur contacté, ce qui pour la plupart des
gens est totalement inutile : d'une part, on ne fait pas de MitM sur un
particulier,
On fait *tout* sur un particulier, ou plutôt sur un ensemble de
particuliers...
et d'autre part, si le gus se retrouve sur paypaI.ru et ne fait
pas attention, il aura un beau cadenas vert parce que le certificat est le
bon.
Ça c'est un autre problème. Que ta collection de certificats de sites
connus ne va pas résoudre pour autant...
Il serait bien plus intelligent d'avoir au niveau de TLS uniquement la
crypto, et de faire des requêtes séparées auprès de différentes autorités
pour s'assurer de la légitimité du certificat. À charge pour l'utilisateur
de choisir les bonnes autorités, celles qui fournissent une information
utile (« ce site est honnête ») plutôt qu'un résultat inutile.
Là tu reste dans le modèle PKIX mais avec moins d'autorités de
certification...
DANE permet en plus de dire mon autorité c'est celle là, pas une autre.
Pzarceque je n'en connais qu'une. Quelle autre alternative à PKIX et ses CA peux-tu nous indiquer ?
Pour un utilisateur avancé, l'équivalent de ~/.ssh/known_hosts, qui existe depuis facilement une vingtaine d'années. Ça s'implémente purement côté client, et ça laisse plein de place pour mettre en place des architectures tierces.
Ok, maintenant explique comment je récupère la clef de linuxfr.org Le roblème n'est pas de se connecter aux sites connus, mais aux sites pas encore connus, avec une confiance minimale
L'architecture actuelle, ou celle que tu as évoquée qui veut la remplacer, sont moisies à la base parce qu'elles veulent prouver la correspondance entre le no de domaine et le serveur contacté, ce qui pour la plupart des gens est totalement inutile : d'une part, on ne fait pas de MitM sur un particulier,
On fait *tout* sur un particulier, ou plutôt sur un ensemble de particuliers...
et d'autre part, si le gus se retrouve sur paypaI.ru et ne fait pas attention, il aura un beau cadenas vert parce que le certificat est le bon.
Ça c'est un autre problème. Que ta collection de certificats de sites connus ne va pas résoudre pour autant...
Il serait bien plus intelligent d'avoir au niveau de TLS uniquement la crypto, et de faire des requêtes séparées auprès de différentes autorités pour s'assurer de la légitimité du certificat. À charge pour l'utilisateur de choisir les bonnes autorités, celles qui fournissent une information utile (« ce site est honnête ») plutôt qu'un résultat inutile.
Là tu reste dans le modèle PKIX mais avec moins d'autorités de certification...
DANE permet en plus de dire mon autorité c'est celle là, pas une autre.
-- Les simplifications c'est trop compliqué
Nicolas George
Erwan David , dans le message , a écrit :
Ok, maintenant explique comment je récupère la clef de linuxfr.org
Exactement comme maintenant : tu prends la clef signée par une entité commerciale à la rigueur douteuse et qui ne s'engage en rien.
Ou alors tu arrêtes de raisonner en « toutes choses égales par ailleurs » et tu obtiens la clef par l'autorité de ton choix.
Au final, toute architecture se résume en une forme ou une autre de Web-of-Trust, mais ce que je préconise est d'une part plus robuste (car réduit les changements de clefs intempestifs) et surtout donne le CHOIX à l'utilisateur/
Là tu reste dans le modèle PKIX mais avec moins d'autorités de certification...
Non. Le défaut fondamental que je critique, c'est que le certificat x509 vienne avec son UNIQUE autorité. Le certificat devrait être distribué séparément, et surtout il devrait être possible d'avoir plusieurs certifications pour la même clef et le même site.
DANE permet en plus de dire mon autorité c'est celle là, pas une autre.
Ce qui est plutôt une aggravation du problème.
Erwan David , dans le message <87a97ig5gl.fsf@bibi.depot.rail.eu.org>, a
écrit :
Ok, maintenant explique comment je récupère la clef de linuxfr.org
Exactement comme maintenant : tu prends la clef signée par une entité
commerciale à la rigueur douteuse et qui ne s'engage en rien.
Ou alors tu arrêtes de raisonner en « toutes choses égales par ailleurs » et
tu obtiens la clef par l'autorité de ton choix.
Au final, toute architecture se résume en une forme ou une autre de
Web-of-Trust, mais ce que je préconise est d'une part plus robuste (car
réduit les changements de clefs intempestifs) et surtout donne le CHOIX à
l'utilisateur/
Là tu reste dans le modèle PKIX mais avec moins d'autorités de
certification...
Non. Le défaut fondamental que je critique, c'est que le certificat x509
vienne avec son UNIQUE autorité. Le certificat devrait être distribué
séparément, et surtout il devrait être possible d'avoir plusieurs
certifications pour la même clef et le même site.
DANE permet en plus de dire mon autorité c'est celle là, pas une autre.
Ok, maintenant explique comment je récupère la clef de linuxfr.org
Exactement comme maintenant : tu prends la clef signée par une entité commerciale à la rigueur douteuse et qui ne s'engage en rien.
Ou alors tu arrêtes de raisonner en « toutes choses égales par ailleurs » et tu obtiens la clef par l'autorité de ton choix.
Au final, toute architecture se résume en une forme ou une autre de Web-of-Trust, mais ce que je préconise est d'une part plus robuste (car réduit les changements de clefs intempestifs) et surtout donne le CHOIX à l'utilisateur/
Là tu reste dans le modèle PKIX mais avec moins d'autorités de certification...
Non. Le défaut fondamental que je critique, c'est que le certificat x509 vienne avec son UNIQUE autorité. Le certificat devrait être distribué séparément, et surtout il devrait être possible d'avoir plusieurs certifications pour la même clef et le même site.
DANE permet en plus de dire mon autorité c'est celle là, pas une autre.
