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.
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.
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.
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.
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 ?
SUSPENSE !
X.
PS: hihihihi ! :-)
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 16:28, Erwan David a écrit :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 ?
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 ?
Le 07/01/2011 16:28, Erwan David a écrit :
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 ?
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 ?
Le 07/01/2011 16:28, Erwan David a écrit :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 ?
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 ?
Je ne fais que reprendre les propos de personnes bien plus compétentes
en la matière.
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.
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
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].
Je ne fais que reprendre les propos de personnes bien plus compétentes
en la matière.
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.
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
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].
Je ne fais que reprendre les propos de personnes bien plus compétentes
en la matière.
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.
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
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].
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.
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.
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 , dans le message , a
é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.
JKB , dans le message <slrniiejis.jdv.jkb@rayleigh.systella.fr>, a
é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.
JKB , dans le message , a
é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.
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.
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.
É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.
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.
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.
É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.
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.
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.
É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.
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 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
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.
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 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
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.
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 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
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.
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).
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...
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).
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...
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).
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...
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.
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.
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.