On commence =E0 trouver des annonces de produits de type network
appliances (Web Proxy) qui clament r=E9aliser de l'inspection de trafic
en HTTPS :
"HTTPS Decryption enables the <machin>[1]
S-Series to enforce acceptable use and
security policies over HTTPS-decrypted
data. <machin>'s Web security solution is the
first to use Web reputation and URL filtering
to make HTTPS decryption decisions. For
example, a banking site can be bypassed for
HTTPS decryption, unless its Web reputation
score is low, in which case the HTTPS connection
is decrypted to scan content for malware,
or blocked outright. With this ability,
administrators no longer have to sacrifice
security for privacy."
J'en perds mon latin, comment est-il possible de r=E9aliser ce type
d'interception sans qu'une attaque Man-in-the-middle soit d=E9tect=E9e.
La description ci-dessus parle de "decryption", on peut supposer
qu'elle aurait lieu dans un temps raisonnable, or les specs de cette
appliance ne pr=E9cisent pas quelle consomme 45kW, ni qu'elle a besoin
d'azote liquide pour le refroidissement...
Bref ma confiance dans la robustesse du protocole HTTPS vacille ...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Christophe HENRY
skribis:
Bonjour,
On commence à trouver des annonces de produits de type network appliances (Web Proxy) qui clament réaliser de l'inspection de trafic en HTTPS : (...) J'en perds mon latin, comment est-il possible de réaliser ce type d'interception sans qu'une attaque Man-in-the-middle soit détectée.
Selon ma compréhension du texte, il s'agit simplement de ne pas s'interposer dans le flux lorsque le certificat du serveur a une « bonne réputation ». Dans ce cas, le flux n'est pas déchiffré. Lorsque le certificat n'a pas de bonne réputation, genre auto-signé peut-être, alors le flux est déchiffré et le certificat du Proxy À la Con est présenté au navigateur.
Cela apporte un certain équilibre en matière de vie privée de l'usager. On peut souhaiter consulter de façon sécurisée le site de sa banque (avec la bonne réputation) et se moquer des flux chiffrés parfois demandés pour télécharger de la publicité ou pour la visite occasionnelle d'un site.
-- Christophe HENRY http://www.sbgodin.fr - Site perso
Mathieu.Chappuis.lists@gmail.com skribis:
Bonjour,
On commence à trouver des annonces de produits de type network
appliances (Web Proxy) qui clament réaliser de l'inspection de trafic
en HTTPS :
(...)
J'en perds mon latin, comment est-il possible de réaliser ce type
d'interception sans qu'une attaque Man-in-the-middle soit détectée.
Selon ma compréhension du texte, il s'agit simplement de ne pas s'interposer
dans le flux lorsque le certificat du serveur a une « bonne réputation ».
Dans ce cas, le flux n'est pas déchiffré. Lorsque le certificat n'a pas de
bonne réputation, genre auto-signé peut-être, alors le flux est déchiffré
et le certificat du Proxy À la Con est présenté au navigateur.
Cela apporte un certain équilibre en matière de vie privée de l'usager. On
peut souhaiter consulter de façon sécurisée le site de sa banque (avec la
bonne réputation) et se moquer des flux chiffrés parfois demandés pour
télécharger de la publicité ou pour la visite occasionnelle d'un site.
--
Christophe HENRY
http://www.sbgodin.fr - Site perso
On commence à trouver des annonces de produits de type network appliances (Web Proxy) qui clament réaliser de l'inspection de trafic en HTTPS : (...) J'en perds mon latin, comment est-il possible de réaliser ce type d'interception sans qu'une attaque Man-in-the-middle soit détectée.
Selon ma compréhension du texte, il s'agit simplement de ne pas s'interposer dans le flux lorsque le certificat du serveur a une « bonne réputation ». Dans ce cas, le flux n'est pas déchiffré. Lorsque le certificat n'a pas de bonne réputation, genre auto-signé peut-être, alors le flux est déchiffré et le certificat du Proxy À la Con est présenté au navigateur.
Cela apporte un certain équilibre en matière de vie privée de l'usager. On peut souhaiter consulter de façon sécurisée le site de sa banque (avec la bonne réputation) et se moquer des flux chiffrés parfois demandés pour télécharger de la publicité ou pour la visite occasionnelle d'un site.
-- Christophe HENRY http://www.sbgodin.fr - Site perso
mpg
Le (on) vendredi 19 décembre 2008 15:56, Christophe HENRY a écrit (wrote) :
Selon ma compréhension du texte, il s'agit simplement de ne pas s'interposer dans le flux lorsque le certificat du serveur a une « bonne réputation ». Dans ce cas, le flux n'est pas déchiffré. Lorsque le certificat n'a pas de bonne réputation, genre auto-signé peut-être, alors le flux est déchiffré et le certificat du Proxy À la Con est présenté au navigateur.
Mézalor l'utilisateur ne peut plus examiner le certificat du site distant. Donc ça permet à quelqu'un entre le proxy et le site distant de faire une attaque de l'homme du milieu sans souci ? Ou bien j'ai manqué un truc ?
Dans tous les cas, quel est l'intérêt pour le proxy de déchiffrer le flux, même dans certains cas ?
Cela apporte un certain équilibre en matière de vie privée de l'usager. On peut souhaiter consulter de façon sécurisée le site de sa banque (avec la bonne réputation) et se moquer des flux chiffrés parfois demandés pour télécharger de la publicité ou pour la visite occasionnelle d'un site.
Ou vouloir se connecter sur un webmail perso, donc avec un certificat valable à nos yeux mais n'ayant vraisemblablement pas « bonne réputation » aux yeux du proxy, vu qu'il ne sera sans doute pas signé par une CA qu'il reconnaît (même si on a pris soin d'importer convenablement cette CA dans son navigateur) et savoir qu'à cause de ce proxy on est vulnérable à une man-in-the-middle... Perso ça me plairait pas...
Manuel.
Le (on) vendredi 19 décembre 2008 15:56, Christophe HENRY a écrit (wrote) :
Selon ma compréhension du texte, il s'agit simplement de ne pas
s'interposer dans le flux lorsque le certificat du serveur a une « bonne
réputation ». Dans ce cas, le flux n'est pas déchiffré. Lorsque le
certificat n'a pas de bonne réputation, genre auto-signé peut-être, alors
le flux est déchiffré et le certificat du Proxy À la Con est présenté au
navigateur.
Mézalor l'utilisateur ne peut plus examiner le certificat du site distant.
Donc ça permet à quelqu'un entre le proxy et le site distant de faire une
attaque de l'homme du milieu sans souci ? Ou bien j'ai manqué un truc ?
Dans tous les cas, quel est l'intérêt pour le proxy de déchiffrer le flux,
même dans certains cas ?
Cela apporte un certain équilibre en matière de vie privée de l'usager. On
peut souhaiter consulter de façon sécurisée le site de sa banque (avec la
bonne réputation) et se moquer des flux chiffrés parfois demandés pour
télécharger de la publicité ou pour la visite occasionnelle d'un site.
Ou vouloir se connecter sur un webmail perso, donc avec un certificat
valable à nos yeux mais n'ayant vraisemblablement pas « bonne réputation »
aux yeux du proxy, vu qu'il ne sera sans doute pas signé par une CA qu'il
reconnaît (même si on a pris soin d'importer convenablement cette CA dans
son navigateur) et savoir qu'à cause de ce proxy on est vulnérable à une
man-in-the-middle... Perso ça me plairait pas...
Le (on) vendredi 19 décembre 2008 15:56, Christophe HENRY a écrit (wrote) :
Selon ma compréhension du texte, il s'agit simplement de ne pas s'interposer dans le flux lorsque le certificat du serveur a une « bonne réputation ». Dans ce cas, le flux n'est pas déchiffré. Lorsque le certificat n'a pas de bonne réputation, genre auto-signé peut-être, alors le flux est déchiffré et le certificat du Proxy À la Con est présenté au navigateur.
Mézalor l'utilisateur ne peut plus examiner le certificat du site distant. Donc ça permet à quelqu'un entre le proxy et le site distant de faire une attaque de l'homme du milieu sans souci ? Ou bien j'ai manqué un truc ?
Dans tous les cas, quel est l'intérêt pour le proxy de déchiffrer le flux, même dans certains cas ?
Cela apporte un certain équilibre en matière de vie privée de l'usager. On peut souhaiter consulter de façon sécurisée le site de sa banque (avec la bonne réputation) et se moquer des flux chiffrés parfois demandés pour télécharger de la publicité ou pour la visite occasionnelle d'un site.
Ou vouloir se connecter sur un webmail perso, donc avec un certificat valable à nos yeux mais n'ayant vraisemblablement pas « bonne réputation » aux yeux du proxy, vu qu'il ne sera sans doute pas signé par une CA qu'il reconnaît (même si on a pris soin d'importer convenablement cette CA dans son navigateur) et savoir qu'à cause de ce proxy on est vulnérable à une man-in-the-middle... Perso ça me plairait pas...
Manuel.
Christophe HENRY
mpg skribis:
Selon ma compréhension du texte, il s'agit simplement de ne pas s'interposer dans le flux lorsque le certificat du serveur a une « bonne réputation ». Dans ce cas, le flux n'est pas déchiffré. Lorsque le certificat n'a pas de bonne réputation, genre auto-signé peut-être, alors le flux est déchiffré et le certificat du Proxy À la Con est présenté au navigateur.
Mézalor l'utilisateur ne peut plus examiner le certificat du site distant. Donc ça permet à quelqu'un entre le proxy et le site distant de faire une attaque de l'homme du milieu sans souci ? Ou bien j'ai manqué un truc ?
Effectivement, une attaque de l'homme du milieu devient de fait indétectable pour le navigateur si le PAC (Proxy À la Con) s'interpose. Reste à avoir confiance envers le PAC de s'assurer de la véracité des certificats interceptés. C'est assez difficile.
Dans tous les cas, quel est l'intérêt pour le proxy de déchiffrer le flux, même dans certains cas ?
Le proxy pourrait fort bien interdire la communication. Or, il l'autorise pour pouvoir l'écouter. Le problème est que laisser passer tel quel interdit d'écouter (rapidement) le trafic. Alors il déchiffre, analyse et renvoie chiffré (avec le certificat du PAC) les données.
Cela apporte un certain équilibre en matière de vie privée de l'usager. On peut souhaiter consulter de façon sécurisée le site de sa banque (avec la bonne réputation) et se moquer des flux chiffrés parfois demandés pour télécharger de la publicité ou pour la visite occasionnelle d'un site.
Ou vouloir se connecter sur un webmail perso, donc avec un certificat valable à nos yeux mais n'ayant vraisemblablement pas « bonne réputation » aux yeux du proxy, vu qu'il ne sera sans doute pas signé par une CA qu'il reconnaît (même si on a pris soin d'importer convenablement cette CA dans son navigateur) et savoir qu'à cause de ce proxy on est vulnérable à une man-in-the-middle... Perso ça me plairait pas...
Si on est prudent, on ne l'est jamais. Il est possible d'imposer le passage par un PAC (dit « transparant ») et de rendre l'opération invisible de prime abord pour le navigateur, puisque le certificat du PAC est souvent déjà inclu dans sa base de certificats à l'installation. Voire, il est validé par l'utilisateur lors de la première sortie en https.
La solution consiste à pourvoir s'assurer que le certificat serveur est bien celui qu'on attend. On peut, par exemple, refuser au certificat du PAC l'autorisation définitive. Ainsi, à chaque interception du PAC un message de validation de son certificat apparaîtra.
Pour ma part, j'aimerais bien que les navigateurs implémentent ce genre de comportement : - passage fortuit en https et on se moque de savoir que les méchants admins ou pirates interceptent les flux : le certificat est toujours accepté par défaut mais non retenu comme fiable dans le magasin ; - passage voulu en https et on veut retenir que tel certificat, avec telle somme cryptographique, est le bon : tout changement de certificat du site (à cause du PAC) déclenche l'alerte ;
Qui connaît Ssh et GnuPg comprends sans peine mes voeux. Merci père Noël ;-)
Le premier cas se rencontrerait quand on clique sur un résultat de recherche qui est un lien en https. Le second cas, quand on va voir sa banque.
-- Christophe HENRY http://www.sbgodin.fr - Site perso
mpg skribis:
Selon ma compréhension du texte, il s'agit simplement de ne pas
s'interposer dans le flux lorsque le certificat du serveur a une « bonne
réputation ». Dans ce cas, le flux n'est pas déchiffré. Lorsque le
certificat n'a pas de bonne réputation, genre auto-signé peut-être, alors
le flux est déchiffré et le certificat du Proxy À la Con est présenté au
navigateur.
Mézalor l'utilisateur ne peut plus examiner le certificat du site distant.
Donc ça permet à quelqu'un entre le proxy et le site distant de faire une
attaque de l'homme du milieu sans souci ? Ou bien j'ai manqué un truc ?
Effectivement, une attaque de l'homme du milieu devient de fait indétectable
pour le navigateur si le PAC (Proxy À la Con) s'interpose. Reste à avoir
confiance envers le PAC de s'assurer de la véracité des certificats
interceptés. C'est assez difficile.
Dans tous les cas, quel est l'intérêt pour le proxy de déchiffrer le flux,
même dans certains cas ?
Le proxy pourrait fort bien interdire la communication. Or, il l'autorise
pour pouvoir l'écouter. Le problème est que laisser passer tel quel
interdit d'écouter (rapidement) le trafic. Alors il déchiffre, analyse et
renvoie chiffré (avec le certificat du PAC) les données.
Cela apporte un certain équilibre en matière de vie privée de l'usager.
On peut souhaiter consulter de façon sécurisée le site de sa banque (avec
la bonne réputation) et se moquer des flux chiffrés parfois demandés pour
télécharger de la publicité ou pour la visite occasionnelle d'un site.
Ou vouloir se connecter sur un webmail perso, donc avec un certificat
valable à nos yeux mais n'ayant vraisemblablement pas « bonne réputation »
aux yeux du proxy, vu qu'il ne sera sans doute pas signé par une CA qu'il
reconnaît (même si on a pris soin d'importer convenablement cette CA dans
son navigateur) et savoir qu'à cause de ce proxy on est vulnérable à une
man-in-the-middle... Perso ça me plairait pas...
Si on est prudent, on ne l'est jamais. Il est possible d'imposer le passage
par un PAC (dit « transparant ») et de rendre l'opération invisible de
prime abord pour le navigateur, puisque le certificat du PAC est souvent
déjà inclu dans sa base de certificats à l'installation. Voire, il est
validé par l'utilisateur lors de la première sortie en https.
La solution consiste à pourvoir s'assurer que le certificat serveur est bien
celui qu'on attend. On peut, par exemple, refuser au certificat du PAC
l'autorisation définitive. Ainsi, à chaque interception du PAC un message
de validation de son certificat apparaîtra.
Pour ma part, j'aimerais bien que les navigateurs implémentent ce genre de
comportement :
- passage fortuit en https et on se moque de savoir que les méchants admins
ou pirates interceptent les flux : le certificat est toujours accepté par
défaut mais non retenu comme fiable dans le magasin ;
- passage voulu en https et on veut retenir que tel certificat, avec telle
somme cryptographique, est le bon : tout changement de certificat du site
(à cause du PAC) déclenche l'alerte ;
Qui connaît Ssh et GnuPg comprends sans peine mes voeux. Merci père Noël ;-)
Le premier cas se rencontrerait quand on clique sur un résultat de recherche
qui est un lien en https. Le second cas, quand on va voir sa banque.
--
Christophe HENRY
http://www.sbgodin.fr - Site perso
Selon ma compréhension du texte, il s'agit simplement de ne pas s'interposer dans le flux lorsque le certificat du serveur a une « bonne réputation ». Dans ce cas, le flux n'est pas déchiffré. Lorsque le certificat n'a pas de bonne réputation, genre auto-signé peut-être, alors le flux est déchiffré et le certificat du Proxy À la Con est présenté au navigateur.
Mézalor l'utilisateur ne peut plus examiner le certificat du site distant. Donc ça permet à quelqu'un entre le proxy et le site distant de faire une attaque de l'homme du milieu sans souci ? Ou bien j'ai manqué un truc ?
Effectivement, une attaque de l'homme du milieu devient de fait indétectable pour le navigateur si le PAC (Proxy À la Con) s'interpose. Reste à avoir confiance envers le PAC de s'assurer de la véracité des certificats interceptés. C'est assez difficile.
Dans tous les cas, quel est l'intérêt pour le proxy de déchiffrer le flux, même dans certains cas ?
Le proxy pourrait fort bien interdire la communication. Or, il l'autorise pour pouvoir l'écouter. Le problème est que laisser passer tel quel interdit d'écouter (rapidement) le trafic. Alors il déchiffre, analyse et renvoie chiffré (avec le certificat du PAC) les données.
Cela apporte un certain équilibre en matière de vie privée de l'usager. On peut souhaiter consulter de façon sécurisée le site de sa banque (avec la bonne réputation) et se moquer des flux chiffrés parfois demandés pour télécharger de la publicité ou pour la visite occasionnelle d'un site.
Ou vouloir se connecter sur un webmail perso, donc avec un certificat valable à nos yeux mais n'ayant vraisemblablement pas « bonne réputation » aux yeux du proxy, vu qu'il ne sera sans doute pas signé par une CA qu'il reconnaît (même si on a pris soin d'importer convenablement cette CA dans son navigateur) et savoir qu'à cause de ce proxy on est vulnérable à une man-in-the-middle... Perso ça me plairait pas...
Si on est prudent, on ne l'est jamais. Il est possible d'imposer le passage par un PAC (dit « transparant ») et de rendre l'opération invisible de prime abord pour le navigateur, puisque le certificat du PAC est souvent déjà inclu dans sa base de certificats à l'installation. Voire, il est validé par l'utilisateur lors de la première sortie en https.
La solution consiste à pourvoir s'assurer que le certificat serveur est bien celui qu'on attend. On peut, par exemple, refuser au certificat du PAC l'autorisation définitive. Ainsi, à chaque interception du PAC un message de validation de son certificat apparaîtra.
Pour ma part, j'aimerais bien que les navigateurs implémentent ce genre de comportement : - passage fortuit en https et on se moque de savoir que les méchants admins ou pirates interceptent les flux : le certificat est toujours accepté par défaut mais non retenu comme fiable dans le magasin ; - passage voulu en https et on veut retenir que tel certificat, avec telle somme cryptographique, est le bon : tout changement de certificat du site (à cause du PAC) déclenche l'alerte ;
Qui connaît Ssh et GnuPg comprends sans peine mes voeux. Merci père Noël ;-)
Le premier cas se rencontrerait quand on clique sur un résultat de recherche qui est un lien en https. Le second cas, quand on va voir sa banque.
-- Christophe HENRY http://www.sbgodin.fr - Site perso
Nicolas (
On 20 déc 2008, 00:59, Christophe HENRY wrote:
Pour ma part, j'aimerais bien que les navigateurs implémentent ce genre de comportement : - passage fortuit en https et on se moque de savoir que les méchants ad mins ou pirates interceptent les flux : le certificat est toujours accepté p ar défaut mais non retenu comme fiable dans le magasin ; - passage voulu en https et on veut retenir que tel certificat, avec tell e somme cryptographique, est le bon : tout changement de certificat du site (à cause du PAC) déclenche l'alerte ;
Le premier cas se rencontrerait quand on clique sur un résultat de rech erche qui est un lien en https. Le second cas, quand on va voir sa banque.
Je vois ici une monstrueuse faille. Dans le cas d'une Mitm, on peut aussi injecter du flux. Qu'est-ce qui empecherais d'envoyer le navigateur se baladais sur le site de la banque dans une iframe invisible (1ier cas) ? Cela permettrais de recuperer quelques cookies et de piégé la prochaine visite sur le site (2iéme cas) (vu qu'on pourra injecter du contenu actif sans declencher d'alerte). On aura alors une contamination du contenu du cas 2 par le contenue du cas 1.
On 20 déc 2008, 00:59, Christophe HENRY <pourr...@sbgodin.fr> wrote:
Pour ma part, j'aimerais bien que les navigateurs implémentent ce genre de
comportement :
- passage fortuit en https et on se moque de savoir que les méchants ad mins
ou pirates interceptent les flux : le certificat est toujours accepté p ar
défaut mais non retenu comme fiable dans le magasin ;
- passage voulu en https et on veut retenir que tel certificat, avec tell e
somme cryptographique, est le bon : tout changement de certificat du site
(à cause du PAC) déclenche l'alerte ;
Le premier cas se rencontrerait quand on clique sur un résultat de rech erche
qui est un lien en https. Le second cas, quand on va voir sa banque.
Je vois ici une monstrueuse faille.
Dans le cas d'une Mitm, on peut aussi injecter du flux.
Qu'est-ce qui empecherais d'envoyer le navigateur se baladais sur le
site de la banque dans une iframe invisible (1ier cas) ?
Cela permettrais de recuperer quelques cookies et de piégé la
prochaine visite sur le site (2iéme cas) (vu qu'on pourra injecter du
contenu actif sans declencher d'alerte).
On aura alors une contamination du contenu du cas 2 par le contenue du
cas 1.
Pour ma part, j'aimerais bien que les navigateurs implémentent ce genre de comportement : - passage fortuit en https et on se moque de savoir que les méchants ad mins ou pirates interceptent les flux : le certificat est toujours accepté p ar défaut mais non retenu comme fiable dans le magasin ; - passage voulu en https et on veut retenir que tel certificat, avec tell e somme cryptographique, est le bon : tout changement de certificat du site (à cause du PAC) déclenche l'alerte ;
Le premier cas se rencontrerait quand on clique sur un résultat de rech erche qui est un lien en https. Le second cas, quand on va voir sa banque.
Je vois ici une monstrueuse faille. Dans le cas d'une Mitm, on peut aussi injecter du flux. Qu'est-ce qui empecherais d'envoyer le navigateur se baladais sur le site de la banque dans une iframe invisible (1ier cas) ? Cela permettrais de recuperer quelques cookies et de piégé la prochaine visite sur le site (2iéme cas) (vu qu'on pourra injecter du contenu actif sans declencher d'alerte). On aura alors une contamination du contenu du cas 2 par le contenue du cas 1.
Christophe HENRY
Nicolas (@thenico) skribis:
On 20 déc 2008, 00:59, Christophe HENRY wrote:
Pour ma part, j'aimerais bien que les navigateurs implémentent ce genre de comportement : - passage fortuit en https et on se moque de savoir que les méchants admins ou pirates interceptent les flux : le certificat est toujours accepté par défaut mais non retenu comme fiable dans le magasin ; - passage voulu en https et on veut retenir que tel certificat, avec telle somme cryptographique, est le bon : tout changement de certificat du site (à cause du PAC) déclenche l'alerte ;
Le premier cas se rencontrerait quand on clique sur un résultat de recherche qui est un lien en https. Le second cas, quand on va voir sa banque.
Je vois ici une monstrueuse faille. Dans le cas d'une Mitm, on peut aussi injecter du flux. Qu'est-ce qui empecherais d'envoyer le navigateur se baladais sur le site de la banque dans une iframe invisible (1ier cas) ?
Il faut avoir confiance envers le Proxy À la Con, c'est évident. La <iframe>, bien que je ne sois pas spécialiste, devrait réveiller la méfiance du navigateur. Il devrait signaler qu'une partie de la page n'est pas authentifiée.
Cela permettrais de recuperer quelques cookies et de piégé la prochaine visite sur le site (2iéme cas) (vu qu'on pourra injecter du contenu actif sans declencher d'alerte). On aura alors une contamination du contenu du cas 2 par le contenue du cas 1.
Il faut en principe vérifier le certificat et s'assurer par un autre biais qu'il est authentique.
-- Christophe HENRY http://www.sbgodin.fr - Site perso
Nicolas (@thenico) skribis:
On 20 déc 2008, 00:59, Christophe HENRY <pourr...@sbgodin.fr> wrote:
Pour ma part, j'aimerais bien que les navigateurs implémentent ce genre
de comportement :
- passage fortuit en https et on se moque de savoir que les méchants
admins ou pirates interceptent les flux : le certificat est toujours
accepté par défaut mais non retenu comme fiable dans le magasin ;
- passage voulu en https et on veut retenir que tel certificat, avec
telle somme cryptographique, est le bon : tout changement de certificat
du site (à cause du PAC) déclenche l'alerte ;
Le premier cas se rencontrerait quand on clique sur un résultat de
recherche qui est un lien en https. Le second cas, quand on va voir sa
banque.
Je vois ici une monstrueuse faille.
Dans le cas d'une Mitm, on peut aussi injecter du flux.
Qu'est-ce qui empecherais d'envoyer le navigateur se baladais sur le
site de la banque dans une iframe invisible (1ier cas) ?
Il faut avoir confiance envers le Proxy À la Con, c'est évident. La
<iframe>, bien que je ne sois pas spécialiste, devrait réveiller la
méfiance du navigateur. Il devrait signaler qu'une partie de la page n'est
pas authentifiée.
Cela permettrais de recuperer quelques cookies et de piégé la
prochaine visite sur le site (2iéme cas) (vu qu'on pourra injecter du
contenu actif sans declencher d'alerte).
On aura alors une contamination du contenu du cas 2 par le contenue du
cas 1.
Il faut en principe vérifier le certificat et s'assurer par un autre biais
qu'il est authentique.
--
Christophe HENRY
http://www.sbgodin.fr - Site perso
Pour ma part, j'aimerais bien que les navigateurs implémentent ce genre de comportement : - passage fortuit en https et on se moque de savoir que les méchants admins ou pirates interceptent les flux : le certificat est toujours accepté par défaut mais non retenu comme fiable dans le magasin ; - passage voulu en https et on veut retenir que tel certificat, avec telle somme cryptographique, est le bon : tout changement de certificat du site (à cause du PAC) déclenche l'alerte ;
Le premier cas se rencontrerait quand on clique sur un résultat de recherche qui est un lien en https. Le second cas, quand on va voir sa banque.
Je vois ici une monstrueuse faille. Dans le cas d'une Mitm, on peut aussi injecter du flux. Qu'est-ce qui empecherais d'envoyer le navigateur se baladais sur le site de la banque dans une iframe invisible (1ier cas) ?
Il faut avoir confiance envers le Proxy À la Con, c'est évident. La <iframe>, bien que je ne sois pas spécialiste, devrait réveiller la méfiance du navigateur. Il devrait signaler qu'une partie de la page n'est pas authentifiée.
Cela permettrais de recuperer quelques cookies et de piégé la prochaine visite sur le site (2iéme cas) (vu qu'on pourra injecter du contenu actif sans declencher d'alerte). On aura alors une contamination du contenu du cas 2 par le contenue du cas 1.
Il faut en principe vérifier le certificat et s'assurer par un autre biais qu'il est authentique.
-- Christophe HENRY http://www.sbgodin.fr - Site perso
