le 24 novembre 2010 :
http://www.numerama.com/magazine/17443-la-dcri-espionnerait-deja-des-ordinateurs-a-distance.html
Selon le Canard Enchaîné les services de renseignements intérieurs
pratiqueraient déjà des captations de données informatique à distance
dans le cadre d'enquêtes administratives. Sans attendre le projet de loi
LOPPSI qui doit autoriser cette pratique exclusivement sous le contrôle
du juge d'instruction.
L'article 23 du projet de loi Loppsi, dont l'examen en seconde lecture a
été repoussé à la mi-décembre, prévoit que la police judiciaire peut
"mettre en place un dispositif technique ayant pour objet, sans le
consentement des intéressés, d’accéder, en tous lieux, à des données
informatiques, de les enregistrer, les conserver et les transmettre,
telles qu’elles s’affichent sur un écran pour l’utilisateur d’un système
de traitement automatisé de données ou telles qu’il les y introduit par
saisie de caractères".
Il précise qu'il est possible de procéder à "la transmission par un
réseau de communications électroniques de ce dispositif", le tout étant
strictement encadré sous le contrôle du juge d'instruction, qui est le
seul habilité à autoriser ces opérations, pour une durée définie, et
avec un certain nombre de conditions très détaillées.
Or le Canard Enchaîné accuse ce mercredi la Direction Centrale du
Renseignement Intérieur (DCRI) de procéder déjà à un espionnage
d'ordinateurs privés à distance. Dans une dépêche, l'AFP indique que la
DCRI a renvoyé ses questions vers la direction générale de la police
nationale (DGPN), laquelle n'a pas répondu.
Ainsi les services de police n'auraient pas attendu la loi pour
installer les mouchards, et le feraient sans aucun encadrement
juridictionnel. L'agence cite le Canard Enchaîné, qui indique selon un
hacker de la DCRI que ces opérations seraient réalisées "en off,
directement avec un opérateur [à qui] on demande l'adresse informatique
de l'ordinateur à ausculter".
De quoi ajouter de l'eau à notre moulin, lorsque nous demandions
pourquoi les opérateurs télécoms sont épargnés par la polémique dans
l'affaire des factures détaillées de journalistes, obtenues hors de tout
cadre légal.
Je préfèrerais que mon navigateur enregistre les certificats de tous les sites que je consulte, et me prévienne en cas de modification bizarre (par exemple lorsqu'un site change de certificat avant expiration, ou change de CA), mais ça demande davantage de travail.
https://addons.mozilla.org/en-US/firefox/addon/6415 https://addons.mozilla.org/en-US/firefox/addon/7974/ -- Kevin
Le 07-01-2011, A. Caspis <a_caspis@yahoo.com> a écrit :
Je préfèrerais que mon navigateur enregistre les
certificats de tous les sites que je consulte, et me prévienne
en cas de modification bizarre (par exemple lorsqu'un site
change de certificat avant expiration, ou change de CA),
mais ça demande davantage de travail.
https://addons.mozilla.org/en-US/firefox/addon/6415
https://addons.mozilla.org/en-US/firefox/addon/7974/
--
Kevin
Je préfèrerais que mon navigateur enregistre les certificats de tous les sites que je consulte, et me prévienne en cas de modification bizarre (par exemple lorsqu'un site change de certificat avant expiration, ou change de CA), mais ça demande davantage de travail.
https://addons.mozilla.org/en-US/firefox/addon/6415 https://addons.mozilla.org/en-US/firefox/addon/7974/ -- Kevin
Kevin Denis
Le 07-01-2011, Stephane Catteau a écrit :
client avec la clef du serveur, puisque, justement, il n'a pas la clef du serveur.
Bien sur que si. Si le proxy met sa réponse en attente, le temps que le serveur ait lui-même répondu, il aura la clé gentiment apportée sur un plateau d'argent par le serveur, ce qui ne ralentira pas des masses la connexions. Et ça marche dans les deux sens, il suffit que le proxy attende la réponse avant de répondre lui-même.
C'est une lecture audacieuse des specs d'échange des clés. Ceci dit, si tu as raison et que tu sait le faire, publies immédiatement, cela va intéresser énormément de monde. -- Kevin
Le 07-01-2011, Stephane Catteau <steph.nospam@sc4x.net> a écrit :
client avec la clef du serveur, puisque, justement, il n'a pas la clef du
serveur.
Bien sur que si. Si le proxy met sa réponse en attente, le temps que
le serveur ait lui-même répondu, il aura la clé gentiment apportée sur
un plateau d'argent par le serveur, ce qui ne ralentira pas des masses
la connexions. Et ça marche dans les deux sens, il suffit que le proxy
attende la réponse avant de répondre lui-même.
C'est une lecture audacieuse des specs d'échange des clés.
Ceci dit, si tu as raison et que tu sait le faire, publies immédiatement,
cela va intéresser énormément de monde.
--
Kevin
client avec la clef du serveur, puisque, justement, il n'a pas la clef du serveur.
Bien sur que si. Si le proxy met sa réponse en attente, le temps que le serveur ait lui-même répondu, il aura la clé gentiment apportée sur un plateau d'argent par le serveur, ce qui ne ralentira pas des masses la connexions. Et ça marche dans les deux sens, il suffit que le proxy attende la réponse avant de répondre lui-même.
C'est une lecture audacieuse des specs d'échange des clés. Ceci dit, si tu as raison et que tu sait le faire, publies immédiatement, cela va intéresser énormément de monde. -- Kevin
Oui, entre-temps j'ai refait le tour de la question et trouvé aussi: CertWatch https://addons.mozilla.org/en-US/firefox/addon/155126/ Conspiracy https://addons.mozilla.org/en-US/firefox/addon/107867/ SignatureCheck https://addons.mozilla.org/en-US/firefox/addon/261955/
Du coup, avec cette abondance de choix, je ne sais pas lequel choisir ! Quiconque a les moyens de bidouiller des certificats à la volée sera certainement tenté de diffuser aussi un add-on de ce genre, piégé.
Finalement l'évaluation obligatoire des logiciels de sécurité par le gouvernement avait du bon :-)
Oui, entre-temps j'ai refait le tour de la question et trouvé aussi:
CertWatch https://addons.mozilla.org/en-US/firefox/addon/155126/
Conspiracy https://addons.mozilla.org/en-US/firefox/addon/107867/
SignatureCheck https://addons.mozilla.org/en-US/firefox/addon/261955/
Du coup, avec cette abondance de choix, je ne sais pas
lequel choisir ! Quiconque a les moyens de bidouiller des
certificats à la volée sera certainement tenté de diffuser
aussi un add-on de ce genre, piégé.
Finalement l'évaluation obligatoire des logiciels de
sécurité par le gouvernement avait du bon :-)
Oui, entre-temps j'ai refait le tour de la question et trouvé aussi: CertWatch https://addons.mozilla.org/en-US/firefox/addon/155126/ Conspiracy https://addons.mozilla.org/en-US/firefox/addon/107867/ SignatureCheck https://addons.mozilla.org/en-US/firefox/addon/261955/
Du coup, avec cette abondance de choix, je ne sais pas lequel choisir ! Quiconque a les moyens de bidouiller des certificats à la volée sera certainement tenté de diffuser aussi un add-on de ce genre, piégé.
Finalement l'évaluation obligatoire des logiciels de sécurité par le gouvernement avait du bon :-)
AC
JKB
Le Fri, 07 Jan 2011 21:33:22 +0100, A. Caspis écrivait :
Erwan David wrote:
Par ailleurs le modèle estfoutu par terre par la térachiée de certificat pré installés dans les navigateurs : on devrait commencer avec 0 certificats et n'ajouter que ceux en lesquels on a confiance...
Oui, et certains le font: https://blog.torproject.org/blog/life-without-ca
C'est le cas de CSWB sous OpenVMS. Et tu dois rajouter les certificats à la main (CSWB n'a pas de fonction pour l'installer automatiquement).
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Fri, 07 Jan 2011 21:33:22 +0100,
A. Caspis <a_caspis@yahoo.com> écrivait :
Erwan David wrote:
Par ailleurs le modèle estfoutu par terre par la térachiée de certificat
pré installés dans les navigateurs : on devrait commencer avec 0
certificats et n'ajouter que ceux en lesquels on a confiance...
Oui, et certains le font:
https://blog.torproject.org/blog/life-without-ca
C'est le cas de CSWB sous OpenVMS. Et tu dois rajouter les
certificats à la main (CSWB n'a pas de fonction pour l'installer
automatiquement).
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Fri, 07 Jan 2011 21:33:22 +0100, A. Caspis écrivait :
Erwan David wrote:
Par ailleurs le modèle estfoutu par terre par la térachiée de certificat pré installés dans les navigateurs : on devrait commencer avec 0 certificats et n'ajouter que ceux en lesquels on a confiance...
Oui, et certains le font: https://blog.torproject.org/blog/life-without-ca
C'est le cas de CSWB sous OpenVMS. Et tu dois rajouter les certificats à la main (CSWB n'a pas de fonction pour l'installer automatiquement).
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
xavier
Sylvain POURRE wrote:
Dans ce cas, l'utilisation d'un VPN me semble particulièrement justifiée.
Sans être parano, la première chose que je fais lirsque je me connecte sur un réseau public, est de monter le VPN. Ne serait-ce que pour avoir accès à des services standard mais parfois filtrés sur les HotSpots.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Dans ce cas, l'utilisation d'un VPN me semble particulièrement justifiée.
Sans être parano, la première chose que je fais lirsque je me connecte
sur un réseau public, est de monter le VPN. Ne serait-ce que pour avoir
accès à des services standard mais parfois filtrés sur les HotSpots.
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
Dans ce cas, l'utilisation d'un VPN me semble particulièrement justifiée.
Sans être parano, la première chose que je fais lirsque je me connecte sur un réseau public, est de monter le VPN. Ne serait-ce que pour avoir accès à des services standard mais parfois filtrés sur les HotSpots.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Loic Restoux
Le 08 janv., a 21:56, Xavier papotait :
Sans être parano, la première chose que je fais lirsque je me connecte sur un réseau public, est de monter le VPN. Ne serait-ce que pour avoir accès à des services standard mais parfois filtrés sur les HotSpots.
Ce qui ne semble pas marcher à tous les coups. :) http://sid.rstack.org/blog/index.php/444-insecurity-enforced
-- No fortunes found
Le 08 janv., a 21:56, Xavier papotait :
Sans être parano, la première chose que je fais lirsque je me connecte
sur un réseau public, est de monter le VPN. Ne serait-ce que pour avoir
accès à des services standard mais parfois filtrés sur les HotSpots.
Ce qui ne semble pas marcher à tous les coups. :)
http://sid.rstack.org/blog/index.php/444-insecurity-enforced
Sans être parano, la première chose que je fais lirsque je me connecte sur un réseau public, est de monter le VPN. Ne serait-ce que pour avoir accès à des services standard mais parfois filtrés sur les HotSpots.
Ce qui ne semble pas marcher à tous les coups. :) http://sid.rstack.org/blog/index.php/444-insecurity-enforced
-- No fortunes found
xavier
Loic Restoux wrote:
Ce qui ne semble pas marcher à tous les coups. :) http://sid.rstack.org/blog/index.php/444-insecurity-enforced
Arf, ça relève plus du bug, tout de même...
Mais il ne serait pas impossible qu'un HotSpot ne laisse pas passer udp/4500, udp/500, udp/1701 et éventuellement ip/88 nécessaires à L2TP/IPSec, parce qu'on ne parlera pas de PPTP, soyons sérieux :)
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Loic Restoux <lrestoux@free.fr> wrote:
Ce qui ne semble pas marcher à tous les coups. :)
http://sid.rstack.org/blog/index.php/444-insecurity-enforced
Arf, ça relève plus du bug, tout de même...
Mais il ne serait pas impossible qu'un HotSpot ne laisse pas passer
udp/4500, udp/500, udp/1701 et éventuellement ip/88 nécessaires à
L2TP/IPSec, parce qu'on ne parlera pas de PPTP, soyons sérieux :)
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
Ce qui ne semble pas marcher à tous les coups. :) http://sid.rstack.org/blog/index.php/444-insecurity-enforced
Arf, ça relève plus du bug, tout de même...
Mais il ne serait pas impossible qu'un HotSpot ne laisse pas passer udp/4500, udp/500, udp/1701 et éventuellement ip/88 nécessaires à L2TP/IPSec, parce qu'on ne parlera pas de PPTP, soyons sérieux :)
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Erwan David
(Xavier) écrivait :
Loic Restoux wrote:
Ce qui ne semble pas marcher à tous les coups. :) http://sid.rstack.org/blog/index.php/444-insecurity-enforced
Arf, ça relève plus du bug, tout de même...
Mais il ne serait pas impossible qu'un HotSpot ne laisse pas passer udp/4500, udp/500, udp/1701 et éventuellement ip/88 nécessaires à L2TP/IPSec, parce qu'on ne parlera pas de PPTP, soyons sérieux :)
D'où l'intérêt de se mettre un openvpn sur TCP/443.
Qui sera difficilement filtré par le portail... (mais sera sensible au bug brésilien).
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
xavier@groumpf.org (Xavier) écrivait :
Loic Restoux <lrestoux@free.fr> wrote:
Ce qui ne semble pas marcher à tous les coups. :)
http://sid.rstack.org/blog/index.php/444-insecurity-enforced
Arf, ça relève plus du bug, tout de même...
Mais il ne serait pas impossible qu'un HotSpot ne laisse pas passer
udp/4500, udp/500, udp/1701 et éventuellement ip/88 nécessaires à
L2TP/IPSec, parce qu'on ne parlera pas de PPTP, soyons sérieux :)
D'où l'intérêt de se mettre un openvpn sur TCP/443.
Qui sera difficilement filtré par le portail...
(mais sera sensible au bug brésilien).
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Ce qui ne semble pas marcher à tous les coups. :) http://sid.rstack.org/blog/index.php/444-insecurity-enforced
Arf, ça relève plus du bug, tout de même...
Mais il ne serait pas impossible qu'un HotSpot ne laisse pas passer udp/4500, udp/500, udp/1701 et éventuellement ip/88 nécessaires à L2TP/IPSec, parce qu'on ne parlera pas de PPTP, soyons sérieux :)
D'où l'intérêt de se mettre un openvpn sur TCP/443.
Qui sera difficilement filtré par le portail... (mais sera sensible au bug brésilien).
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Stephane Catteau
Nicolas George n'était pas loin de dire :
Bien sur que si. Si le proxy met sa réponse en attente, le temps que le serveur ait lui-même répondu, il aura la clé gentiment apportée sur un plateau d'argent par le serveur
Certainement pas, il aura la signature du serveur, ce n'est pas du tout la même chose que d'en avoir la clef.
Ce qui revient au même dans le cas présent, mais apparament tu es plus intéressé par ta conviction d'avoir raison que par la démonstration de cette conviction. Du coup tu te contente d'asséner tes certitudes sans expliciter pourquoi elles existent, ce qui rend la discussion impossible (et inutile pour le lecteur qui n'y apprend rien), sauf à deviner ce que tu as dans la tête.
C'est comme lorsque tu dis par ailleurs que le proxy perd l'authentification de pair-à-pair parce qu'il déchiffre puis rechiffre, tu commets une erreur de raisonnement. Oui, un proxy doit déchiffrer pour analyser, mais pourquoi diable devrait-il obligatoirement rechiffrer après, alors qu'il lui suffit de retransmettre à l'identique les données qu'il a reçu sans altération ?
Tout simplement parce que ce n'est pas possible, les protocoles d'échange de clefs et d'authentification pair-à-pair sont précisément prévus pour empêcher ça.
<news: Accessoirement ces proxies, HTTPS autant que SSH, sont principalement utilisés non pour le controle, mais pour le développement. Il est plus simple d'analyser le flux en son centre, que de loguer l'intégralitée des paquets aux deux extrémitées ; c'est donc un bon outil de débuguage. </>
Dans cette discussion, *tu* es la personne qui pense que la clé publique de l'utilisateur est inconnue du proxy. Or le contexte d'utilisation du proxy, que je viens de rappeler, indique clairement qu'il y est déployé volontairement. Pour autant, dès lors que l'utilisation volontaire et controlée est posssible, l'utilisation fortuite est aussi possible, même si la tache est effectivement compliquée par un pré-requis de taille, à savoir la connaissance de la clé publique de l'utilisateur. Neanmoins, sauf à entrer celle-ci en étant physiquement devant la machine, il n'y a aucune garantie a priori qu'elle n'a pas été elle aussi interceptée ; d'ailleurs même en l'entrant physiquement cette garantie n'est pas absolue, la machine pouvant être déjà compromise.
Plus précisément, si le proxy n'altère pas les données qui circulent entre le client et le serveur, alors il laisse s'établir une clef de session à laquelle il n'a pas accès, et ne peut donc pas décoder le flux.
Si et seulement si :
1) Il n'a pas connaissance de la clé publique du client (c.f. supra) 2) Il n'a pas connaissance de la clé publique du serveur. Or, pour cette dernière la tache est plus simple, il suffit (tout est relatif) d'être présent lors de la première connexion d'un nouvel utilisateur. Ce qui implique d'en connaitre aussi la clé publique, d'où la parenthèse.
Donc à moins que tu ne connaisse une faiblesse de ces protocoles que tout le monde ignore, tu en fait juste en train d'étaler ton incompréhension de la cryptographie.
C'est, en un sens, une faiblesse, mais elle est connue de tous, cela s'appelle "le facteur humain".
Nicolas George n'était pas loin de dire :
Bien sur que si. Si le proxy met sa réponse en attente, le temps que
le serveur ait lui-même répondu, il aura la clé gentiment apportée sur
un plateau d'argent par le serveur
Certainement pas, il aura la signature du serveur, ce n'est pas du tout la
même chose que d'en avoir la clef.
Ce qui revient au même dans le cas présent, mais apparament tu es plus
intéressé par ta conviction d'avoir raison que par la démonstration de
cette conviction. Du coup tu te contente d'asséner tes certitudes sans
expliciter pourquoi elles existent, ce qui rend la discussion
impossible (et inutile pour le lecteur qui n'y apprend rien), sauf à
deviner ce que tu as dans la tête.
C'est comme lorsque tu dis par ailleurs que le proxy perd
l'authentification de pair-à-pair parce qu'il déchiffre puis rechiffre,
tu commets une erreur de raisonnement. Oui, un proxy doit déchiffrer
pour analyser, mais pourquoi diable devrait-il obligatoirement
rechiffrer après, alors qu'il lui suffit de retransmettre à l'identique
les données qu'il a reçu sans altération ?
Tout simplement parce que ce n'est pas possible, les protocoles d'échange de
clefs et d'authentification pair-à-pair sont précisément prévus pour
empêcher ça.
<news:mn.3c187db1d65bd3ca.30736@sc4x.org>
Accessoirement ces proxies, HTTPS autant que SSH, sont principalement
utilisés non pour le controle, mais pour le développement. Il est plus
simple d'analyser le flux en son centre, que de loguer l'intégralitée
des paquets aux deux extrémitées ; c'est donc un bon outil de
débuguage.
</>
Dans cette discussion, *tu* es la personne qui pense que la clé
publique de l'utilisateur est inconnue du proxy. Or le contexte
d'utilisation du proxy, que je viens de rappeler, indique clairement
qu'il y est déployé volontairement.
Pour autant, dès lors que l'utilisation volontaire et controlée est
posssible, l'utilisation fortuite est aussi possible, même si la tache
est effectivement compliquée par un pré-requis de taille, à savoir la
connaissance de la clé publique de l'utilisateur. Neanmoins, sauf à
entrer celle-ci en étant physiquement devant la machine, il n'y a
aucune garantie a priori qu'elle n'a pas été elle aussi interceptée ;
d'ailleurs même en l'entrant physiquement cette garantie n'est pas
absolue, la machine pouvant être déjà compromise.
Plus précisément, si le proxy n'altère pas les données qui circulent entre
le client et le serveur, alors il laisse s'établir une clef de session à
laquelle il n'a pas accès, et ne peut donc pas décoder le flux.
Si et seulement si :
1) Il n'a pas connaissance de la clé publique du client (c.f. supra)
2) Il n'a pas connaissance de la clé publique du serveur. Or, pour
cette dernière la tache est plus simple, il suffit (tout est relatif)
d'être présent lors de la première connexion d'un nouvel utilisateur.
Ce qui implique d'en connaitre aussi la clé publique, d'où la
parenthèse.
Donc à moins que tu ne connaisse une faiblesse de ces protocoles que tout le
monde ignore, tu en fait juste en train d'étaler ton incompréhension de la
cryptographie.
C'est, en un sens, une faiblesse, mais elle est connue de tous, cela
s'appelle "le facteur humain".
Bien sur que si. Si le proxy met sa réponse en attente, le temps que le serveur ait lui-même répondu, il aura la clé gentiment apportée sur un plateau d'argent par le serveur
Certainement pas, il aura la signature du serveur, ce n'est pas du tout la même chose que d'en avoir la clef.
Ce qui revient au même dans le cas présent, mais apparament tu es plus intéressé par ta conviction d'avoir raison que par la démonstration de cette conviction. Du coup tu te contente d'asséner tes certitudes sans expliciter pourquoi elles existent, ce qui rend la discussion impossible (et inutile pour le lecteur qui n'y apprend rien), sauf à deviner ce que tu as dans la tête.
C'est comme lorsque tu dis par ailleurs que le proxy perd l'authentification de pair-à-pair parce qu'il déchiffre puis rechiffre, tu commets une erreur de raisonnement. Oui, un proxy doit déchiffrer pour analyser, mais pourquoi diable devrait-il obligatoirement rechiffrer après, alors qu'il lui suffit de retransmettre à l'identique les données qu'il a reçu sans altération ?
Tout simplement parce que ce n'est pas possible, les protocoles d'échange de clefs et d'authentification pair-à-pair sont précisément prévus pour empêcher ça.
<news: Accessoirement ces proxies, HTTPS autant que SSH, sont principalement utilisés non pour le controle, mais pour le développement. Il est plus simple d'analyser le flux en son centre, que de loguer l'intégralitée des paquets aux deux extrémitées ; c'est donc un bon outil de débuguage. </>
Dans cette discussion, *tu* es la personne qui pense que la clé publique de l'utilisateur est inconnue du proxy. Or le contexte d'utilisation du proxy, que je viens de rappeler, indique clairement qu'il y est déployé volontairement. Pour autant, dès lors que l'utilisation volontaire et controlée est posssible, l'utilisation fortuite est aussi possible, même si la tache est effectivement compliquée par un pré-requis de taille, à savoir la connaissance de la clé publique de l'utilisateur. Neanmoins, sauf à entrer celle-ci en étant physiquement devant la machine, il n'y a aucune garantie a priori qu'elle n'a pas été elle aussi interceptée ; d'ailleurs même en l'entrant physiquement cette garantie n'est pas absolue, la machine pouvant être déjà compromise.
Plus précisément, si le proxy n'altère pas les données qui circulent entre le client et le serveur, alors il laisse s'établir une clef de session à laquelle il n'a pas accès, et ne peut donc pas décoder le flux.
Si et seulement si :
1) Il n'a pas connaissance de la clé publique du client (c.f. supra) 2) Il n'a pas connaissance de la clé publique du serveur. Or, pour cette dernière la tache est plus simple, il suffit (tout est relatif) d'être présent lors de la première connexion d'un nouvel utilisateur. Ce qui implique d'en connaitre aussi la clé publique, d'où la parenthèse.
Donc à moins que tu ne connaisse une faiblesse de ces protocoles que tout le monde ignore, tu en fait juste en train d'étaler ton incompréhension de la cryptographie.
C'est, en un sens, une faiblesse, mais elle est connue de tous, cela s'appelle "le facteur humain".
Stephane Catteau
Kevin Denis devait dire quelque chose comme ceci :
client avec la clef du serveur, puisque, justement, il n'a pas la clef du serveur.
Bien sur que si. Si le proxy met sa réponse en attente, le temps que le serveur ait lui-même répondu, il aura la clé gentiment apportée sur un plateau d'argent par le serveur, ce qui ne ralentira pas des masses la connexions. Et ça marche dans les deux sens, il suffit que le proxy attende la réponse avant de répondre lui-même.
C'est une lecture audacieuse des specs d'échange des clés. Ceci dit, si tu as raison et que tu sait le faire, publies immédiatement, cela va intéresser énormément de monde.
Je ne sais pas le faire, mais je sais que j'ai raison pour l'avoir vu à l'oeuvre. Comme je l'ai dit initialement, et rappelé dans mon autre message, le proxy servait à l'analyse des flux lors du développement[1]. Techniquement parlant, je ne sais pas grand chose du proxy si ce n'est qu'il est dérivé de SSH proxy, qu'il avait connaissance de la clé utilisateur utilisée et qu'il fonctionnait avec n'importe quel serveur. Comme je l'ai rappelé, là aussi dans ma réponse à Nicolas George, je n'ai à aucun moment prétendu qu'un proxy SSH malvaillant existait, me contentant de dire qu'un proxy SSH, qui s'avère partiellement autonome, existait. Cela ne remet en aucun cas en question la robustesse intrinsèque du protocole, mais il n'en demeure pas moins qu'à l'instart de la biométrie dont l'on parlait dans une autre discussion, cette robustesse demande une part de confiance. Autrement dit, si l'on n'a pas confiance en la façon dont les clés publiques sont transmises à l'admin ou en la façon dont ce dernier se connecte au serveur pour les rajouter[2], alors il y n'est pas impossible que la connexion SSH soit interceptée et comprise à notre insu.
[1] L'objectif étant de ne pas avoir à ajouter du code loguant à l'un et/ou l'autre bout de la connexion, autant pour ne pas altérer le comportement des logiciels, que pour être sûr de ne pas avoir oublié de l'enlever (ou enlevé partiellement), ce qui créerait une brèche énorme. [2] J'ai connu un admin qui faisait tout l'administration via telnet au motif que les machines serveurs et son poste de travail étaient sur le même intranet, espéront le sécurisé à plus de 200%.
Kevin Denis devait dire quelque chose comme ceci :
client avec la clef du serveur, puisque, justement, il n'a pas la clef du
serveur.
Bien sur que si. Si le proxy met sa réponse en attente, le temps que
le serveur ait lui-même répondu, il aura la clé gentiment apportée sur
un plateau d'argent par le serveur, ce qui ne ralentira pas des masses
la connexions. Et ça marche dans les deux sens, il suffit que le proxy
attende la réponse avant de répondre lui-même.
C'est une lecture audacieuse des specs d'échange des clés.
Ceci dit, si tu as raison et que tu sait le faire, publies immédiatement,
cela va intéresser énormément de monde.
Je ne sais pas le faire, mais je sais que j'ai raison pour l'avoir vu
à l'oeuvre. Comme je l'ai dit initialement, et rappelé dans mon autre
message, le proxy servait à l'analyse des flux lors du
développement[1]. Techniquement parlant, je ne sais pas grand chose du
proxy si ce n'est qu'il est dérivé de SSH proxy, qu'il avait
connaissance de la clé utilisateur utilisée et qu'il fonctionnait avec
n'importe quel serveur.
Comme je l'ai rappelé, là aussi dans ma réponse à Nicolas George, je
n'ai à aucun moment prétendu qu'un proxy SSH malvaillant existait, me
contentant de dire qu'un proxy SSH, qui s'avère partiellement autonome,
existait. Cela ne remet en aucun cas en question la robustesse
intrinsèque du protocole, mais il n'en demeure pas moins qu'à l'instart
de la biométrie dont l'on parlait dans une autre discussion, cette
robustesse demande une part de confiance. Autrement dit, si l'on n'a
pas confiance en la façon dont les clés publiques sont transmises à
l'admin ou en la façon dont ce dernier se connecte au serveur pour les
rajouter[2], alors il y n'est pas impossible que la connexion SSH soit
interceptée et comprise à notre insu.
[1]
L'objectif étant de ne pas avoir à ajouter du code loguant à l'un
et/ou l'autre bout de la connexion, autant pour ne pas altérer le
comportement des logiciels, que pour être sûr de ne pas avoir oublié de
l'enlever (ou enlevé partiellement), ce qui créerait une brèche énorme.
[2]
J'ai connu un admin qui faisait tout l'administration via telnet au
motif que les machines serveurs et son poste de travail étaient sur le
même intranet, espéront le sécurisé à plus de 200%.
Kevin Denis devait dire quelque chose comme ceci :
client avec la clef du serveur, puisque, justement, il n'a pas la clef du serveur.
Bien sur que si. Si le proxy met sa réponse en attente, le temps que le serveur ait lui-même répondu, il aura la clé gentiment apportée sur un plateau d'argent par le serveur, ce qui ne ralentira pas des masses la connexions. Et ça marche dans les deux sens, il suffit que le proxy attende la réponse avant de répondre lui-même.
C'est une lecture audacieuse des specs d'échange des clés. Ceci dit, si tu as raison et que tu sait le faire, publies immédiatement, cela va intéresser énormément de monde.
Je ne sais pas le faire, mais je sais que j'ai raison pour l'avoir vu à l'oeuvre. Comme je l'ai dit initialement, et rappelé dans mon autre message, le proxy servait à l'analyse des flux lors du développement[1]. Techniquement parlant, je ne sais pas grand chose du proxy si ce n'est qu'il est dérivé de SSH proxy, qu'il avait connaissance de la clé utilisateur utilisée et qu'il fonctionnait avec n'importe quel serveur. Comme je l'ai rappelé, là aussi dans ma réponse à Nicolas George, je n'ai à aucun moment prétendu qu'un proxy SSH malvaillant existait, me contentant de dire qu'un proxy SSH, qui s'avère partiellement autonome, existait. Cela ne remet en aucun cas en question la robustesse intrinsèque du protocole, mais il n'en demeure pas moins qu'à l'instart de la biométrie dont l'on parlait dans une autre discussion, cette robustesse demande une part de confiance. Autrement dit, si l'on n'a pas confiance en la façon dont les clés publiques sont transmises à l'admin ou en la façon dont ce dernier se connecte au serveur pour les rajouter[2], alors il y n'est pas impossible que la connexion SSH soit interceptée et comprise à notre insu.
[1] L'objectif étant de ne pas avoir à ajouter du code loguant à l'un et/ou l'autre bout de la connexion, autant pour ne pas altérer le comportement des logiciels, que pour être sûr de ne pas avoir oublié de l'enlever (ou enlevé partiellement), ce qui créerait une brèche énorme. [2] J'ai connu un admin qui faisait tout l'administration via telnet au motif que les machines serveurs et son poste de travail étaient sur le même intranet, espéront le sécurisé à plus de 200%.
