Loppsi 2.0

Le
Yannix
Salut,

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.



fcs et copie fsc, puis suivi fcs.

X.
Vos réponses Page 10 / 13
Trier par : date / pertinence
Stephane Catteau
Le #22999021
Nicolas George n'était pas loin de dire :

Cela me fait penser aux paranoïaques qui utilisent leur clé PGP pour
signer tout ce qu'ils écrivent en public, sans même avoir conscience du
fait que ce faisant ils fragilisent leur clé au point de la rendre
vulnérable ; plus l'échantillon est grand, plus le décryptage est
facile.



Là, tu montres surtout une grosse méconnaissance des principes de la
cryptographie à clef publique.



Je ne fais que reprendre les propos de personnes bien plus compétentes
en la matière.


Le plus intéressant étant qu'au bout du compte la mise en place d'un
tel proxy, sur un bridge en bordure du réseau, augmente le niveau de
sécurité, puisqu'il garantie que même les flux HTTPS ne seront pas
utilisables pour la fuite de documents.



En contrepartie, ils rendent impossible une vérification sérieuse du
certificat du site distant par l'utilisateur : soit l'administrateur a tout
prévu exhaustivement (bon courage), soit il laisse tout passer, soit il se
repose sur la sécurité grotesque de l'architecture des autorités de
certification.



Tu dis cela parce que tu raisonnes en terme de proxy pur et en te
basant sur l'affirmation initiale faisant fonctionner ce proxy avec une
base de certificat ou un cache pour ceux-ci. Ce qui amène d'ailleurs
ton erreur concernant le proxy SSH. Pour autant, un proxy peut
parfaitement agir autrement, mais peut-être devrions-nous alors lui
donner un autre nom.
Le principe n'est pas de simplement retransmettre les flux, mais
d'agir réellement comme un client vis-à-vis du serveur et comme un
serveur vis-à-vis du client. Ou, pour être plus précis, comme LE client
vis-à-vis du serveur et comme LE serveur vis-à-vis du client. Du coup
ton client SSH ne te dira rien, car le proxy se comportera réellement
comme le serveur, copiant à l'identique les réponses qu'il donnera,
jusqu'à la clé du serveur lui-même[1]. Le principe n'est pas de
simplement mettre les données en cache pour accélérer les connexions,
mais bel et bien d'intercepter celles-ci à la volée.
On peut en débattre si tu le veux, mais à vrai dire je me lasse un
peu, cela fait trois ans qu'à chaque fois qu'un nouveau débarque sur le
forum je suis obligé de tout reprendre à zéro, lisez les archives un
peu.


[1]
Ben vi, ce n'est pas pour rien que j'avais écrit "grosso-modo hein",
je n'ai pas dit qu'il suffisait d'installer un logiciel pour avoir un
proxy SSH, il me semblait évident que les personnes connaissants le
protocole sauraient qu'il faut intervenir à plus d'un niveau.
JKB
Le #22999161
Le Fri, 07 Jan 2011 15:56:24 +0100,
Yannix
Le 07/01/2011 14:35, JKB a écrit :
Le Thu, 06 Jan 2011 09:34:35 +0100,
Stephane Catteau
Erwan David devait dire quelque chose comme ceci :

En dehors d'intercaler entre le serveur et le client un proxy https qui
inclue et renvoie aux clients les certificats des sites https concernés,
ça me parrait difficile.



Ah mais ça se fait...



Il paraitrait même que ça se vend, c'est dire.



Et que ça va jusqu'à analyser finement le https et les données
soi-disant chiffrées.



Eh bien, "la populace", comme ce cher JKB, semble plutôt inquiète!



Gnî ? Je n'ai pas écrit 'est-ce que', mais 'Et que'. Toi y en a
comprendre la différence ?

Est-ce que nos Catteau et David vont pouvoir la rassurer ?

SUSPENSE !

X.

PS: hihihihi ! :-)



<soupir>

Je connais un prestataire de service qui possède justement ce genre
de proxy. Pour l'utilisateur final, c'est chiffré. Sauf que le proxy
déchiffre et rechiffre au vol à fins d'analyse pour être sûr que ce
qui circule sur le port 443 est du https légitime et pas un autre
protocole. Après, tout est dans la confiance que l'on accorde au
prestataire en question.

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
JKB
Le #22999151
Le Fri, 07 Jan 2011 17:26:25 +0100,
Yannix
Le 07/01/2011 16:28, Erwan David a écrit :
Yannix
Le 07/01/2011 14:35, JKB a écrit :
Le Thu, 06 Jan 2011 09:34:35 +0100,
Stephane Catteau
Erwan David devait dire quelque chose comme ceci :

En dehors d'intercaler entre le serveur et le client un proxy https qui
inclue et renvoie aux clients les certificats des sites https concernés,
ça me parrait difficile.



Ah mais ça se fait...



Il paraitrait même que ça se vend, c'est dire.



Et que ça va jusqu'à analyser finement le https et les données
soi-disant chiffrées.



Eh bien, "la populace", comme ce cher JKB, semble plutôt inquiète!

Est-ce que nos Catteau et David vont pouvoir la rassurer ?



Rassurer sur quoi ?



Et bien par exemple quand JKB se connecte au site de sa banque en https
? Là, il s'agit de pognon et visiblement, ça ferait mal aux fesses de
JKB si on pouvait intercepter la trace de ses virements en Suisse... :-)

On peut te trouver des boites qui vendent du proxy
web qui va générer au vol un certificat dont il a la clef pour les sites
en https et faire du man in the middle pour analyser les flux.

Ça existe. Maintenant est-ce largement déployé, j'en doute. Et c'est
plus simple à mettre en place sur une infrastructure d'entreprise (où
les postes clients font confiance au CA de l'entreprise).



Ben oui mais Catteau a parlé de "bridge" in the middle. Qu'est-ce qui
prouve à JKB que ses communications avec sa banque en https sont sûres ?



Avant de répondre à un type qui ne comprend rien, merci de lire
attentivement ce que j'ai écrit...

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
Nicolas George
Le #22999291
Stephane Catteau , dans le message a écrit :
Je ne fais que reprendre les propos de personnes bien plus compétentes
en la matière.



Peut-être as-tu mal compris leurs propos, ou peut-être ne sont-elles pas
aussi compétentes que tu le crois.

Tu dis cela parce que tu raisonnes en terme de proxy pur et en te
basant sur l'affirmation initiale faisant fonctionner ce proxy avec une
base de certificat ou un cache pour ceux-ci.



Je me base sur mes connaissances en cryptographie.

Ce qui amène d'ailleurs
ton erreur concernant le proxy SSH.



Il n'y a pas d'erreur de ma part en l'occurrence, ou alors il va te falloir
bosser un peu plus pour le prouver.

Le principe n'est pas de simplement retransmettre les flux, mais
d'agir réellement comme un client vis-à-vis du serveur et comme un



Et donc s'il agit comme client vis-à-vis du serveur, c'est à lui que revient
la tâche d'authentifier le serveur.

Je prends un cas très simple : supposons qu'une banque, dans un accès de
compétence bien improbable, cesse d'utiliser l'architecture des autorités de
certifications TLS et se mette, à la place, à distribuer l'empreinte de son
certificat auto-signé sur les courriers confidentiels qu'elle m'envoie. En
tant que client soigneux, je vérifie cette empreinte à chaque connexion.

Maintenant, tu m'expliques comment je la lui transmets, cette empreinte, au
proxy, pour qu'il authentifie le serveur ?

ton client SSH ne te dira rien, car le proxy se comportera réellement
comme le serveur, copiant à l'identique les réponses qu'il donnera,
jusqu'à la clé du serveur lui-même[1].



Là, tu te contredis, et de toutes façons, ton raisonnement ne tient pas.

De deux choses l'une : soit le proxy fait du « man in the middle », c'est à
dire usurpe chaque interlocuteur vis-à-vis de l'autre, soit il se contente
d'observer le flux.

S'il fait du « man in the middle », il ne peut pas s'authentifier auprès du
client avec la clef du serveur, puisque, justement, il n'a pas la clef du
serveur.

S'il ne fait pas du « man in the middle », il peut bien espionner ce qui
passe, mais ça lui fera une belle jambe, parce que le principe de la crypto,
c'est précisément de rendre opaque un canal de communication qui peut être
utilisé.

Évidemment, tout ceci s'appuie sur l'hypothèse que le proxy ne connaît pas
de faille dans les protocoles cryptographiques inconnue des chercheurs. Si
tu veux faire l'hupothèse rocambolesue inverse, on peut aussi te laisser
faire joujou avec Yannix.
Nicolas George
Le #22999271
JKB , dans le message écrit :
Je connais un prestataire de service qui possède justement ce genre
de proxy. Pour l'utilisateur final, c'est chiffré. Sauf que le proxy
déchiffre et rechiffre au vol à fins d'analyse pour être sûr que ce
qui circule sur le port 443 est du https légitime et pas un autre
protocole. Après, tout est dans la confiance que l'on accorde au
prestataire en question.



S'il déchiffre et rechiffre, alors il perd l'authentification de
pair-à-pair, ce qui dans certains cas est catastrophique pour la sécurité.

Certaines extensions au HTTP permettent à un proxy de faire suivre les
crédences du serveur, mais je ne sais pas à quel point elles sont
implémentées en pratique.
Erwan David
Le #22999341
Nicolas George
JKB , dans le message écrit :
Je connais un prestataire de service qui possède justement ce genre
de proxy. Pour l'utilisateur final, c'est chiffré. Sauf que le proxy
déchiffre et rechiffre au vol à fins d'analyse pour être sûr que ce
qui circule sur le port 443 est du https légitime et pas un autre
protocole. Après, tout est dans la confiance que l'on accorde au
prestataire en question.



S'il déchiffre et rechiffre, alors il perd l'authentification de
pair-à-pair, ce qui dans certains cas est catastrophique pour la sécurité.

Certaines extensions au HTTP permettent à un proxy de faire suivre les
crédences du serveur, mais je ne sais pas à quel point elles sont
implémentées en pratique.



Pas besoin : il suffit de regénérer un certificat au vol signé par son
CA local qu'on aura fait mettre dans les clients (parceque c'est celui
de l'entreprise). SSL ,e permet pas en effet de faire confiances aux
signataires sous condition c'est confiance absolue ou pas confiance...

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...


--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Stephane Catteau
Le #22999641
Nicolas George devait dire quelque chose comme ceci :

Le principe n'est pas de simplement retransmettre les flux, mais
d'agir réellement comme un client vis-à-vis du serveur et comme un



Et donc s'il agit comme client vis-à-vis du serveur, c'est à lui que revient
la tâche d'authentifier le serveur.



Le proxy s'en fout que le serveur soit qui il prétend être, il est là
pour analyser le flux, pas pour en valider la légitimité.


ton client SSH ne te dira rien, car le proxy se comportera réellement
comme le serveur, copiant à l'identique les réponses qu'il donnera,
jusqu'à la clé du serveur lui-même[1].



Là, tu te contredis, et de toutes façons, ton raisonnement ne tient pas.



Je ne me contredis pas et mon raisonnement tiens.

De deux choses l'une : soit le proxy fait du « man in the middle », c'est à
dire usurpe chaque interlocuteur vis-à-vis de l'autre, soit il se contente
d'observer le flux.



Tu es au courant, n'est-ce pas, qu'il n'y a strictement rien qui
l'empèche de faire les deux ?


S'il fait du « man in the middle », il ne peut pas s'authentifier auprès du
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.


Évidemment, tout ceci s'appuie sur l'hypothèse que le proxy ne connaît pas
de faille dans les protocoles cryptographiques inconnue des chercheurs.



Il n'y a pas besoin de faille pour que ça fonctionne, pas même besoin
de casser quoi que ce soit, toutes les données nécessaires transitent
par le réseau et donc par le proxy.
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 ?
Il ne suffit pas de raisonner en suivant les bons usages à la lettre,
il faut aussi imaginer toutes les façons de ne surtout pas les suivre
et les conséquences que cela peut impliquer. Oui, par exemple, dans un
monde de bisounours, une machine n'enverra jamais une clé serveur qui
n'est pas la sienne, mais on est pas dans un monde de bisounours et une
machine peut parfaitement envoyer la clé d'une autre machine, il suffit
juste qu'on lui ait demandé de faire comme cela.
Nicolas George
Le #22999941
Stephane Catteau , dans le message a écrit :
De deux choses l'une : soit le proxy fait du « man in the middle », c'est à
dire usurpe chaque interlocuteur vis-à-vis de l'autre, soit il se contente
d'observer le flux.


Tu es au courant, n'est-ce pas, qu'il n'y a strictement rien qui
l'empèche de faire les deux ?



Bien sûr que si il y a quelque chose qui l'empêche : la logique élémentaire.
Agir en « man in the middle » est exactement le complémentaire de « se
contenter d'observer le flux ».

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.

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.

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. A contrario,
si le proxy altère les données dans un sens ou dans l'autre, alors il se
rend visible par l'autre extrémité et brise l'authentification.

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.

Il ne suffit pas de raisonner en suivant les bons usages à la lettre,
il faut aussi imaginer toutes les façons de ne surtout pas les suivre
et les conséquences que cela peut impliquer.



Pour ta gouverne, les chercheurs en cryptanalyse font ça pendant tout leur
temps de travail, et à l'heure actuelle, ils n'ont pas trouvé de faiblesse
dans les protocoles employés ; ils ont même parfois démontré l'absence de
certaines faiblesses.

Oui, par exemple, dans un
monde de bisounours, une machine n'enverra jamais une clé serveur qui
n'est pas la sienne, mais on est pas dans un monde de bisounours et une
machine peut parfaitement envoyer la clé d'une autre machine, il suffit
juste qu'on lui ait demandé de faire comme cela.



Il faut aussi qu'elle l'ait, la clef, gros malin.
Nicolas George
Le #22999931
Erwan David , dans le message
Pas besoin : il suffit de regénérer un certificat au vol signé par son
CA local qu'on aura fait mettre dans les clients (parceque c'est celui
de l'entreprise).



Oui, bien sûr, de ce côté-là ça marche. C'est de l'autre côté que ça ne
marche pas : le proxy qui se connecte au serveur à notre place, comment il
décide s'il fait confiance au certificat ? Sans proxy, en cas de doute, le
navigateur peut demander à l'utilisateur, et un utilisateur très prudent
peut vider la base de CA de confiance de son navigateur. Avec un proxy, que
dalle, on en est réduit au comportement par défaut impossible à paramétrer.

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



À qui le dis-tu

et n'ajouter que ceux en lesquels on a confiance...



Et encore, même ça ce ne serait pas satisfaisant : si je décide de charger
dans mon navigateur, au hasard, la CA du CNRS, je veux lui faire confiance
pour les sites académiques français exclusivement, pas pour n'importe quel
site. Aucun navigateur ne propose d'interface pour faire ça.
Erwan David
Le #23000341
Nicolas George

Et encore, même ça ce ne serait pas satisfaisant : si je décide de charger
dans mon navigateur, au hasard, la CA du CNRS, je veux lui faire confiance
pour les sites académiques français exclusivement, pas pour n'importe quel
site. Aucun navigateur ne propose d'interface pour faire ça.



Effectivement, c'est ce que je disais dans un autre message, la
confiance est binaire : totale, ou rien...

--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Publicité
Poster une réponse
Anonyme