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.
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...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Yannix <faitmoipeur@gmail.com> écrivait :
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...
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
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...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Kevin Denis
Le 05-01-2011, Erwan David a écrit :
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...
Sur un sujet connexe, un groupe publie une liste de clés privées pour faciliter le travail d'interception de flux chiffré: http://www.devttys0.com/2010/12/breaking-ssl-on-embedded-devices/
Cible primaire, les boitiers tout-en-un qui se gèrent en HTTPs avec une clé privée unique et identique pour toute la gamme. -- Kevin
Le 05-01-2011, Erwan David <erwan@rail.eu.org> a écrit :
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...
Sur un sujet connexe, un groupe publie une liste de clés privées
pour faciliter le travail d'interception de flux chiffré:
http://www.devttys0.com/2010/12/breaking-ssl-on-embedded-devices/
Cible primaire, les boitiers tout-en-un qui se gèrent en HTTPs avec une
clé privée unique et identique pour toute la gamme.
--
Kevin
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...
Sur un sujet connexe, un groupe publie une liste de clés privées pour faciliter le travail d'interception de flux chiffré: http://www.devttys0.com/2010/12/breaking-ssl-on-embedded-devices/
Cible primaire, les boitiers tout-en-un qui se gèrent en HTTPs avec une clé privée unique et identique pour toute la gamme. -- Kevin
Tonton Th
On 01/01/2011 07:52 PM, Yannix wrote:
Donc couche 7 selon le modèle OSI !
IP ne suit pas le modèle OSI.
Hein ? Attends, tu peux me répéter ça ?
IP ne suit pas le modèle OSI.
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
On 01/01/2011 07:52 PM, Yannix wrote:
Donc couche 7 selon le modèle OSI !
IP ne suit pas le modèle OSI.
Hein ? Attends, tu peux me répéter ça ?
IP ne suit pas le modèle OSI.
--
Ma coiffeuse est formidable - http://sonia.buvette.org/
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
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.
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.
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.
GG
"Baton Rouge" a écrit dans le message de news:
On Thu, 30 Dec 2010 00:23:42 +0100, "GG" wrote:
Mais comment peuvent ils voir ce qui est sur mon ecran et ce que je tape ?
Si mes souvenirs sont bons, on avait parlé d'un keylogger/espion matériel, installé physiquement dans le PC.
Keylogger physique ??? Trop visible !!!
Et pourquoi pas qq lignes de code judicieusement placées ds le système d'exploitation ??? Sur qq millions de lignes... Trop facile !!!
Pour ça faut que sarko demande l'autorisation à M$
Ah... Et ds le "camp adverse", comment font-ils ??? Demandent-ils l'autorisation ???
Mais bon, comme dit précédemment, on n'est sûr de rien !!!
"Baton Rouge" <nospam@poubelle.con> a écrit dans le message de news:
t39ph69rec2hv3rsep5kuq0cadoajcu0o9@4ax.com...
On Thu, 30 Dec 2010 00:23:42 +0100, "GG" <ggpgt@aliceadsl.fr> wrote:
Mais comment peuvent ils voir ce qui est sur mon ecran et ce que je
tape ?
Si mes souvenirs sont bons, on avait parlé d'un keylogger/espion
matériel, installé physiquement dans le PC.
Keylogger physique ??? Trop visible !!!
Et pourquoi pas qq lignes de code judicieusement placées ds le système
d'exploitation ??? Sur qq millions de lignes... Trop facile !!!
Pour ça faut que sarko demande l'autorisation à M$
Ah... Et ds le "camp adverse", comment font-ils ??? Demandent-ils
l'autorisation ???
Mais bon, comme dit précédemment, on n'est sûr de rien !!!
Mais comment peuvent ils voir ce qui est sur mon ecran et ce que je tape ?
Si mes souvenirs sont bons, on avait parlé d'un keylogger/espion matériel, installé physiquement dans le PC.
Keylogger physique ??? Trop visible !!!
Et pourquoi pas qq lignes de code judicieusement placées ds le système d'exploitation ??? Sur qq millions de lignes... Trop facile !!!
Pour ça faut que sarko demande l'autorisation à M$
Ah... Et ds le "camp adverse", comment font-ils ??? Demandent-ils l'autorisation ???
Mais bon, comme dit précédemment, on n'est sûr de rien !!!
JKB
Le Thu, 06 Jan 2011 09:34:35 +0100, Stephane Catteau écrivait :
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.
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 Thu, 06 Jan 2011 09:34:35 +0100,
Stephane Catteau <steph.nospam@sc4x.net> écrivait :
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.
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 Thu, 06 Jan 2011 09:34:35 +0100, Stephane Catteau écrivait :
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.
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
Yannix
Le 07/01/2011 14:35, JKB a écrit :
Le Thu, 06 Jan 2011 09:34:35 +0100, Stephane Catteau écrivait :
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 ?
SUSPENSE !
X.
PS: hihihihi ! :-)
Le 07/01/2011 14:35, JKB a écrit :
Le Thu, 06 Jan 2011 09:34:35 +0100,
Stephane Catteau <steph.nospam@sc4x.net> écrivait :
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 ?
Le Thu, 06 Jan 2011 09:34:35 +0100, Stephane Catteau écrivait :
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 ?
SUSPENSE !
X.
PS: hihihihi ! :-)
Erwan David
Yannix écrivait :
Le 07/01/2011 14:35, JKB a écrit :
Le Thu, 06 Jan 2011 09:34:35 +0100, Stephane Catteau écrivait :
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 ? 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).
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Yannix <faitmoipeur@gmail.com> écrivait :
Le 07/01/2011 14:35, JKB a écrit :
Le Thu, 06 Jan 2011 09:34:35 +0100,
Stephane Catteau <steph.nospam@sc4x.net> écrivait :
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 ? 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).
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Le Thu, 06 Jan 2011 09:34:35 +0100, Stephane Catteau écrivait :
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 ? 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).
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Stephane Catteau
Erwan David devait dire quelque chose comme ceci :
[proxy HTTPS filtrant]
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!
Pourquoi être inquiet ? Le fait est qu'il existe de tels logiciels et que *tous* les flux, même chiffrés, peuvent être analysées[1] dès lors qu'il y a échange de clé, point. Ce qui m'inquiète pour ma part ce n'est pas cela, mais le nombre incroyablement élevé de personnes qui pensent le contraire. 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.
Est-ce que nos Catteau et David vont pouvoir la rassurer ?
Rassurer sur quoi ? 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.
En cherchant bien dans les ruelles sombres on peut même trouver au moins un proxy qui fait (grosso-modo hein) pareil pour SSH, c'est dire.
Ç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).
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. L'important ce n'est pas qu'un tel proxy existe, mais comment et par qui il est utilisé. 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.
[1] Si si, tous les flux, mêmes les flux TOR peuvent l'être, il suffit d'être placé entre l'une des extrémités et l'entrée dans le réseau TOR ou sa sortie.
Erwan David devait dire quelque chose comme ceci :
[proxy HTTPS filtrant]
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!
Pourquoi être inquiet ? Le fait est qu'il existe de tels logiciels et
que *tous* les flux, même chiffrés, peuvent être analysées[1] dès lors
qu'il y a échange de clé, point. Ce qui m'inquiète pour ma part ce
n'est pas cela, mais le nombre incroyablement élevé de personnes qui
pensent le contraire.
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.
Est-ce que nos Catteau et David vont pouvoir la rassurer ?
Rassurer sur quoi ? 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.
En cherchant bien dans les ruelles sombres on peut même trouver au
moins un proxy qui fait (grosso-modo hein) pareil pour SSH, c'est dire.
Ç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).
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. L'important ce n'est pas qu'un
tel proxy existe, mais comment et par qui il est utilisé.
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.
[1]
Si si, tous les flux, mêmes les flux TOR peuvent l'être, il suffit
d'être placé entre l'une des extrémités et l'entrée dans le réseau TOR
ou sa sortie.
Erwan David devait dire quelque chose comme ceci :
[proxy HTTPS filtrant]
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!
Pourquoi être inquiet ? Le fait est qu'il existe de tels logiciels et que *tous* les flux, même chiffrés, peuvent être analysées[1] dès lors qu'il y a échange de clé, point. Ce qui m'inquiète pour ma part ce n'est pas cela, mais le nombre incroyablement élevé de personnes qui pensent le contraire. 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.
Est-ce que nos Catteau et David vont pouvoir la rassurer ?
Rassurer sur quoi ? 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.
En cherchant bien dans les ruelles sombres on peut même trouver au moins un proxy qui fait (grosso-modo hein) pareil pour SSH, c'est dire.
Ç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).
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. L'important ce n'est pas qu'un tel proxy existe, mais comment et par qui il est utilisé. 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.
[1] Si si, tous les flux, mêmes les flux TOR peuvent l'être, il suffit d'être placé entre l'une des extrémités et l'entrée dans le réseau TOR ou sa sortie.
Nicolas George
Stephane Catteau , dans le message , a écrit :
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.
En cherchant bien dans les ruelles sombres on peut même trouver au moins un proxy qui fait (grosso-modo hein) pareil pour SSH, c'est dire.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
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.
Stephane Catteau , dans le message <mn.3c187db1d65bd3ca.30736@sc4x.org>,
a écrit :
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.
En cherchant bien dans les ruelles sombres on peut même trouver au
moins un proxy qui fait (grosso-modo hein) pareil pour SSH, c'est dire.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
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.
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.
En cherchant bien dans les ruelles sombres on peut même trouver au moins un proxy qui fait (grosso-modo hein) pareil pour SSH, c'est dire.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
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.
