La solution « du pauvre » (sans que ce soit une question d'argent ^^),
si tu as un petit nombre de sites à SSLiser : tu génères pour chacun un
certificat auto-signé, le client n'aura qu'à accepter l'alerte de
sécurité de son navigateur à sa première connexion, après vérification
de l'empreinte du certificat (que tu lui auras transmis dans son mail
d'inscription par exemple).
La solution « du riche », si tu commences à avoir beaucoup de sites à
gérer : tu génères un certificat de CA auto-signé, et chaque certificat
de tes sites est alors généré et signé par ta propre CA.
Là pour tes clients, soit ils continuent à accepter chaque alerte de
chaque site à la 1ère connexion (après vérification toujours), soit tu
mets à leur disposition (en ligne sur ton site web par exemple) ton
certificat racine, tes clients l'importe dans leur navigateur, et tout
site SSLifié (actuel ou futur) par ta CA apparaît donc vert directement.
Au final, tu ne fais que remettre SSL à ce qu'il devrait être et à
comment il devrait fonctionner (il n'a jamais été prévu pour avoir des
méga-autorités de certification totalement arbitraires…) !
Et même mieux, dans le cas de la 2nde solution, tu peux même générer
pour chaque client son propre certificat (puisque tu es toi-même CA),
qui une fois importé dans son navigateur, permet de faire de
l'authentification mutuelle !
Le client ne peut dialoguer qu'avec un serveur dûment mandaté par ta CA,
et tes serveurs ne peuvent communiquer qu'avec un client dûment mandater
par ta CA ! Si l'un ou l'autre côté était compromis, plus aucune
communication ne passe ! Niveau sécurité, c'est royal, bien plus que le
cadenas et la barre verte (qui ne protège rien du tout au final, un faux
client n'étant pas détectable et si une root CA est compromise, un faux
serveur est possible)…
La solution « du pauvre » (sans que ce soit une question d'argent ^^),
si tu as un petit nombre de sites à SSLiser : tu génères pour chacun un
certificat auto-signé, le client n'aura qu'à accepter l'alerte de
sécurité de son navigateur à sa première connexion, après vérification
de l'empreinte du certificat (que tu lui auras transmis dans son mail
d'inscription par exemple).
La solution « du riche », si tu commences à avoir beaucoup de sites à
gérer : tu génères un certificat de CA auto-signé, et chaque certificat
de tes sites est alors généré et signé par ta propre CA.
Là pour tes clients, soit ils continuent à accepter chaque alerte de
chaque site à la 1ère connexion (après vérification toujours), soit tu
mets à leur disposition (en ligne sur ton site web par exemple) ton
certificat racine, tes clients l'importe dans leur navigateur, et tout
site SSLifié (actuel ou futur) par ta CA apparaît donc vert directement.
Au final, tu ne fais que remettre SSL à ce qu'il devrait être et à
comment il devrait fonctionner (il n'a jamais été prévu pour avoir des
méga-autorités de certification totalement arbitraires…) !
Et même mieux, dans le cas de la 2nde solution, tu peux même générer
pour chaque client son propre certificat (puisque tu es toi-même CA),
qui une fois importé dans son navigateur, permet de faire de
l'authentification mutuelle !
Le client ne peut dialoguer qu'avec un serveur dûment mandaté par ta CA,
et tes serveurs ne peuvent communiquer qu'avec un client dûment mandater
par ta CA ! Si l'un ou l'autre côté était compromis, plus aucune
communication ne passe ! Niveau sécurité, c'est royal, bien plus que le
cadenas et la barre verte (qui ne protège rien du tout au final, un faux
client n'étant pas détectable et si une root CA est compromise, un faux
serveur est possible)…
La solution « du pauvre » (sans que ce soit une question d'argent ^^),
si tu as un petit nombre de sites à SSLiser : tu génères pour chacun un
certificat auto-signé, le client n'aura qu'à accepter l'alerte de
sécurité de son navigateur à sa première connexion, après vérification
de l'empreinte du certificat (que tu lui auras transmis dans son mail
d'inscription par exemple).
La solution « du riche », si tu commences à avoir beaucoup de sites à
gérer : tu génères un certificat de CA auto-signé, et chaque certificat
de tes sites est alors généré et signé par ta propre CA.
Là pour tes clients, soit ils continuent à accepter chaque alerte de
chaque site à la 1ère connexion (après vérification toujours), soit tu
mets à leur disposition (en ligne sur ton site web par exemple) ton
certificat racine, tes clients l'importe dans leur navigateur, et tout
site SSLifié (actuel ou futur) par ta CA apparaît donc vert directement.
Au final, tu ne fais que remettre SSL à ce qu'il devrait être et à
comment il devrait fonctionner (il n'a jamais été prévu pour avoir des
méga-autorités de certification totalement arbitraires…) !
Et même mieux, dans le cas de la 2nde solution, tu peux même générer
pour chaque client son propre certificat (puisque tu es toi-même CA),
qui une fois importé dans son navigateur, permet de faire de
l'authentification mutuelle !
Le client ne peut dialoguer qu'avec un serveur dûment mandaté par ta CA,
et tes serveurs ne peuvent communiquer qu'avec un client dûment mandater
par ta CA ! Si l'un ou l'autre côté était compromis, plus aucune
communication ne passe ! Niveau sécurité, c'est royal, bien plus que le
cadenas et la barre verte (qui ne protège rien du tout au final, un faux
client n'étant pas détectable et si une root CA est compromise, un faux
serveur est possible)…
mais tu te rends compte que le client devrait être potentiellement au
courant que c'est toi qui est responsable de la sécurité de ses échanges
avec ton site. Et que dans ce cas le client pourrait aussi se retourner
contre toi...
Commerce oui mais responsabilité non...
Là on ne parle même plus d'éducation du client, si ca devient trop
compliqué/long (au delà de 3 clics et 2 phrase) il risquerait de passer
son chemin et d'aller sur une boutique plus simplifiée.
Commerce oui mais réflexion du client non...
mais tu te rends compte que le client devrait être potentiellement au
courant que c'est toi qui est responsable de la sécurité de ses échanges
avec ton site. Et que dans ce cas le client pourrait aussi se retourner
contre toi...
Commerce oui mais responsabilité non...
Là on ne parle même plus d'éducation du client, si ca devient trop
compliqué/long (au delà de 3 clics et 2 phrase) il risquerait de passer
son chemin et d'aller sur une boutique plus simplifiée.
Commerce oui mais réflexion du client non...
mais tu te rends compte que le client devrait être potentiellement au
courant que c'est toi qui est responsable de la sécurité de ses échanges
avec ton site. Et que dans ce cas le client pourrait aussi se retourner
contre toi...
Commerce oui mais responsabilité non...
Là on ne parle même plus d'éducation du client, si ca devient trop
compliqué/long (au delà de 3 clics et 2 phrase) il risquerait de passer
son chemin et d'aller sur une boutique plus simplifiée.
Commerce oui mais réflexion du client non...
A mon humble avis les certificats EV sont une vaste fumisterie qui n'a
qu'un seul but: vous faire cracher encore plus au bassinet, avec une
contrepartie "cosmétique": la fameuse barre verte censée rassurer Mme Michu.
A mon humble avis les certificats EV sont une vaste fumisterie qui n'a
qu'un seul but: vous faire cracher encore plus au bassinet, avec une
contrepartie "cosmétique": la fameuse barre verte censée rassurer Mme Michu.
A mon humble avis les certificats EV sont une vaste fumisterie qui n'a
qu'un seul but: vous faire cracher encore plus au bassinet, avec une
contrepartie "cosmétique": la fameuse barre verte censée rassurer Mme Michu.
Evidemment, mais il y a 2 problèmes qui se posent ici:
1) celui de l'identité associée au certificat: c'est quand-même l'une
des fonctions principales ! Dans le cas d'un certificat auto-signé,
j'achète un nom de domaine correspondant à quelque chose d'autre (je
fais du "cybersquatting", par exemple), je me fabrique mon propre
certificat dans mon coin et hop, me voilà légitime: j'ai un nom de
domaine et le certificat qui va avec... Facile ! ;-)
2) même si vous êtes un "gentil" qui n'a aucune intention de voler le
nom de domaine de qui que ce soit et que votre certificat auto-signé est
tout à fait légitime, comment vous assurez-vous qu'il est arrivé à bon
port sans avoir été falsifié en cours de route ?
La solution que vous
proposez (mise à disposition de l'empreinte du certificat sur votre site
web) n'en est pas une vis à vis des attaques par interposition ("man in
the middle", si vous préférez).
Ca revient à peu près au même que de
proposer des fichiers en téléchargement sur votre serveur et d'en
donner, sur le même site, la somme SHA1 ou autre pour permettre la
vérification de leur intégrité...
Evidemment, mais il y a 2 problèmes qui se posent ici:
1) celui de l'identité associée au certificat: c'est quand-même l'une
des fonctions principales ! Dans le cas d'un certificat auto-signé,
j'achète un nom de domaine correspondant à quelque chose d'autre (je
fais du "cybersquatting", par exemple), je me fabrique mon propre
certificat dans mon coin et hop, me voilà légitime: j'ai un nom de
domaine et le certificat qui va avec... Facile ! ;-)
2) même si vous êtes un "gentil" qui n'a aucune intention de voler le
nom de domaine de qui que ce soit et que votre certificat auto-signé est
tout à fait légitime, comment vous assurez-vous qu'il est arrivé à bon
port sans avoir été falsifié en cours de route ?
La solution que vous
proposez (mise à disposition de l'empreinte du certificat sur votre site
web) n'en est pas une vis à vis des attaques par interposition ("man in
the middle", si vous préférez).
Ca revient à peu près au même que de
proposer des fichiers en téléchargement sur votre serveur et d'en
donner, sur le même site, la somme SHA1 ou autre pour permettre la
vérification de leur intégrité...
Evidemment, mais il y a 2 problèmes qui se posent ici:
1) celui de l'identité associée au certificat: c'est quand-même l'une
des fonctions principales ! Dans le cas d'un certificat auto-signé,
j'achète un nom de domaine correspondant à quelque chose d'autre (je
fais du "cybersquatting", par exemple), je me fabrique mon propre
certificat dans mon coin et hop, me voilà légitime: j'ai un nom de
domaine et le certificat qui va avec... Facile ! ;-)
2) même si vous êtes un "gentil" qui n'a aucune intention de voler le
nom de domaine de qui que ce soit et que votre certificat auto-signé est
tout à fait légitime, comment vous assurez-vous qu'il est arrivé à bon
port sans avoir été falsifié en cours de route ?
La solution que vous
proposez (mise à disposition de l'empreinte du certificat sur votre site
web) n'en est pas une vis à vis des attaques par interposition ("man in
the middle", si vous préférez).
Ca revient à peu près au même que de
proposer des fichiers en téléchargement sur votre serveur et d'en
donner, sur le même site, la somme SHA1 ou autre pour permettre la
vérification de leur intégrité...
mais tu te rends compte que le client devrait être potentiellement au
courant que c'est toi qui est responsable de la sécurité de ses échanges
avec ton site. Et que dans ce cas le client pourrait aussi se retourner
contre toi...
Commerce oui mais responsabilité non...
Là on ne parle même plus d'éducation du client, si ca devient trop
compliqué/long (au delà de 3 clics et 2 phrase) il risquerait de passer
son chemin et d'aller sur une boutique plus simplifiée.
Commerce oui mais réflexion du client non...
mais tu te rends compte que le client devrait être potentiellement au
courant que c'est toi qui est responsable de la sécurité de ses échanges
avec ton site. Et que dans ce cas le client pourrait aussi se retourner
contre toi...
Commerce oui mais responsabilité non...
Là on ne parle même plus d'éducation du client, si ca devient trop
compliqué/long (au delà de 3 clics et 2 phrase) il risquerait de passer
son chemin et d'aller sur une boutique plus simplifiée.
Commerce oui mais réflexion du client non...
mais tu te rends compte que le client devrait être potentiellement au
courant que c'est toi qui est responsable de la sécurité de ses échanges
avec ton site. Et que dans ce cas le client pourrait aussi se retourner
contre toi...
Commerce oui mais responsabilité non...
Là on ne parle même plus d'éducation du client, si ca devient trop
compliqué/long (au delà de 3 clics et 2 phrase) il risquerait de passer
son chemin et d'aller sur une boutique plus simplifiée.
Commerce oui mais réflexion du client non...
Le 08/09/2011 08:57, Az Sam a écrit :
mais tu te rends compte que le client devrait être potentiellement au
courant que c'est toi qui est responsable de la sécurité de ses échanges
avec ton site. Et que dans ce cas le client pourrait aussi se retourner
contre toi...
Commerce oui mais responsabilité non...Là on ne parle même plus d'éducation du client, si ca devient trop
compliqué/long (au delà de 3 clics et 2 phrase) il risquerait de passer
son chemin et d'aller sur une boutique plus simplifiée.
Commerce oui mais réflexion du client non...
OK, donc forcément, avec ce genre de mentalité, les root CA vont encore
avoir la vie longue, et les clients la sécurité courte…
D'autant plus qu'importer un certificat dans un navigateur se fait en 1
clic à la 1ère connexion.
Le 08/09/2011 08:57, Az Sam a écrit :
mais tu te rends compte que le client devrait être potentiellement au
courant que c'est toi qui est responsable de la sécurité de ses échanges
avec ton site. Et que dans ce cas le client pourrait aussi se retourner
contre toi...
Commerce oui mais responsabilité non...
Là on ne parle même plus d'éducation du client, si ca devient trop
compliqué/long (au delà de 3 clics et 2 phrase) il risquerait de passer
son chemin et d'aller sur une boutique plus simplifiée.
Commerce oui mais réflexion du client non...
OK, donc forcément, avec ce genre de mentalité, les root CA vont encore
avoir la vie longue, et les clients la sécurité courte…
D'autant plus qu'importer un certificat dans un navigateur se fait en 1
clic à la 1ère connexion.
Le 08/09/2011 08:57, Az Sam a écrit :
mais tu te rends compte que le client devrait être potentiellement au
courant que c'est toi qui est responsable de la sécurité de ses échanges
avec ton site. Et que dans ce cas le client pourrait aussi se retourner
contre toi...
Commerce oui mais responsabilité non...Là on ne parle même plus d'éducation du client, si ca devient trop
compliqué/long (au delà de 3 clics et 2 phrase) il risquerait de passer
son chemin et d'aller sur une boutique plus simplifiée.
Commerce oui mais réflexion du client non...
OK, donc forcément, avec ce genre de mentalité, les root CA vont encore
avoir la vie longue, et les clients la sécurité courte…
D'autant plus qu'importer un certificat dans un navigateur se fait en 1
clic à la 1ère connexion.
On en revient à ce que je disais à propos de la perte de confiance: si
vous êtes le seul à proposer une solution de ce genre, alors que chez
tous les autres, il n'y a pas d'alerte de sécurité, vous allez perdre
des clients...
Ca, c'est ce qui s'appelle une affirmation gratuite qu'il vous faudra
étayer pour me convaincre... ;-) Reprenez les RFC et dites-moi comment
vous pouvez déduire cela. Pour ma part voici ce que je trouve dans la
RFC2246:
"As part of the X.509 protocol (a.k.a. ISO Authentication
framework), certificates are assigned by a trusted Certificate
Authority and provide a strong binding between a party's identity
or some other attributes and its public key."
Relisez. Vous voyez (et comprenez) le mot "trusted" ?
Si je suis votre raisonnement, les PKI sont des trucs inutiles, donc ?
Vous pensez pouvoir prouver votre identité simplement sur la foi de
votre bonne tête, et comme sur Internet on est tous un gros tas de
chouettes copains, vous serez cru sur parole...
Encore une fois, techniquement exact, mais pas applicable à des entités
externes à l'entreprise.
Ce n'est pas du tout le même cadre d'utilisation. Je vous rappelle qu'on
est dans le cadre d'une relation commerciale avec éventuellement un
transfert d'argent à la clef (sans jeu de mots). La barre verte est là
pour *rassurer*, même si elle n'est en aucune cas un gage absolu de
sécurité. On n'est plus dans le domaine du rationnel ici, mais bel et
bien dans celui de l'affect.
Si j'osais, je dirais que la barre verte du navigateur est à SSL ce que
la cravate est au commercial: elle fait bonne impression, mais ne prouve
rien... ;-)
Encore une fois, je ne crois malheureusement pas à la viabilité du
système que vous proposez, même si *dans certains cas* il est utilisable.
A mon sens, la seule alternative viable aux certificats racines, c'est
le réseau de confiance, tel qu'implémenté et utilisé par PGP/GPG et
consorts.
On en revient à ce que je disais à propos de la perte de confiance: si
vous êtes le seul à proposer une solution de ce genre, alors que chez
tous les autres, il n'y a pas d'alerte de sécurité, vous allez perdre
des clients...
Ca, c'est ce qui s'appelle une affirmation gratuite qu'il vous faudra
étayer pour me convaincre... ;-) Reprenez les RFC et dites-moi comment
vous pouvez déduire cela. Pour ma part voici ce que je trouve dans la
RFC2246:
"As part of the X.509 protocol (a.k.a. ISO Authentication
framework), certificates are assigned by a trusted Certificate
Authority and provide a strong binding between a party's identity
or some other attributes and its public key."
Relisez. Vous voyez (et comprenez) le mot "trusted" ?
Si je suis votre raisonnement, les PKI sont des trucs inutiles, donc ?
Vous pensez pouvoir prouver votre identité simplement sur la foi de
votre bonne tête, et comme sur Internet on est tous un gros tas de
chouettes copains, vous serez cru sur parole...
Encore une fois, techniquement exact, mais pas applicable à des entités
externes à l'entreprise.
Ce n'est pas du tout le même cadre d'utilisation. Je vous rappelle qu'on
est dans le cadre d'une relation commerciale avec éventuellement un
transfert d'argent à la clef (sans jeu de mots). La barre verte est là
pour *rassurer*, même si elle n'est en aucune cas un gage absolu de
sécurité. On n'est plus dans le domaine du rationnel ici, mais bel et
bien dans celui de l'affect.
Si j'osais, je dirais que la barre verte du navigateur est à SSL ce que
la cravate est au commercial: elle fait bonne impression, mais ne prouve
rien... ;-)
Encore une fois, je ne crois malheureusement pas à la viabilité du
système que vous proposez, même si *dans certains cas* il est utilisable.
A mon sens, la seule alternative viable aux certificats racines, c'est
le réseau de confiance, tel qu'implémenté et utilisé par PGP/GPG et
consorts.
On en revient à ce que je disais à propos de la perte de confiance: si
vous êtes le seul à proposer une solution de ce genre, alors que chez
tous les autres, il n'y a pas d'alerte de sécurité, vous allez perdre
des clients...
Ca, c'est ce qui s'appelle une affirmation gratuite qu'il vous faudra
étayer pour me convaincre... ;-) Reprenez les RFC et dites-moi comment
vous pouvez déduire cela. Pour ma part voici ce que je trouve dans la
RFC2246:
"As part of the X.509 protocol (a.k.a. ISO Authentication
framework), certificates are assigned by a trusted Certificate
Authority and provide a strong binding between a party's identity
or some other attributes and its public key."
Relisez. Vous voyez (et comprenez) le mot "trusted" ?
Si je suis votre raisonnement, les PKI sont des trucs inutiles, donc ?
Vous pensez pouvoir prouver votre identité simplement sur la foi de
votre bonne tête, et comme sur Internet on est tous un gros tas de
chouettes copains, vous serez cru sur parole...
Encore une fois, techniquement exact, mais pas applicable à des entités
externes à l'entreprise.
Ce n'est pas du tout le même cadre d'utilisation. Je vous rappelle qu'on
est dans le cadre d'une relation commerciale avec éventuellement un
transfert d'argent à la clef (sans jeu de mots). La barre verte est là
pour *rassurer*, même si elle n'est en aucune cas un gage absolu de
sécurité. On n'est plus dans le domaine du rationnel ici, mais bel et
bien dans celui de l'affect.
Si j'osais, je dirais que la barre verte du navigateur est à SSL ce que
la cravate est au commercial: elle fait bonne impression, mais ne prouve
rien... ;-)
Encore une fois, je ne crois malheureusement pas à la viabilité du
système que vous proposez, même si *dans certains cas* il est utilisable.
A mon sens, la seule alternative viable aux certificats racines, c'est
le réseau de confiance, tel qu'implémenté et utilisé par PGP/GPG et
consorts.
Les marketteux expliquent depuis des années qu'un ordinateur,
c'est normal que ça plante, et que l'informatique, c'est plus facile
que le vélo parce que c'est intuitif et qu'on n'a pas besoin
d'apprendre. Va expliquer après ça que la sécurité, c'est
compliqué.
Les marketteux expliquent depuis des années qu'un ordinateur,
c'est normal que ça plante, et que l'informatique, c'est plus facile
que le vélo parce que c'est intuitif et qu'on n'a pas besoin
d'apprendre. Va expliquer après ça que la sécurité, c'est
compliqué.
Les marketteux expliquent depuis des années qu'un ordinateur,
c'est normal que ça plante, et que l'informatique, c'est plus facile
que le vélo parce que c'est intuitif et qu'on n'a pas besoin
d'apprendre. Va expliquer après ça que la sécurité, c'est
compliqué.
Des méthodes existent pour garantir l'authenticité (GPG par exemple).
Des méthodes existent pour garantir l'authenticité (GPG par exemple).
Des méthodes existent pour garantir l'authenticité (GPG par exemple).
Le 08/09/2011 07:46, Bruno Tréguier a écrit :Evidemment, mais il y a 2 problèmes qui se posent ici:
1) celui de l'identité associée au certificat: c'est quand-même l'une
des fonctions principales ! Dans le cas d'un certificat auto-signé,
j'achète un nom de domaine correspondant à quelque chose d'autre (je
fais du "cybersquatting", par exemple), je me fabrique mon propre
certificat dans mon coin et hop, me voilà légitime: j'ai un nom de
domaine et le certificat qui va avec... Facile ! ;-)
C'est exactement la même chose actuellement…
Le fait de détenir un nom de domaine (cybersquatté ou non) te rend
automatiquement légitime pour en réclamer un certificat valide, y
compris en EV.
C'est uniquement une procédure IANA qui peut décider si oui ou non il y
a cybersquattage ou pas. Aussi bien, c'est toi le cybersquatter…
Et justement après, avec ma méthode, c'est TOI qui délivre TON
certificat à TON client.
Si tu te fais cybersquatter et qu'un de tes clients se fait avoir, il
aura une alerte de sécurité à sa connexion car il n'aura pas le
certificat du cybersquatteur dans son cercle de confianc !
Actuellement, le cybersquatteur pourrait avoir un certificat totalement
valide délivré par une root CA peu scrupuleuse, et tes clients se faire
avoir…
2) même si vous êtes un "gentil" qui n'a aucune intention de voler le
nom de domaine de qui que ce soit et que votre certificat auto-signé est
tout à fait légitime, comment vous assurez-vous qu'il est arrivé à bon
port sans avoir été falsifié en cours de route ?
Le problème est encore pire aujourd'hui, puisqu'il n'y a même pas besoin
de le falsifier ! Tu peux te monter du cybersquat avec « l'approbation »
des root CA.
Et de toute façon, dans tout système sécuritaire, le 1er contact
nécessite toujours d'être particulièrement vigilant, que cela soit
X.509, GPG ou RSA… Sauf qu'actuellement, ce 1er contact est tout sauf sûr !
La solution que vous
proposez (mise à disposition de l'empreinte du certificat sur votre site
web) n'en est pas une vis à vis des attaques par interposition ("man in
the middle", si vous préférez).
Faux problème.
Des méthodes existent pour garantir l'authenticité (GPG par exemple).
Ca revient à peu près au même que de
proposer des fichiers en téléchargement sur votre serveur et d'en
donner, sur le même site, la somme SHA1 ou autre pour permettre la
vérification de leur intégrité...
Oui, et c'est exactement pour cela que les empreintes SHA1 sont signées
par GPG…
De toute façon, actualité aidant, je peux vous retourner toutes vos
questions, et même bien d'autres…
Le 08/09/2011 07:46, Bruno Tréguier a écrit :
Evidemment, mais il y a 2 problèmes qui se posent ici:
1) celui de l'identité associée au certificat: c'est quand-même l'une
des fonctions principales ! Dans le cas d'un certificat auto-signé,
j'achète un nom de domaine correspondant à quelque chose d'autre (je
fais du "cybersquatting", par exemple), je me fabrique mon propre
certificat dans mon coin et hop, me voilà légitime: j'ai un nom de
domaine et le certificat qui va avec... Facile ! ;-)
C'est exactement la même chose actuellement…
Le fait de détenir un nom de domaine (cybersquatté ou non) te rend
automatiquement légitime pour en réclamer un certificat valide, y
compris en EV.
C'est uniquement une procédure IANA qui peut décider si oui ou non il y
a cybersquattage ou pas. Aussi bien, c'est toi le cybersquatter…
Et justement après, avec ma méthode, c'est TOI qui délivre TON
certificat à TON client.
Si tu te fais cybersquatter et qu'un de tes clients se fait avoir, il
aura une alerte de sécurité à sa connexion car il n'aura pas le
certificat du cybersquatteur dans son cercle de confianc !
Actuellement, le cybersquatteur pourrait avoir un certificat totalement
valide délivré par une root CA peu scrupuleuse, et tes clients se faire
avoir…
2) même si vous êtes un "gentil" qui n'a aucune intention de voler le
nom de domaine de qui que ce soit et que votre certificat auto-signé est
tout à fait légitime, comment vous assurez-vous qu'il est arrivé à bon
port sans avoir été falsifié en cours de route ?
Le problème est encore pire aujourd'hui, puisqu'il n'y a même pas besoin
de le falsifier ! Tu peux te monter du cybersquat avec « l'approbation »
des root CA.
Et de toute façon, dans tout système sécuritaire, le 1er contact
nécessite toujours d'être particulièrement vigilant, que cela soit
X.509, GPG ou RSA… Sauf qu'actuellement, ce 1er contact est tout sauf sûr !
La solution que vous
proposez (mise à disposition de l'empreinte du certificat sur votre site
web) n'en est pas une vis à vis des attaques par interposition ("man in
the middle", si vous préférez).
Faux problème.
Des méthodes existent pour garantir l'authenticité (GPG par exemple).
Ca revient à peu près au même que de
proposer des fichiers en téléchargement sur votre serveur et d'en
donner, sur le même site, la somme SHA1 ou autre pour permettre la
vérification de leur intégrité...
Oui, et c'est exactement pour cela que les empreintes SHA1 sont signées
par GPG…
De toute façon, actualité aidant, je peux vous retourner toutes vos
questions, et même bien d'autres…
Le 08/09/2011 07:46, Bruno Tréguier a écrit :Evidemment, mais il y a 2 problèmes qui se posent ici:
1) celui de l'identité associée au certificat: c'est quand-même l'une
des fonctions principales ! Dans le cas d'un certificat auto-signé,
j'achète un nom de domaine correspondant à quelque chose d'autre (je
fais du "cybersquatting", par exemple), je me fabrique mon propre
certificat dans mon coin et hop, me voilà légitime: j'ai un nom de
domaine et le certificat qui va avec... Facile ! ;-)
C'est exactement la même chose actuellement…
Le fait de détenir un nom de domaine (cybersquatté ou non) te rend
automatiquement légitime pour en réclamer un certificat valide, y
compris en EV.
C'est uniquement une procédure IANA qui peut décider si oui ou non il y
a cybersquattage ou pas. Aussi bien, c'est toi le cybersquatter…
Et justement après, avec ma méthode, c'est TOI qui délivre TON
certificat à TON client.
Si tu te fais cybersquatter et qu'un de tes clients se fait avoir, il
aura une alerte de sécurité à sa connexion car il n'aura pas le
certificat du cybersquatteur dans son cercle de confianc !
Actuellement, le cybersquatteur pourrait avoir un certificat totalement
valide délivré par une root CA peu scrupuleuse, et tes clients se faire
avoir…
2) même si vous êtes un "gentil" qui n'a aucune intention de voler le
nom de domaine de qui que ce soit et que votre certificat auto-signé est
tout à fait légitime, comment vous assurez-vous qu'il est arrivé à bon
port sans avoir été falsifié en cours de route ?
Le problème est encore pire aujourd'hui, puisqu'il n'y a même pas besoin
de le falsifier ! Tu peux te monter du cybersquat avec « l'approbation »
des root CA.
Et de toute façon, dans tout système sécuritaire, le 1er contact
nécessite toujours d'être particulièrement vigilant, que cela soit
X.509, GPG ou RSA… Sauf qu'actuellement, ce 1er contact est tout sauf sûr !
La solution que vous
proposez (mise à disposition de l'empreinte du certificat sur votre site
web) n'en est pas une vis à vis des attaques par interposition ("man in
the middle", si vous préférez).
Faux problème.
Des méthodes existent pour garantir l'authenticité (GPG par exemple).
Ca revient à peu près au même que de
proposer des fichiers en téléchargement sur votre serveur et d'en
donner, sur le même site, la somme SHA1 ou autre pour permettre la
vérification de leur intégrité...
Oui, et c'est exactement pour cela que les empreintes SHA1 sont signées
par GPG…
De toute façon, actualité aidant, je peux vous retourner toutes vos
questions, et même bien d'autres…
