Honnêtement, j'ai abandonné tout espoir. Entre les autorités foireuses
et les certificats auto-signés, je préfère considérer que HTTP et
HTTPS sont équivalents.
Honnêtement, j'ai abandonné tout espoir. Entre les autorités foireuses
et les certificats auto-signés, je préfère considérer que HTTP et
HTTPS sont équivalents.
Honnêtement, j'ai abandonné tout espoir. Entre les autorités foireuses
et les certificats auto-signés, je préfère considérer que HTTP et
HTTPS sont équivalents.
Le 07-09-2011, Aéris a écrit :Euh??? Rappelle-moi pourquoi on paie une fortune un certificat SSL ?
Ne serait-ce pas parce que justement les CA *DEVAIENT* vérifier ton
identité réelle et contrôler les demandes une à une ?
Rappelle moi pourquoi les certificats "EV" ont été inventé? Ne serait-ce
pas parceque le procédé de vérification/validation de certificat était
tellement léger qu'ils ont chois de faire des "Extended Validation"?
Le 07-09-2011, Aéris<aeris@imirhil.fr> a écrit :
Euh??? Rappelle-moi pourquoi on paie une fortune un certificat SSL ?
Ne serait-ce pas parce que justement les CA *DEVAIENT* vérifier ton
identité réelle et contrôler les demandes une à une ?
Rappelle moi pourquoi les certificats "EV" ont été inventé? Ne serait-ce
pas parceque le procédé de vérification/validation de certificat était
tellement léger qu'ils ont chois de faire des "Extended Validation"?
Le 07-09-2011, Aéris a écrit :Euh??? Rappelle-moi pourquoi on paie une fortune un certificat SSL ?
Ne serait-ce pas parce que justement les CA *DEVAIENT* vérifier ton
identité réelle et contrôler les demandes une à une ?
Rappelle moi pourquoi les certificats "EV" ont été inventé? Ne serait-ce
pas parceque le procédé de vérification/validation de certificat était
tellement léger qu'ils ont chois de faire des "Extended Validation"?
Honnêtement, j'ai abandonné tout espoir. Entre les autorités foireuses
et les certificats auto-signés, je préfère considérer que HTTP et
HTTPS sont équivalents.
Honnêtement, j'ai abandonné tout espoir. Entre les autorités foireuses
et les certificats auto-signés, je préfère considérer que HTTP et
HTTPS sont équivalents.
Honnêtement, j'ai abandonné tout espoir. Entre les autorités foireuses
et les certificats auto-signés, je préfère considérer que HTTP et
HTTPS sont équivalents.
Ce n'est certes pas obligatoire dans l'absolu, mais la force du
marketing étant ce qu'elle est, pour mettre en place une boutique en
ligne, c'est quand-même *très* fortement conseillé de nos jours.
Ce n'est certes pas obligatoire dans l'absolu, mais la force du
marketing étant ce qu'elle est, pour mettre en place une boutique en
ligne, c'est quand-même *très* fortement conseillé de nos jours.
Ce n'est certes pas obligatoire dans l'absolu, mais la force du
marketing étant ce qu'elle est, pour mettre en place une boutique en
ligne, c'est quand-même *très* fortement conseillé de nos jours.
Parce que les autorités de certification sont en situation d'oligopole.
Parce que les autorités de certification sont en situation d'oligopole.
Parce que les autorités de certification sont en situation d'oligopole.
Si tu tiens un site commercial, pourquoi avoir céder « au petit cadenas
» et « à la barre verte » alors qu'on voit bien que c'est totalement
inutile ?
Pire, les utilisateurs vont se croire en sécurité avec leur barre verte
et leur cadenas, alors qu'ils auraient du avoir une grosse alerte rouge
cramoisie que le certificat en face n'est plus celui qu'ils ont eux-même
déployé dans leur navigateur et que le responsable du site leur avait
communiqué au départ…
Si tu tiens un site commercial, pourquoi avoir céder « au petit cadenas
» et « à la barre verte » alors qu'on voit bien que c'est totalement
inutile ?
Pire, les utilisateurs vont se croire en sécurité avec leur barre verte
et leur cadenas, alors qu'ils auraient du avoir une grosse alerte rouge
cramoisie que le certificat en face n'est plus celui qu'ils ont eux-même
déployé dans leur navigateur et que le responsable du site leur avait
communiqué au départ…
Si tu tiens un site commercial, pourquoi avoir céder « au petit cadenas
» et « à la barre verte » alors qu'on voit bien que c'est totalement
inutile ?
Pire, les utilisateurs vont se croire en sécurité avec leur barre verte
et leur cadenas, alors qu'ils auraient du avoir une grosse alerte rouge
cramoisie que le certificat en face n'est plus celui qu'ils ont eux-même
déployé dans leur navigateur et que le responsable du site leur avait
communiqué au départ…
Et vous le lui avez communiqué comment, votre certificat, à votre client
à l'autre bout de la planète ? :-)
Cordialement,
Et vous le lui avez communiqué comment, votre certificat, à votre client
à l'autre bout de la planète ? :-)
Cordialement,
Et vous le lui avez communiqué comment, votre certificat, à votre client
à l'autre bout de la planète ? :-)
Cordialement,
Les certificats n'ont aucune raison d'être gardés secrets et peuvent
donc être librement mis à disposition sur Internet.
Après, 2 solutions.
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)…
Seul bémol (et l'actualité est là pour nous le rappeler), la clef privée
de la CA doit rester totalement secrète sous peine de tout voir s'écrouler…
Mais il te sera bien plus facile de mettre cette clef sous clef et
déconnectée du réseau que ne peut le faire les Root CA actuelles…
Les certificats n'ont aucune raison d'être gardés secrets et peuvent
donc être librement mis à disposition sur Internet.
Après, 2 solutions.
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)…
Seul bémol (et l'actualité est là pour nous le rappeler), la clef privée
de la CA doit rester totalement secrète sous peine de tout voir s'écrouler…
Mais il te sera bien plus facile de mettre cette clef sous clef et
déconnectée du réseau que ne peut le faire les Root CA actuelles…
Les certificats n'ont aucune raison d'être gardés secrets et peuvent
donc être librement mis à disposition sur Internet.
Après, 2 solutions.
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)…
Seul bémol (et l'actualité est là pour nous le rappeler), la clef privée
de la CA doit rester totalement secrète sous peine de tout voir s'écrouler…
Mais il te sera bien plus facile de mettre cette clef sous clef et
déconnectée du réseau que ne peut le faire les Root CA actuelles…
On 09/07/2011 04:57 PM, wrote:Je pense que tu veux parler des clefs privées ? Mais ça aurait empêché
toute automatisation...
A minima, le serveur ultime qui produit les certificat (et garde la
clé au chaud) aurait dû être totalement isolé du reste, avec un seul
port ouvert, genre RPC simple dans un langage qui rend l'exploitation
d'injection difficile, et qui répond à une seule commande "génère moi
le certificat pour .."
On 09/07/2011 04:57 PM, erwan@rail.eu.org wrote:
Je pense que tu veux parler des clefs privées ? Mais ça aurait empêché
toute automatisation...
A minima, le serveur ultime qui produit les certificat (et garde la
clé au chaud) aurait dû être totalement isolé du reste, avec un seul
port ouvert, genre RPC simple dans un langage qui rend l'exploitation
d'injection difficile, et qui répond à une seule commande "génère moi
le certificat pour .."
On 09/07/2011 04:57 PM, wrote:Je pense que tu veux parler des clefs privées ? Mais ça aurait empêché
toute automatisation...
A minima, le serveur ultime qui produit les certificat (et garde la
clé au chaud) aurait dû être totalement isolé du reste, avec un seul
port ouvert, genre RPC simple dans un langage qui rend l'exploitation
d'injection difficile, et qui répond à une seule commande "génère moi
le certificat pour .."
Le 07-09-2011, Fabien LE LEZ a écrit :J'ai lu (sur reddit je crois), il y a un ou deux mois, le message d'un
admin système qui demandait des conseils, car un "expert" chargé d'un
audit lui demandait la liste des mots de passe de tous ses
utilisateurs (en clair bien sûr), sur les six derniers mois.
<
http://serverfault.com/questions/293217/our-security-auditor-is-an-idiot-how-do-i-give-him-the-information-he-wants >
Le 07-09-2011, Fabien LE LEZ <gramster@gramster.com> a écrit :
J'ai lu (sur reddit je crois), il y a un ou deux mois, le message d'un
admin système qui demandait des conseils, car un "expert" chargé d'un
audit lui demandait la liste des mots de passe de tous ses
utilisateurs (en clair bien sûr), sur les six derniers mois.
<
http://serverfault.com/questions/293217/our-security-auditor-is-an-idiot-how-do-i-give-him-the-information-he-wants >
Le 07-09-2011, Fabien LE LEZ a écrit :J'ai lu (sur reddit je crois), il y a un ou deux mois, le message d'un
admin système qui demandait des conseils, car un "expert" chargé d'un
audit lui demandait la liste des mots de passe de tous ses
utilisateurs (en clair bien sûr), sur les six derniers mois.
<
http://serverfault.com/questions/293217/our-security-auditor-is-an-idiot-how-do-i-give-him-the-information-he-wants >
