Unix n'a rien de standard de ce point de vue, alors chaque application
refait sa sauce. Mozilla utilise la libnss qui a un "Personnal Security
Manager" qui offre un peu les mêmes services, mais juste pour Mozilla.
Unix n'a rien de standard de ce point de vue, alors chaque application
refait sa sauce. Mozilla utilise la libnss qui a un "Personnal Security
Manager" qui offre un peu les mêmes services, mais juste pour Mozilla.
Unix n'a rien de standard de ce point de vue, alors chaque application
refait sa sauce. Mozilla utilise la libnss qui a un "Personnal Security
Manager" qui offre un peu les mêmes services, mais juste pour Mozilla.
Thomas Pornin wrote:Manager" qui offre un peu les mêmes services, mais juste pour Mozilla.
Un peu faux.
...
On pourrait faire évoluer le truc pour en faire un service standardisé
...
dbm type BSD qui ne peut pas être partagé entre plusieurs applis.
Thomas Pornin wrote:
Manager" qui offre un peu les mêmes services, mais juste pour Mozilla.
Un peu faux.
...
On pourrait faire évoluer le truc pour en faire un service standardisé
...
dbm type BSD qui ne peut pas être partagé entre plusieurs applis.
Thomas Pornin wrote:Manager" qui offre un peu les mêmes services, mais juste pour Mozilla.
Un peu faux.
...
On pourrait faire évoluer le truc pour en faire un service standardisé
...
dbm type BSD qui ne peut pas être partagé entre plusieurs applis.
Thomas Pornin wrote:Unix n'a rien de standard de ce point de vue, alors chaque application
refait sa sauce. Mozilla utilise la libnss qui a un "Personnal Security
Manager" qui offre un peu les mêmes services, mais juste pour Mozilla.
Un peu faux.
Le "Personnal Security Manager" fait partie de Mozilla et l'interface
avec NSS en rajoutant une sérieuse couche de CPP et d'interface
graphique au dessus de NSS qui est du C pur.
Le "Personnal Security Manager" transforme la sécurité + le SSL en un
composant XPCOM comportant des parties graphiques et scriptable, que
Mozilla sait alors utiliser facilement.
NSS pour ce qui est de la configuration des certificats se base sur
une mini base de donnée, dont il faut lui indiquer le chemin, et a
priori personnalisée par utilisateur + Un module contenant des CA en
dur dont les valeurs pouvant être écrasés par celle des
l'utilisateurs, ce module étant soit à coté de la bdd, soit dans un
chemin externe qui devra être paramétré dans la bdd.
On pourrait faire évoluer le truc pour en faire un service standardisé
... D'autant que la couche basse du truc est une interface pkcs#11
standard. Il y a un seul obstacle qui est que la bdd est basée sur un
dbm type BSD qui ne peut pas être partagé entre plusieurs
applis. M'enfin, c'est déjà un problème à résoudre pour
Mozilla/FireFox/ThunderBird.
Thomas Pornin wrote:
Unix n'a rien de standard de ce point de vue, alors chaque application
refait sa sauce. Mozilla utilise la libnss qui a un "Personnal Security
Manager" qui offre un peu les mêmes services, mais juste pour Mozilla.
Un peu faux.
Le "Personnal Security Manager" fait partie de Mozilla et l'interface
avec NSS en rajoutant une sérieuse couche de CPP et d'interface
graphique au dessus de NSS qui est du C pur.
Le "Personnal Security Manager" transforme la sécurité + le SSL en un
composant XPCOM comportant des parties graphiques et scriptable, que
Mozilla sait alors utiliser facilement.
NSS pour ce qui est de la configuration des certificats se base sur
une mini base de donnée, dont il faut lui indiquer le chemin, et a
priori personnalisée par utilisateur + Un module contenant des CA en
dur dont les valeurs pouvant être écrasés par celle des
l'utilisateurs, ce module étant soit à coté de la bdd, soit dans un
chemin externe qui devra être paramétré dans la bdd.
On pourrait faire évoluer le truc pour en faire un service standardisé
... D'autant que la couche basse du truc est une interface pkcs#11
standard. Il y a un seul obstacle qui est que la bdd est basée sur un
dbm type BSD qui ne peut pas être partagé entre plusieurs
applis. M'enfin, c'est déjà un problème à résoudre pour
Mozilla/FireFox/ThunderBird.
Thomas Pornin wrote:Unix n'a rien de standard de ce point de vue, alors chaque application
refait sa sauce. Mozilla utilise la libnss qui a un "Personnal Security
Manager" qui offre un peu les mêmes services, mais juste pour Mozilla.
Un peu faux.
Le "Personnal Security Manager" fait partie de Mozilla et l'interface
avec NSS en rajoutant une sérieuse couche de CPP et d'interface
graphique au dessus de NSS qui est du C pur.
Le "Personnal Security Manager" transforme la sécurité + le SSL en un
composant XPCOM comportant des parties graphiques et scriptable, que
Mozilla sait alors utiliser facilement.
NSS pour ce qui est de la configuration des certificats se base sur
une mini base de donnée, dont il faut lui indiquer le chemin, et a
priori personnalisée par utilisateur + Un module contenant des CA en
dur dont les valeurs pouvant être écrasés par celle des
l'utilisateurs, ce module étant soit à coté de la bdd, soit dans un
chemin externe qui devra être paramétré dans la bdd.
On pourrait faire évoluer le truc pour en faire un service standardisé
... D'autant que la couche basse du truc est une interface pkcs#11
standard. Il y a un seul obstacle qui est que la bdd est basée sur un
dbm type BSD qui ne peut pas être partagé entre plusieurs
applis. M'enfin, c'est déjà un problème à résoudre pour
Mozilla/FireFox/ThunderBird.
On Tue, 02 Mar 2004 21:26:19 +0100, Jean-Marc DesperrierOn pourrait faire évoluer le truc pour en faire un service standardisé
...
dbm type BSD qui ne peut pas être partagé entre plusieurs applis.
Donc totalement vrai.
Une seul appli peut accéder à la base en même & le « on pourrait »
indique que sera uniquement à la bonne volonté de tout le monde.
[...]
On Tue, 02 Mar 2004 21:26:19 +0100, Jean-Marc Desperrier
On pourrait faire évoluer le truc pour en faire un service standardisé
...
dbm type BSD qui ne peut pas être partagé entre plusieurs applis.
Donc totalement vrai.
Une seul appli peut accéder à la base en même & le « on pourrait »
indique que sera uniquement à la bonne volonté de tout le monde.
[...]
On Tue, 02 Mar 2004 21:26:19 +0100, Jean-Marc DesperrierOn pourrait faire évoluer le truc pour en faire un service standardisé
...
dbm type BSD qui ne peut pas être partagé entre plusieurs applis.
Donc totalement vrai.
Une seul appli peut accéder à la base en même & le « on pourrait »
indique que sera uniquement à la bonne volonté de tout le monde.
[...]
Si on trouvait un remplacement simple avec une interface compatible dbm
supportant le multi-process avec une licence suffisament ouverte, il n'y
aurait aucune difficulté à avoir le support des developpeurs pour
intégrer cela.
Si on trouvait un remplacement simple avec une interface compatible dbm
supportant le multi-process avec une licence suffisament ouverte, il n'y
aurait aucune difficulté à avoir le support des developpeurs pour
intégrer cela.
Si on trouvait un remplacement simple avec une interface compatible dbm
supportant le multi-process avec une licence suffisament ouverte, il n'y
aurait aucune difficulté à avoir le support des developpeurs pour
intégrer cela.
On Wed, 3 Mar 2004, Jean-Marc Desperrier wrote:Si on trouvait un remplacement simple avec une interface compatible dbm
supportant le multi-process avec une licence suffisament ouverte, il n'y
aurait aucune difficulté à avoir le support des developpeurs pour
intégrer cela.
Comme par exemple Berkeley DB de Sleepycat? Ca supporte les accès
multiples, le verrouillage de clé, la journalisation, la détection des
"étreintes mortelles", et d'autres choses...
On Wed, 3 Mar 2004, Jean-Marc Desperrier wrote:
Si on trouvait un remplacement simple avec une interface compatible dbm
supportant le multi-process avec une licence suffisament ouverte, il n'y
aurait aucune difficulté à avoir le support des developpeurs pour
intégrer cela.
Comme par exemple Berkeley DB de Sleepycat? Ca supporte les accès
multiples, le verrouillage de clé, la journalisation, la détection des
"étreintes mortelles", et d'autres choses...
On Wed, 3 Mar 2004, Jean-Marc Desperrier wrote:Si on trouvait un remplacement simple avec une interface compatible dbm
supportant le multi-process avec une licence suffisament ouverte, il n'y
aurait aucune difficulté à avoir le support des developpeurs pour
intégrer cela.
Comme par exemple Berkeley DB de Sleepycat? Ca supporte les accès
multiples, le verrouillage de clé, la journalisation, la détection des
"étreintes mortelles", et d'autres choses...
According to Christian :Une entrerprise Entreprise A souhaite offrir à ses salariés un moyen de
communiquer de manière sécurisée par email, entre eux, mais surtout avec
des
utilisateurs quelconques sur internet.
La solution de messagerie de l'Entreprise A est Lotus Domino V6, avec le
client Web iNotes v6 (le client lourd Notes n'est pas déployé sur les
postes)
Quels sont les standards de messagerie sécurisée ?
Il y a grosso-modo deux moyens de faire de la "messagerie sécurisée" :
1. Faire un système à base de pages web, avec consultation via HTTPS
(autrement dit : SSL). C'est sécurisé en ce sens que les courriers sont
transférés entre le serveur central et les machines des utilisateurs
à l'intérieur de tuyaux SSL, avec donc un chiffrement et des contrôle
d'intégrité décents.
Les avantages de cette méthode sont un déploiement simple (rien à
installer sur les postes clients, car on suppose que ces postes ont déjà
un browser web capable de faire du SSL [Internet Explorer, Netscape,
Mozilla...]) et la possibilité d'appliquer certains traitements de masse
(par exemple, appliquer un antivirus sur tous les mails).
En revanche, il y a pas mal de défauts :
-- tout le système est centralisé sur le serveur web, qui ne doit pas
tomber en panne ;
-- le serveur central contient tous les courriers en clair (donc l'admin
peut tout lire -- c'est d'ailleurs pour ça qu'on peut appliquer un
antivirus général) ;
-- le système n'est pas compatible avec le reste du monde, et si des
extérieurs veulent échanger des courriers selon ce système, ils doivent
obtenir un accès au serveur central, et s'y connecter.
On peut fournir un accès "IMAP sur SSL" pour que les clients puissent
utiliser un client mail classique (genre "Outlook Express").
Le fait que le serveur central ait accès à tout et soit seul maître de
la sécurité fait que pour la non-répudiation à valeur juridique, c'est
rapé.
2. Faire un système où la cryptographie (chiffrement, signature...) est
appliquée directement sur les postes clients. Ça suppose un logiciel
client capable de faire ce genre de choses. Il y a deux standards :
-- OpenPGP : dérivé du PGP originel, maintenant une vraie norme puisqu'il
existe une autre implémentation interopérable (GnuPG).
-- S/MIME : la norme de l'ISO, utilisant les certificats X.509. Les
logiciels de mail "standards du marché" (Outlook, Outlook Express,
Netscape Messenger, Lotus Notes 6...) le gèrent nativement.
Dans les deux cas, les courriers sont envoyés ensuite en tant que
courriers tout-à-fait classiques, et si on ne fait que de la signature,
les courriers seront lisibles par des logiciels ne connaissant pas
ces standards (mais, bien sûr, les signatures ne seront alors pas
vérifiées).
Dans le cas de Domino avec le client iNotes, il faudrait voir en détail
si la cryptographie est appliquée par le client, ou déléguée au
serveur.
S/MIME a sur OpenPGP les avantages suivants :
-- Le support est déjà intégré dans les outils de courrier les plus
courants (PGP s'installe facilement, mais rien ne s'installe aussi
facilement que ce qui est déjà installé).
-- Le système de PKI est celui des certificats X.509 : il est
hiérarchique et centralisé, ce qui a tendance à mieux correspondre aux
besoins des entreprises. Le système de PKI d'OpenPGP ne fonctionne bien
qu'avec des communautés restreintes ; chaque utilisateur y gère sa
propre politique de sécurité, indépendamment de la volonté hiérarchique ;
le système n'est vraiment "sûr" que si chaque utilisateur comprend ce
qui se passe du point de vue sécurité (condition complètement irréaliste).
D'un autre côté, X.509 c'est gros, les PKI sont des choses complexes
et OpenPGP semble souvent bien attrayant parce que beaucoup moins
cher. Mais c'est parce qu'il en fournit beaucoup moins : ce qui est
cher dans une PKI hiérarchique, c'est la mise en place des procédures
de certification (identification physique des gens, surtout). Comme
d'habitude, quand on ne paye rien, on en a exactement pour son argent.
--Thomas Pornin
According to Christian <xtian_news@hotmail.com>:
Une entrerprise Entreprise A souhaite offrir à ses salariés un moyen de
communiquer de manière sécurisée par email, entre eux, mais surtout avec
des
utilisateurs quelconques sur internet.
La solution de messagerie de l'Entreprise A est Lotus Domino V6, avec le
client Web iNotes v6 (le client lourd Notes n'est pas déployé sur les
postes)
Quels sont les standards de messagerie sécurisée ?
Il y a grosso-modo deux moyens de faire de la "messagerie sécurisée" :
1. Faire un système à base de pages web, avec consultation via HTTPS
(autrement dit : SSL). C'est sécurisé en ce sens que les courriers sont
transférés entre le serveur central et les machines des utilisateurs
à l'intérieur de tuyaux SSL, avec donc un chiffrement et des contrôle
d'intégrité décents.
Les avantages de cette méthode sont un déploiement simple (rien à
installer sur les postes clients, car on suppose que ces postes ont déjà
un browser web capable de faire du SSL [Internet Explorer, Netscape,
Mozilla...]) et la possibilité d'appliquer certains traitements de masse
(par exemple, appliquer un antivirus sur tous les mails).
En revanche, il y a pas mal de défauts :
-- tout le système est centralisé sur le serveur web, qui ne doit pas
tomber en panne ;
-- le serveur central contient tous les courriers en clair (donc l'admin
peut tout lire -- c'est d'ailleurs pour ça qu'on peut appliquer un
antivirus général) ;
-- le système n'est pas compatible avec le reste du monde, et si des
extérieurs veulent échanger des courriers selon ce système, ils doivent
obtenir un accès au serveur central, et s'y connecter.
On peut fournir un accès "IMAP sur SSL" pour que les clients puissent
utiliser un client mail classique (genre "Outlook Express").
Le fait que le serveur central ait accès à tout et soit seul maître de
la sécurité fait que pour la non-répudiation à valeur juridique, c'est
rapé.
2. Faire un système où la cryptographie (chiffrement, signature...) est
appliquée directement sur les postes clients. Ça suppose un logiciel
client capable de faire ce genre de choses. Il y a deux standards :
-- OpenPGP : dérivé du PGP originel, maintenant une vraie norme puisqu'il
existe une autre implémentation interopérable (GnuPG).
-- S/MIME : la norme de l'ISO, utilisant les certificats X.509. Les
logiciels de mail "standards du marché" (Outlook, Outlook Express,
Netscape Messenger, Lotus Notes 6...) le gèrent nativement.
Dans les deux cas, les courriers sont envoyés ensuite en tant que
courriers tout-à-fait classiques, et si on ne fait que de la signature,
les courriers seront lisibles par des logiciels ne connaissant pas
ces standards (mais, bien sûr, les signatures ne seront alors pas
vérifiées).
Dans le cas de Domino avec le client iNotes, il faudrait voir en détail
si la cryptographie est appliquée par le client, ou déléguée au
serveur.
S/MIME a sur OpenPGP les avantages suivants :
-- Le support est déjà intégré dans les outils de courrier les plus
courants (PGP s'installe facilement, mais rien ne s'installe aussi
facilement que ce qui est déjà installé).
-- Le système de PKI est celui des certificats X.509 : il est
hiérarchique et centralisé, ce qui a tendance à mieux correspondre aux
besoins des entreprises. Le système de PKI d'OpenPGP ne fonctionne bien
qu'avec des communautés restreintes ; chaque utilisateur y gère sa
propre politique de sécurité, indépendamment de la volonté hiérarchique ;
le système n'est vraiment "sûr" que si chaque utilisateur comprend ce
qui se passe du point de vue sécurité (condition complètement irréaliste).
D'un autre côté, X.509 c'est gros, les PKI sont des choses complexes
et OpenPGP semble souvent bien attrayant parce que beaucoup moins
cher. Mais c'est parce qu'il en fournit beaucoup moins : ce qui est
cher dans une PKI hiérarchique, c'est la mise en place des procédures
de certification (identification physique des gens, surtout). Comme
d'habitude, quand on ne paye rien, on en a exactement pour son argent.
--Thomas Pornin
According to Christian :Une entrerprise Entreprise A souhaite offrir à ses salariés un moyen de
communiquer de manière sécurisée par email, entre eux, mais surtout avec
des
utilisateurs quelconques sur internet.
La solution de messagerie de l'Entreprise A est Lotus Domino V6, avec le
client Web iNotes v6 (le client lourd Notes n'est pas déployé sur les
postes)
Quels sont les standards de messagerie sécurisée ?
Il y a grosso-modo deux moyens de faire de la "messagerie sécurisée" :
1. Faire un système à base de pages web, avec consultation via HTTPS
(autrement dit : SSL). C'est sécurisé en ce sens que les courriers sont
transférés entre le serveur central et les machines des utilisateurs
à l'intérieur de tuyaux SSL, avec donc un chiffrement et des contrôle
d'intégrité décents.
Les avantages de cette méthode sont un déploiement simple (rien à
installer sur les postes clients, car on suppose que ces postes ont déjà
un browser web capable de faire du SSL [Internet Explorer, Netscape,
Mozilla...]) et la possibilité d'appliquer certains traitements de masse
(par exemple, appliquer un antivirus sur tous les mails).
En revanche, il y a pas mal de défauts :
-- tout le système est centralisé sur le serveur web, qui ne doit pas
tomber en panne ;
-- le serveur central contient tous les courriers en clair (donc l'admin
peut tout lire -- c'est d'ailleurs pour ça qu'on peut appliquer un
antivirus général) ;
-- le système n'est pas compatible avec le reste du monde, et si des
extérieurs veulent échanger des courriers selon ce système, ils doivent
obtenir un accès au serveur central, et s'y connecter.
On peut fournir un accès "IMAP sur SSL" pour que les clients puissent
utiliser un client mail classique (genre "Outlook Express").
Le fait que le serveur central ait accès à tout et soit seul maître de
la sécurité fait que pour la non-répudiation à valeur juridique, c'est
rapé.
2. Faire un système où la cryptographie (chiffrement, signature...) est
appliquée directement sur les postes clients. Ça suppose un logiciel
client capable de faire ce genre de choses. Il y a deux standards :
-- OpenPGP : dérivé du PGP originel, maintenant une vraie norme puisqu'il
existe une autre implémentation interopérable (GnuPG).
-- S/MIME : la norme de l'ISO, utilisant les certificats X.509. Les
logiciels de mail "standards du marché" (Outlook, Outlook Express,
Netscape Messenger, Lotus Notes 6...) le gèrent nativement.
Dans les deux cas, les courriers sont envoyés ensuite en tant que
courriers tout-à-fait classiques, et si on ne fait que de la signature,
les courriers seront lisibles par des logiciels ne connaissant pas
ces standards (mais, bien sûr, les signatures ne seront alors pas
vérifiées).
Dans le cas de Domino avec le client iNotes, il faudrait voir en détail
si la cryptographie est appliquée par le client, ou déléguée au
serveur.
S/MIME a sur OpenPGP les avantages suivants :
-- Le support est déjà intégré dans les outils de courrier les plus
courants (PGP s'installe facilement, mais rien ne s'installe aussi
facilement que ce qui est déjà installé).
-- Le système de PKI est celui des certificats X.509 : il est
hiérarchique et centralisé, ce qui a tendance à mieux correspondre aux
besoins des entreprises. Le système de PKI d'OpenPGP ne fonctionne bien
qu'avec des communautés restreintes ; chaque utilisateur y gère sa
propre politique de sécurité, indépendamment de la volonté hiérarchique ;
le système n'est vraiment "sûr" que si chaque utilisateur comprend ce
qui se passe du point de vue sécurité (condition complètement irréaliste).
D'un autre côté, X.509 c'est gros, les PKI sont des choses complexes
et OpenPGP semble souvent bien attrayant parce que beaucoup moins
cher. Mais c'est parce qu'il en fournit beaucoup moins : ce qui est
cher dans une PKI hiérarchique, c'est la mise en place des procédures
de certification (identification physique des gens, surtout). Comme
d'habitude, quand on ne paye rien, on en a exactement pour son argent.
--Thomas Pornin
Et moi aussi. Entre un site d'un commerçant avec certificat signé par
une CA privée quelconque et le même avec un certificat auto-signé,
pour moi c'est pareil : pourquoi devrais-je accorder plus de confiance
à des certificats accordés par une entreprise qui ne doit de comptes à
personne, qu'au commerçant lui-même auquel je suis de toute façon
obligé de faire confiance sur le traitement de mes informations
(bancaires notamment).
Et moi aussi. Entre un site d'un commerçant avec certificat signé par
une CA privée quelconque et le même avec un certificat auto-signé,
pour moi c'est pareil : pourquoi devrais-je accorder plus de confiance
à des certificats accordés par une entreprise qui ne doit de comptes à
personne, qu'au commerçant lui-même auquel je suis de toute façon
obligé de faire confiance sur le traitement de mes informations
(bancaires notamment).
Et moi aussi. Entre un site d'un commerçant avec certificat signé par
une CA privée quelconque et le même avec un certificat auto-signé,
pour moi c'est pareil : pourquoi devrais-je accorder plus de confiance
à des certificats accordés par une entreprise qui ne doit de comptes à
personne, qu'au commerçant lui-même auquel je suis de toute façon
obligé de faire confiance sur le traitement de mes informations
(bancaires notamment).
Unix n'a rien de standard de ce point de vue, alors chaque application
refait sa sauce. Mozilla utilise la libnss qui a un "Personnal Security
Manager" qui offre un peu les mêmes services, mais juste pour Mozilla.
Unix n'a rien de standard de ce point de vue, alors chaque application
refait sa sauce. Mozilla utilise la libnss qui a un "Personnal Security
Manager" qui offre un peu les mêmes services, mais juste pour Mozilla.
Unix n'a rien de standard de ce point de vue, alors chaque application
refait sa sauce. Mozilla utilise la libnss qui a un "Personnal Security
Manager" qui offre un peu les mêmes services, mais juste pour Mozilla.
In article , Laurent Fousse wrote:
Et moi aussi. Entre un site d'un commerçant avec certificat signé par
une CA privée quelconque et le même avec un certificat auto-signé,
pour moi c'est pareil : pourquoi devrais-je accorder plus de confiance
à des certificats accordés par une entreprise qui ne doit de comptes à
personne, qu'au commerçant lui-même auquel je suis de toute façon
obligé de faire confiance sur le traitement de mes informations
(bancaires notamment).
Justement comment sais tu avec un certificat autosigné que tu parles
bien à la bonne entreprise.
Dans un cas le modèle d'attaque requiert la corruption ou
l'exploitation d'une incompétence d'un CA, dans l'autre le modèle
d'attaque requiert "juste" de controler un point du traffic
entre toi et le site marchand sur lequel tu fais tes emplettes.
A toi de voir quel est le plus probable des deux, mais à mon avis
c'est le contrôle du réseau par un attaquant...
In article <slrnc46mih.42a.nobbs@nowwhat.fousse.info>, Laurent Fousse wrote:
Et moi aussi. Entre un site d'un commerçant avec certificat signé par
une CA privée quelconque et le même avec un certificat auto-signé,
pour moi c'est pareil : pourquoi devrais-je accorder plus de confiance
à des certificats accordés par une entreprise qui ne doit de comptes à
personne, qu'au commerçant lui-même auquel je suis de toute façon
obligé de faire confiance sur le traitement de mes informations
(bancaires notamment).
Justement comment sais tu avec un certificat autosigné que tu parles
bien à la bonne entreprise.
Dans un cas le modèle d'attaque requiert la corruption ou
l'exploitation d'une incompétence d'un CA, dans l'autre le modèle
d'attaque requiert "juste" de controler un point du traffic
entre toi et le site marchand sur lequel tu fais tes emplettes.
A toi de voir quel est le plus probable des deux, mais à mon avis
c'est le contrôle du réseau par un attaquant...
In article , Laurent Fousse wrote:
Et moi aussi. Entre un site d'un commerçant avec certificat signé par
une CA privée quelconque et le même avec un certificat auto-signé,
pour moi c'est pareil : pourquoi devrais-je accorder plus de confiance
à des certificats accordés par une entreprise qui ne doit de comptes à
personne, qu'au commerçant lui-même auquel je suis de toute façon
obligé de faire confiance sur le traitement de mes informations
(bancaires notamment).
Justement comment sais tu avec un certificat autosigné que tu parles
bien à la bonne entreprise.
Dans un cas le modèle d'attaque requiert la corruption ou
l'exploitation d'une incompétence d'un CA, dans l'autre le modèle
d'attaque requiert "juste" de controler un point du traffic
entre toi et le site marchand sur lequel tu fais tes emplettes.
A toi de voir quel est le plus probable des deux, mais à mon avis
c'est le contrôle du réseau par un attaquant...