Le rapport
(http://www.scribd.com/doc/64011372/Operation-Black-Tulip-v1-0) du
gouvernement hollandais est édifiant: des malwares sur les serveurs de
production les plus critiques, serveurs non patchés avec de multiples
vulnérabilités, etc.
Il serait intéressant de savoir comment un prestataire aussi incompétent
techniquement a pu se glisser dans la liste des autorités de certification.
Et combien d'autres autorités de certification sont aussi peu fiables ..
On Tue, 06 Sep 2011 18:29:25 +0200, Xavier Roche :
Si cela permet de faire une grosse purge dans ce panier de crabes que sont les autorités de certification, ainsi soit-il.
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 joli cadenas, sa sert surtout à rassurer Mme Michu, pour qu'elle n'hésite pas à faire marcher le commerce électronique.
Ah, j'oubliais la meilleure: les boites en question sont auditées par des "experts" en sécurité pour pouvoir faire partie du gotha des entreprises de confiance. Ce qui donne un éclairage édifiant sur le niveau de compétence de ces fameux experts ..
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.
On Tue, 06 Sep 2011 18:29:25 +0200, Xavier Roche
<xroche@free.fr.NOSPAM.invalid>:
Si cela permet de faire une grosse purge dans ce panier de crabes que
sont les autorités de certification, ainsi soit-il.
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 joli cadenas, sa sert surtout à rassurer Mme Michu, pour qu'elle
n'hésite pas à faire marcher le commerce électronique.
Ah, j'oubliais la meilleure: les boites en question sont auditées par
des "experts" en sécurité pour pouvoir faire partie du gotha des
entreprises de confiance. Ce qui donne un éclairage édifiant sur le
niveau de compétence de ces fameux experts ..
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.
On Tue, 06 Sep 2011 18:29:25 +0200, Xavier Roche :
Si cela permet de faire une grosse purge dans ce panier de crabes que sont les autorités de certification, ainsi soit-il.
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 joli cadenas, sa sert surtout à rassurer Mme Michu, pour qu'elle n'hésite pas à faire marcher le commerce électronique.
Ah, j'oubliais la meilleure: les boites en question sont auditées par des "experts" en sécurité pour pouvoir faire partie du gotha des entreprises de confiance. Ce qui donne un éclairage édifiant sur le niveau de compétence de ces fameux experts ..
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.
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 > -- Kevin
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 >
--
Kevin
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 > -- Kevin
Kevin Denis
Le 07-09-2011, Xavier Roche a écrit :
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 .."
Cela n'empêche pas de générer des faux certificats si la machine juste avant s'est faite router, mais au moins la clé ultime est protégée.
La machine juste avant ayant le même modèle, mais gérant les demandes des backends, eux même serveurs des front-end Web.
C'est évidemment simpliste, mais même un modèle aussi simpliste aurait probablement aidé à éviter le pire.
Mieux qu'un petit réseau installé par des bras cassés et ouvert sur l???extérieur directement. Même vis-à-vis des spécificités de sécurisation de l'infâme Hadopi, je pense que cela ne passerait pas..
Ca, ce n'est pas clair du tout. Le hacker dit que le réseau est déconnecté d'internet, l'audit par foxit dit que le réseau est accessible par un vlan d'admin, donc je ne m'avancerai pas.
Ceci dit, pas besoin d'avoir accès à la clé privé. J'imagine que les clés ne sont pas faites manuellement, si le pirate a accès au workflow, il lui suffit d'ajouter ses certificats à lui. Le gugus qui amène le workflow à faire signer ne fait peut-être pas attention au fait qu'il y ait 153 ou 155 clés à faire signer.. Le pirate indique aussi qu'il a du apprendre un langage spécifique http://en.wikipedia.org/wiki/Xuda pour faire signer ses certificats. Ca semble crédible. -- Kevin
Le 07-09-2011, Xavier Roche <xroche@free.fr.NOSPAM.invalid> a écrit :
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 .."
Cela n'empêche pas de générer des faux certificats si la machine juste
avant s'est faite router, mais au moins la clé ultime est protégée.
La machine juste avant ayant le même modèle, mais gérant les demandes
des backends, eux même serveurs des front-end Web.
C'est évidemment simpliste, mais même un modèle aussi simpliste aurait
probablement aidé à éviter le pire.
Mieux qu'un petit réseau installé par des bras cassés et ouvert sur
l???extérieur directement. Même vis-à-vis des spécificités de sécurisation
de l'infâme Hadopi, je pense que cela ne passerait pas..
Ca, ce n'est pas clair du tout. Le hacker dit que le réseau est
déconnecté d'internet, l'audit par foxit dit que le réseau est
accessible par un vlan d'admin, donc je ne m'avancerai pas.
Ceci dit, pas besoin d'avoir accès à la clé privé. J'imagine que les
clés ne sont pas faites manuellement, si le pirate a accès au workflow,
il lui suffit d'ajouter ses certificats à lui. Le gugus qui amène le
workflow à faire signer ne fait peut-être pas attention au fait qu'il
y ait 153 ou 155 clés à faire signer..
Le pirate indique aussi qu'il a du apprendre un langage spécifique
http://en.wikipedia.org/wiki/Xuda pour faire signer ses certificats.
Ca semble crédible.
--
Kevin
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 .."
Cela n'empêche pas de générer des faux certificats si la machine juste avant s'est faite router, mais au moins la clé ultime est protégée.
La machine juste avant ayant le même modèle, mais gérant les demandes des backends, eux même serveurs des front-end Web.
C'est évidemment simpliste, mais même un modèle aussi simpliste aurait probablement aidé à éviter le pire.
Mieux qu'un petit réseau installé par des bras cassés et ouvert sur l???extérieur directement. Même vis-à-vis des spécificités de sécurisation de l'infâme Hadopi, je pense que cela ne passerait pas..
Ca, ce n'est pas clair du tout. Le hacker dit que le réseau est déconnecté d'internet, l'audit par foxit dit que le réseau est accessible par un vlan d'admin, donc je ne m'avancerai pas.
Ceci dit, pas besoin d'avoir accès à la clé privé. J'imagine que les clés ne sont pas faites manuellement, si le pirate a accès au workflow, il lui suffit d'ajouter ses certificats à lui. Le gugus qui amène le workflow à faire signer ne fait peut-être pas attention au fait qu'il y ait 153 ou 155 clés à faire signer.. Le pirate indique aussi qu'il a du apprendre un langage spécifique http://en.wikipedia.org/wiki/Xuda pour faire signer ses certificats. Ca semble crédible. -- Kevin
luser
Dans son message précédent, a écrit :
luser écrivait :
Et surtout, les machines contenant les certificats racines n'auraient-elle pas du etre completement deconnectées de tout réseaux?
++
Je pense que tu veux parler des clefs privées ? Mais ça aurait empêché toute automatisation...
Dans mon stage de fin d'etudes en 2001, dans une boite qui s'occupait de chiffrement et de certificats, mon maitre de stage m'avait fait créer un environnement complet de (auto)certification et sa préconisation principale était que les machines contenant les certificats racines servant à signer le reste, soient déconnectées de tout réseau et que les certifs à signer soient transférés par disquette (ou clé usb de nos jours).
EN fait ce qui tue le SSL ce sont les contraintes économiques des CA commerciaux qui ne peuvent pas se permettre de manipulations manuelles...
Dur alors d'éviter le pire...
++
Dans son message précédent, erwan@rail.eu.org a écrit :
luser <luser@invalid.fr> écrivait :
Et surtout, les machines contenant les certificats racines
n'auraient-elle pas du etre completement deconnectées de tout réseaux?
++
Je pense que tu veux parler des clefs privées ? Mais ça aurait empêché
toute automatisation...
Dans mon stage de fin d'etudes en 2001, dans une boite qui s'occupait
de chiffrement et de certificats, mon maitre de stage m'avait fait
créer un environnement complet de (auto)certification et sa
préconisation principale était que les machines contenant les
certificats racines servant à signer le reste, soient déconnectées de
tout réseau et que les certifs à signer soient transférés par disquette
(ou clé usb de nos jours).
EN fait ce qui tue le SSL ce sont les contraintes économiques des CA
commerciaux qui ne peuvent pas se permettre de manipulations
manuelles...
Et surtout, les machines contenant les certificats racines n'auraient-elle pas du etre completement deconnectées de tout réseaux?
++
Je pense que tu veux parler des clefs privées ? Mais ça aurait empêché toute automatisation...
Dans mon stage de fin d'etudes en 2001, dans une boite qui s'occupait de chiffrement et de certificats, mon maitre de stage m'avait fait créer un environnement complet de (auto)certification et sa préconisation principale était que les machines contenant les certificats racines servant à signer le reste, soient déconnectées de tout réseau et que les certifs à signer soient transférés par disquette (ou clé usb de nos jours).
EN fait ce qui tue le SSL ce sont les contraintes économiques des CA commerciaux qui ne peuvent pas se permettre de manipulations manuelles...
Dur alors d'éviter le pire...
++
Kevin Denis
Le 07-09-2011, luser a écrit :
Dans mon stage de fin d'etudes en 2001, dans une boite qui s'occupait de chiffrement et de certificats, mon maitre de stage m'avait fait créer un environnement complet de (auto)certification et sa préconisation principale était que les machines contenant les certificats racines servant à signer le reste, soient déconnectées de tout réseau et que les certifs à signer soient transférés par disquette (ou clé usb de nos jours).
C'est précisément le point. QUI surveille le contenu de cette clé USB? Si tu as la main sur le PC qui génère la liste de clés à certifier, alors il est simple d'en ajouter une.. -- Kevin
Le 07-09-2011, luser <luser@invalid.fr> a écrit :
Dans mon stage de fin d'etudes en 2001, dans une boite qui s'occupait
de chiffrement et de certificats, mon maitre de stage m'avait fait
créer un environnement complet de (auto)certification et sa
préconisation principale était que les machines contenant les
certificats racines servant à signer le reste, soient déconnectées de
tout réseau et que les certifs à signer soient transférés par disquette
(ou clé usb de nos jours).
C'est précisément le point. QUI surveille le contenu de cette clé USB?
Si tu as la main sur le PC qui génère la liste de clés à certifier,
alors il est simple d'en ajouter une..
--
Kevin
Dans mon stage de fin d'etudes en 2001, dans une boite qui s'occupait de chiffrement et de certificats, mon maitre de stage m'avait fait créer un environnement complet de (auto)certification et sa préconisation principale était que les machines contenant les certificats racines servant à signer le reste, soient déconnectées de tout réseau et que les certifs à signer soient transférés par disquette (ou clé usb de nos jours).
C'est précisément le point. QUI surveille le contenu de cette clé USB? Si tu as la main sur le PC qui génère la liste de clés à certifier, alors il est simple d'en ajouter une.. -- Kevin
Aéris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 07/09/2011 17:21, Kevin Denis a écrit :
Ceci dit, pas besoin d'avoir accès à la clé privé. J'imagine que les clés ne sont pas faites manuellement, si le pirate a accès au workflow, il lui suffit d'ajouter ses certificats à lui. Le gugus qui amène le workflow à faire signer ne fait peut-être pas attention au fait qu'il y ait 153 ou 155 clés à faire signer..
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 ?
- -- Aeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Ceci dit, pas besoin d'avoir accès à la clé privé. J'imagine que les
clés ne sont pas faites manuellement, si le pirate a accès au workflow,
il lui suffit d'ajouter ses certificats à lui. Le gugus qui amène le
workflow à faire signer ne fait peut-être pas attention au fait qu'il
y ait 153 ou 155 clés à faire signer..
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 ?
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Ceci dit, pas besoin d'avoir accès à la clé privé. J'imagine que les clés ne sont pas faites manuellement, si le pirate a accès au workflow, il lui suffit d'ajouter ses certificats à lui. Le gugus qui amène le workflow à faire signer ne fait peut-être pas attention au fait qu'il y ait 153 ou 155 clés à faire signer..
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 ?
- -- Aeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
C'est précisément le point. QUI surveille le contenu de cette clé USB? Si tu as la main sur le PC qui génère la liste de clés à certifier, alors il est simple d'en ajouter une..
Théoriquement non.
La clef USB ne contient que des *demandes* de certificats, avec l'ensemble des pièces justificatives de l'identité du demandeur. Selon le workflow SSL, c'est celui qui génère réellement le certificat qui est en charge de la vérification de l'identité et ne devrait pas signer bêtement toute demande lui parvenant. Et en sortie, la clef USB contiendrait les certificats générés.
Forcément, si tu considères toutes les demandes arrivant à la clef privée comme valide, tu vas au-devant de sacrés problèmes…
- -- Aeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
C'est précisément le point. QUI surveille le contenu de cette clé USB?
Si tu as la main sur le PC qui génère la liste de clés à certifier,
alors il est simple d'en ajouter une..
Théoriquement non.
La clef USB ne contient que des *demandes* de certificats, avec
l'ensemble des pièces justificatives de l'identité du demandeur.
Selon le workflow SSL, c'est celui qui génère réellement le certificat
qui est en charge de la vérification de l'identité et ne devrait pas
signer bêtement toute demande lui parvenant.
Et en sortie, la clef USB contiendrait les certificats générés.
Forcément, si tu considères toutes les demandes arrivant à la clef
privée comme valide, tu vas au-devant de sacrés problèmes…
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
C'est précisément le point. QUI surveille le contenu de cette clé USB? Si tu as la main sur le PC qui génère la liste de clés à certifier, alors il est simple d'en ajouter une..
Théoriquement non.
La clef USB ne contient que des *demandes* de certificats, avec l'ensemble des pièces justificatives de l'identité du demandeur. Selon le workflow SSL, c'est celui qui génère réellement le certificat qui est en charge de la vérification de l'identité et ne devrait pas signer bêtement toute demande lui parvenant. Et en sortie, la clef USB contiendrait les certificats générés.
Forcément, si tu considères toutes les demandes arrivant à la clef privée comme valide, tu vas au-devant de sacrés problèmes…
- -- Aeris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
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"? -- Kevin
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"?
--
Kevin
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"? -- Kevin
Nicolas George
Aéris , dans le message <4e67a33f$0$10632$, a écrit :
Euh... Rappelle-moi pourquoi on paie une fortune un certificat SSL ?
Parce que les autorités de certification sont en situation d'oligopole.
Aéris , dans le message <4e67a33f$0$10632$426a74cc@news.free.fr>, a
écrit :
Euh... Rappelle-moi pourquoi on paie une fortune un certificat SSL ?
Parce que les autorités de certification sont en situation d'oligopole.
