Certificat SSL

On Thu, 13 Jan 2005, Patrick Mevzek wrote:

ignorée? Si vous ne configurez pas vos logiciels pour valider un
certificat par rapport à la CRL de son AC, c'est purement et simplement
votre problème.

C'est où dans Windows (je parle bien de l'OS et pas d'une application
s'exécutant sur cet OS) qu'on configure
1) la liste des AC reconnues

Démarrer, Panneau de configuration, Options Internet, onglet Contenu.

2) les CRLs employées ?

Aucune idée.

Perso, je ne sais pas moi-meme, mais n'étant pas sous windows, ca m'est
égal. Je doute que cela soit très connu. C'est peut-etre meme impossible
à faire ?

Peut-être. Si c'est bien le cas, c'est donc une faute de Microsoft. Ils ne
sont pas à ça prêt. C'est du même coup une faute de l'utilisateur de
continuer à utiliser cet OS, s'il veut un bon support PKI. D'autant que
les applications Microsoft qui gèrent les CRL ne le font pas correctement
(la CRL n'est pas téléchargée avant la date nextUpdate indiquée).

Pour le certificat MS en question la bourde est ``réparée'' sous forme de
patch à Windows via Windows Update & co !

Et ce patch contenait quoi? Une CRL, et un petit bout de code qui vérifie
la CRL. Ce qui signifie donc que cette étape n'était pas faite auparavant.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Que veut dire respecter la netiquette et oû se trouve
l'option follow up to ???
-+- K in GNU : Configurer le fu2 vers la Nétiquette -+-

Bonjour,

On Thu, 13 Jan 2005, Dominique Blas wrote:

Erwann ABALEA wrote:

Leur plate forme est mutualisée, ce qui signifie que c'est strictement la
même pour délivrer des certificats serveurs que des certificats
utilisateurs (et autres). S'ils avaient à maintenir une plate forme
séparée juste pour des certificats utilisateurs sous leur AC (machines,
surface, electricité, contrats de maintenance, temps d'administration,
gestion des pannes, etc), le coût aurait été sensiblement supérieur. C'est
tout l'intérêt de la mutualisation.
Ok, très bien.

Mais qu'en est-il de la qualité du certificat utilisateur par rapport au
certificat de serveur ? Les usages ne sont pas les mêmes nous sommes
d'accord mais parfois, je dis bien parfois, la qualité demandée à un
cerificat utilisateur surpasse celle que l'on est en droit d'attendre d'un
certif serveur.

Je ne comprends pas votre question. Qu'entendez-vous par 'qualité du
certificat'?

Coment cela se passe-t-il alors che les << grands >>.
Osent-ils conseiller alors de créer sa propre AC ?

Bien sûr! Moins de travail, plus de pognon. C'est tout bénef'. Dans
certains cas, c'est la seule façon de faire.

Il faut bien comprendre ce que représente un certificat X.509. C'est une
identité. Et une identité n'a de valeur que par rapport à un référentiel
donné. Exemple:
- je suis Erwann Abalea, j'ai un état civil, des papiers qui le prouvent,
j'ai donc une identité pour l'Etat.
- je suis un assuré social, avec un numéro de sécu. J'ai donc une autre
identité pour la Sécu (si vous considérez que mon identité par rapport
à l'Etat et par rapport à la Sécu est la même, considérez l'identité de
vos enfants dans ces 2 référentiels)
- je suis un déclarant, au sens où je déclare mes impôts, j'ai également
une identité pour la DGI
- je suis employé par la société X, qui est la seule habilitée à déclarer
que j'occupe tel ou tel poste, personne d'autre ne peut le faire à sa
place
- ...

Chacun de nous a donc plusieurs identités, il est normal qu'il y ait
plusieurs AC.

Non. Je n'ai pas assez mis en avant le "(je le sais)", mais ça veut bien
dire ce que ça veut dire. Malheureusement, je ne peux pas en dire plus,
mais vous devriez arriver à imaginer quelque chose qui pourrait être non
loin de la vérité. ;)
Hum, pour ma part je refuse le soi-disant << faites nous confiance >>. C'est

ce que répètent les banquiers, machinalement, à longueur de jour en ce qui
concerne la sécurité des paiements par CB. Or, << je sais bien >> qu'il
n'en est rien !

Et pourtant vous leur faites confiance, sinon vous n'auriez pas de compte
en banque, pas de moyen de paiement, ...

Pourquoi en serait-il différemment chez un prestataire de certificats ?
Parce que VOUS l'ASSUREZ ?
Désolé, ça ne me suffit pas. En d'autres termes votre parole ne me suffit
pas et ce, quel que soit le niveau d'expertise auquel vous intervenez.
Et cela me suffira d'autant moins que la prestation réalisée par ledit
prestataire sera médiatisée.

Vous avez raison, strictement parlant. Mais le début de la discussion
portait sur la différence entre un certificat délivré par une AC type
VeriSign et une AC faite dans son coin avec quelques scripts...

Je suppose que vous avez supprimé de votre magasin de certificat toutes
les AC que vous n'avez pas audité vous-même? ;)

[...]

Bien sûr. L'erreur est humaine, ce ne sont pas des machines qui font le
travail. De plus, il s'agit d'une seule erreur. En connaissez-vous
d'autres?
A mon avis si une erreur aussi médiatique s'est glissée bien d'autres

ont eu lieu et courrent encore aujourd'hui.
En sécurité comme en mathématique un seul contre-exemple fiche le théorème
par terre.

N'avez-vous jamais fait d'erreur vous-même, même dans l'exercice
de votre métier, ce pour quoi on vous paye?

Oh que si, et heureusement, mais je ne pèse pas plusieurs milliards de

dollars
et ne dispose donc pas de l'infrastructure adéquate pour éviter ce genre de
désagrément.

Vous n'obtiendrez jamais le risque 0, quoi que vous fassiez. Il faut quand
même que les certificats soient délivrés, ça reste une opération humaine,
et les humains sont faillibles. Donc l'ensemble du process est faillible.
Le fait de peser plusieurs milliards de dollars ne change rien.

Je ne prétends pas délivrer de certificats à la planète entière ni

Mais... Qui vous oblige à acheter des certificats VRSN? Personne. Vous
reprochez à VRSN de vendre des certificats et de vouloir en vendre le plus
possible. C'est idiot.

Ce que je veux dire également c'est que l'attribution des certificats est
avant tout un travail de proximité et certainement pas un boulot à
dimension planétaire.

Toutafé.

Je vois mal comment une boîte étrangère pourrait enquêter sur la justesse
d'une demande française. Via sa filliale ?

Ben oui.

Raison pour laquelle je privilégie les tiers de confiance français et
préférence sans techno étrangère impliquée !

Du pur franco français, donc. Vous en avez trouvé? ;)

Parlons-en de la confiance justement, car c'est de cela dont il est
question.
Selon moi, aujourd'hui, pour un périmètre relativement restreint d'acteurs,
une communauté, par exemple celle de l'automobile en France (qui comprend
les constructeurs et les fournisseurs) il est bien plus intéressant et
économique de gérer elle-même sa confiance plutôt que de faire confiance à
une entité étrangère à cette communauté.

Oui, ce qui rejoint mon point développé plus haut.

A une échelle plus petite si vous me connaissez bien et que nous nous voyons
régulièrement (et pouvons donc en parler) je pense que vous ferez davantage
confiance à un certif racine émis par moi-même plutôt qu'un certif racine
émis par une autorité reconnue. N'est-ce pas ?

Ca dépend. Faire confiance dans une racine X.509 signifie à la fois faire
confiance à l'identité de cette racine *et* faire confiance à ses
pratiques de certification. Si on reporte ça sur le modèle PGP, cela
signifie que vous déclarez à la fois que vous avez vérifié l'identité
d'untel et sa clé publique déclarée, *et* que vous considérez que les
signatures faites par ce untel sont dignes de confiance...

Ceci d'autant que peu de personnes, peu d'applications vont vérifier la
réalité du certificat racine de l'autorité reconnue.

Oui. Et comme de toute façon la procédure pour faire ça proprement est
compliquée et nécessite des moyens non négligeables, c'est rarement fait
correctement.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
bio> Qui peut encore croire que le bio est reserve aux gens
bio> financierement aises?
Tous les gens qui ne sont pas financierement aises.
-+- DC in <http://neuneu.mine.nu> : À l'aise blaise -+-

"Patrick Mevzek" <pm-N200501@nospam.dotandco.com> wrote in message
news:pan.2005.01.13.14.06.47.36282.18513@nospam.dotandco.com

C'est où dans Windows (je parle bien de l'OS et pas d'une application
s'exécutant sur cet OS) qu'on configure 1) la liste des AC reconnues 2)
les CRLs employées ?

Je ne comprends pas bien la question. En quoi l'OS aurait-il besoin de
reconnaître des AC ?

Vérification de la signature des applis téléchargées (ActiveX), à moins
que ce soit le navigateur IE qui gère cela.

Et pour les voir, tu as IE qui se base sur le magasin de certificats
Microsoft.

``magasin de certificats'' : c'est donc bien une fonctionnalité de l'OS
et non d'une appli en particulier.

Perso, je ne sais pas moi-meme, mais n'étant pas sous windows, ca m'est
égal. Je doute que cela soit très connu. C'est peut-etre meme
impossible à faire ?

Arf, en retournant la question, où dans un système unix serait la liste
des AC reconnues ?

Il n'y en a pas, car sous Unix ce n'est pas l'OS qui utilise ou vérifie
des certificats. C'est openssl, ou une surcouche, ou un navigateur,
etc... etc...

Sous Windows, c'est moins clair.
La correction de la bourde Verisign entrainait le téléchargement d'un
patch pour *windows* et non pas pour *IE* IIRC.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Bonjour,

On Thu, 13 Jan 2005, Patrick Mevzek wrote:

Je n'ai pas assez mis en avant le "(je le sais)", mais ça veut bien
dire ce que ça veut dire. Malheureusement, je ne peux pas en dire plus,
mais vous devriez arriver à imaginer quelque chose qui pourrait être non
loin de la vérité. ;)

Ca veut dire que vous avez audité de manière approfondie le
fonctionnement de toutes les AC ?

Toutes les AC? Pas la peine, celles de VRSN suffisent.

Bien sûr. L'erreur est humaine, ce ne sont pas des machines qui font le
travail. De plus, il s'agit d'une seule erreur. En connaissez-vous
d'autres?

Je doute fort que les AC les clament sur tous les toits. D'ailleurs
comment identifier l'erreur d'une AC ? Personne ne peut, si ce n'est la
personne qui a réussit à avoir un certificat sans rapport avec son
entité. Et si c'est à des fins frauduleuses, je doute qu'elle le clame
sur tous les toits aussi.

On peut quand même faire un audit sur ce qu'il s'est passé, voir les
traces d'activité, et détecter quelques erreurs.

Ce certificat a été révoqué dans les semaines qui ont suivi mais qui
vérifie la validité d'un certificat de nos jours ? A part la date
d'expiration et encore.

Sur ce point, la faute n'est pas aux fournisseurs de certificat, mais
bien aux développeurs de logiciel.

La faute est à l'AC de fournir des certificats sans vérifier l'adéquation
entre le demandeur et l'objet certifié.

C'est une faute de l'AC, soit. Mais ne pas faire le travail de
vérification correctement est aussi une faute.

ignorée? Si vous ne configurez pas vos logiciels pour valider un
certificat par rapport à la CRL de son AC, c'est purement et simplement
votre problème.

Pas d'accord, quand le certificat est erroné *dès* sa fabrication.
L'usage des CRL est certes très recommandée, mais cela *n'exonère* pas
l'AC de faire son travail correctement !

Je n'ai jamais rien dit de tel. Mais autant il est du ressort de l'AC de
s'assurer de l'identité des entités à lesquelles elle délivre un
certificat, autant il est du ressort des usagers (machines ou humains) de
vérifier correctement les certificats. Et cette étape de vérification
passe obligatoirement par la vérification de la CRL, si celle-ci existe.
Après tout, la majorité des certificats révoqués ne sont pas du fait de
l'AC.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----

- Bientot==> Une rubrique membre avec photos
- Bientot==> "Un chat on line" pour discuter
Si j'amène la photo de mon membre, je pourai caresser le chat ?

-+- FF in Guide du Neuneu Usenet - Cha chanonchait bien pourtant -+-

Ca veut dire que vous avez audité de manière approfondie le
fonctionnement de toutes les AC ?

Toutes les AC? Pas la peine, celles de VRSN suffisent.

C'est marrant, mon navigateur n'est pas d'accord avec vous...

Netcraft non plus apparemment:
http://www.hosttrail.com/web-hosting-news/07-04/netcraft-0701.php

Je doute fort que les AC les clament sur tous les toits. D'ailleurs
comment identifier l'erreur d'une AC ? Personne ne peut, si ce n'est la
personne qui a réussit à avoir un certificat sans rapport avec son
entité. Et si c'est à des fins frauduleuses, je doute qu'elle le clame
sur tous les toits aussi.

On peut quand même faire un audit sur ce qu'il s'est passé, voir les
traces d'activité, et détecter quelques erreurs.

Hors de l'AC, sans voir les certificats délivrés et les entités
référencés dans les certificats, je vois difficilement comment.

Question travail des utilisateurs, et tout, je suis tombé sur ca:
http://news.netcraft.com/archives/2003/06/27/certificate_authorities_careless_about_ssl_security.html
et ca m'a bien fait rire...

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Arf, en retournant la question, où dans un système unix serait la liste
des AC reconnues ?

De plus en plus de distributions Linux utilisent la liste des AC du
projet Mozilla,

Autant que je sache, Mozilla n'est pas un système unix...

Il est facile de trouver sa configuration.
Par contre j'attends toujours la réponse à ma question, sans qu'on me
réponde par une autre question.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

On Thu, 13 Jan 2005, Patrick Mevzek wrote:

ignorée? Si vous ne configurez pas vos logiciels pour valider un
certificat par rapport à la CRL de son AC, c'est purement et
simplement votre problème.

C'est où dans Windows (je parle bien de l'OS et pas d'une application
s'exécutant sur cet OS) qu'on configure 1) la liste des AC reconnues

Démarrer, Panneau de configuration, Options Internet, onglet Contenu.

Je n'ai pas Windows sous les yeux, mais de mémoire, ca ouvre les
préférences d'IE (page de démarrage, cache Web, etc...)
Amusant de voir la distinction (absente) entre l'OS et l'appli.

2) les CRLs employées ?

Aucune idée.

Vous m'expliquez alors comment les utilisateurs peuvent s'assurer que les
CRLs sont bien employées pour les ACs en question puisque selon vous c'est
leur travail (cf le quote plus haut) ?

Perso, je ne sais pas moi-meme, mais n'étant pas sous windows, ca m'est
égal. Je doute que cela soit très connu. C'est peut-etre meme
impossible à faire ?

Peut-être. Si c'est bien le cas, c'est donc une faute de Microsoft. Ils
ne sont pas à ça prêt. C'est du même coup une faute de l'utilisateur de
continuer à utiliser cet OS,

Je me disais bien, fallait que ca retombe sur l'utilisateur :-)

Si je suis tout à fait d'accord pour dire que l'utilisateur est souvent
le maillon faible, et qu'il ne peut y avoir un minimum de sécurité que si
l'utilisateur s'éduque un minimum, je ne suis pas d'accord pour
systématiquement rejeter la faute sur lui et j'estime que c'est aussi la
faute des vendeurs au sens large.

Pourquoi une AC, qui fournit des certificats et maintient des CRLs, ne
verifierait-elle pas que les CRLs en question sont bien utilisés, à
savoir que les applications utilisant ses certificats utilisent aussi ses
CRLs ? Ca ne coute pas cher de maintenir une page listant les cas de
figure, à charge pour l'utilisateur de se renseigner. Mais pas à charge
pour lui de faire le travail des autres, et de chercher les détails.

Parce qu'en résumé de l'histoire:
l'AC n'y est pour rien car l'utilisateur doit s'assurer de bien utiliser
les CRLs que l'AC maintient et tant pis pour l'utilisateur c'est bien
fait pour lui si au final, concrétement, il n'a aucun moyen d'assurer
qu'il utilise les CRLs en question ni même de le vérifier !

Pour le certificat MS en question la bourde est ``réparée'' sous forme
de patch à Windows via Windows Update & co !

Et ce patch contenait quoi? Une CRL, et un petit bout de code qui
vérifie la CRL.

On met à jour donc une partie de l'OS, a propos d'une fonctionnalité sur
laquelle l'utilisateur n'a aucun pouvoir (cf plus haut).
Ca donne super confiance...

Ce qui signifie donc que cette étape n'était pas faite
auparavant.

Ca donne super confiance...

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Le Wed, 12 Jan 2005 15:45:44 +0000, VANHULLEBUS Yvan a écrit :

complexe), mais pour un "simple certificat", techniquement parlant, la
seule difference est effectivement l'autorite de certification, connue
et deja diffusee d'un cote, pas connue et a diffuser de facon fiable
de l'autre....

Merci. Quand tu dis "a diffuser de façon fiable", ça ne prend pas en
compte le certificat généré par soi-même, et téléchargé par le
navigateur à la première connexion SSL ?

--

DAPL
http://marreduspam.com/ad252602

DAPL <pasdespam@free.fr> writes:

Le Wed, 12 Jan 2005 15:45:44 +0000, VANHULLEBUS Yvan a écrit :

complexe), mais pour un "simple certificat", techniquement parlant, la
seule difference est effectivement l'autorite de certification, connue
et deja diffusee d'un cote, pas connue et a diffuser de facon fiable
de l'autre....

Merci. Quand tu dis "a diffuser de façon fiable", ça ne prend pas en
compte le certificat généré par soi-même, et téléchargé par le
navigateur à la première connexion SSL ?

Reprenons....

D'abord, j'ai toujours parle d'un point de vue *purement technique*,
la ou d'autres se sont engages plus ou moins sur l'aspect "valeur
ajoutee", aspect que j'avais juste evoque.

Donc techniquement parlant, un certificat X509 est un certificat X509,
qu'il ait ete genere a cher, par une societe reputee, dans un bunker,
ou par ma grand mere avec OpenSSL.....

Et un certificat serveur est techniquement identique a un certificat
utilisateur, et aussi a un certificat de CA. La seule difference,
c'est les bits d'utilisation ("ce certificat est succeptible d'etre
utilise pour signer d'autres certificats", etc...).



Pour ce qui est de "transmettre de facon fiable", on a en fait affaire
a un bete probleme de poule et d'oeuf: On peut valider un certificat
si on a deja le certificat de la CA qui correspond, mais pour diffuser
ce certificat de CA de facon fiable, on ne peut pas se contenter de la
signer avec son certificat utilisateur/serveur, puisqu'on ne pourra
valider celui -ci qu'une fois qu'on aura le certif. de la CA....


Il faut donc d'abord une facon fiable de diffuser le certificat de la
CA, et c'est la qu'arrive une partie de la valeur ajoutee des societes
de certification: leurs certificats roots sont deja diffuses de facon
presumee fiable.


A +

VANHU.

Le Mon, 17 Jan 2005 10:20:41 +0000, VANHULLEBUS Yvan a écrit :

Reprenons....

Ok pour tout ça...

Pour ce qui est de "transmettre de facon fiable", on a en fait affaire
a un bete probleme de poule et d'oeuf: On peut valider un certificat
si on a deja le certificat de la CA qui correspond, mais pour diffuser
ce certificat de CA de facon fiable, on ne peut pas se contenter de la
signer avec son certificat utilisateur/serveur, puisqu'on ne pourra
valider celui -ci qu'une fois qu'on aura le certif. de la CA....

Certes, mais alors quid des serveurs HTTPS dont la CA ne fait pas partie
de la liste des CA du navigateur ?


--

DAPL
http://marreduspam.com/ad252602