OVH Cloud OVH Cloud

Certificat SSL

62 réponses
Avatar
DAPL
Bonjour,

Je voudrais savoir la différence entre un certificat SSL généré par un
serveur Linux interne (donc avec l'identité de la société) et ceux
fournis (cher !) par des sociétés comme Thawte. Est-ce dû au simple
fait que l'autorité de certification est connue et donc intégrée à la
plupart des navigateurs ?

Merci de vos lumières.

--

DAPL
http://marreduspam.com/ad252602

10 réponses

Avatar
Patrick Mevzek
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...


Non. Je n'ai pas dit cela. Il serait peut-être bon d'apprendre à lire.


Ca commence bien...

Je prend la Debian, et son package ca-certificates, qui provient en
grande partie de Mozilla:


Et donc on sait où sont les certificats.
(man dpkg et option -L)

Beaucoup de bruit pour rien.

--
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>




Avatar
VANHULLEBUS Yvan
DAPL writes:

Le Mon, 17 Jan 2005 16:14:10 +0000, VANHULLEBUS Yvan a écrit :

[Faux certificat]


Oui, mais la communication est tout de même chiffrée vue par qqu'un de
l'extérieur.


Yep.

Sauf que, pour quelqu'un qui est bien place pour faire un Man in the
Middle (ou qui peut s'arranger pour "devenir" bien place), bah il
n'est plus "de l'exterieur", mais il a la possibilite de devenir
l'extremite des 2 sessions (une vers le client, une vers le vrai
serveur, eventuellement). Donc de tout voir en clair, et de pouvoir
modifier ce qu'il veut.


A +

VANHU.

Avatar
Erwann ABALEA
On Tue, 18 Jan 2005, Patrick Mevzek wrote:

C'est une fonctionnalité de la CAPI, à mettre au même niveau qu'OpenSSL
dont vous parlez plus bas. Une application qui n'utilise pas la CAPI
n'utilisera pas cette liste des AC.


[..]

Non, pour la CAPI, qui fait partie intégrante de Windows, au même titre
qu'IE.


Il faudrait savoir: la CAPI est équivalente à OpenSSL mais en même temps
fait partie de Windows.

Je suis désolé mais OpenSSL ne fait partie d'aucun système Unix. C'est
une bibliothèque comme une autre....


Bien. La CAPI est une bibliothèque, au même titre qu'OpenSSL. Le fait que
Microsoft ait fortement intégré la CAPI à Windows est le choix strict de
Microsoft. Cela ne change rien au fait que c'est bien une bibliothèque, et
qu'on peut l'utiliser ou non.

Pareil, IE et son moteur HTML est fortement intégré à Windows, au point
que ça en fait partie intégrante, dixit Microsoft. Mais ça n'empêche pas
qu'on peut ne pas utiliser son moteur HTML.

Ca tourne en dialogue de sourd là...

--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
When uncertain, or in doubt, run in circles and scream.


Avatar
Erwann ABALEA
On Tue, 18 Jan 2005, Patrick Mevzek wrote:

Pourquoi une AC, qui fournit des certificats et maintient des CRLs, ne
verifierait-elle pas que les CRLs en question sont bien utilisés, à


Bien. Je suis une AC, je publie ma CRL régulièrement. Comment est-ce que
je peux vérifier que telle ou telle application est bien configurée et
télécharge correctement la CRL? C'est n'importe quoi.


L'AC sait a priori où est installé son certificat non ?


C'est là le problème. Absolument pas. Si je décide de faire explicitement
confiance à une AC quelconque, je n'ai *pas* à prévenir cette AC. Donc
cette AC ne sait *pas* où est installé ce certificat. Une AC peut
évidemment savoir que son certificat a été installé par défaut avec
Windows/IE/CAPI ou Netscape/Mozilla, mais ailleurs...

Là où s'est installé elle pourrait demander à vérifier que la CRL est
bien utilisée.


Tu retournes le problème. Qui a besoin de confiance? L'utilisateur de
certificat (Microsoft, Mozilla, ... ou l'utilisateur lambda). Qui fournit
la confiance? L'AC. C'est donc à celui qui a besoin de confiance de
s'appuyer sur ce que lui fournit le fournisseur de confiance, pas au
fournisseur de la confiance de s'assurer que tout le monde fait bien son
travail.

Ah, évidemment, ca demanderait un peu de travail et un peu d'argent, je
concois bien que ca embêterait les AC de ne plus faire quasimment 100% de
marge mais moins....


Détaille tes 100%, et on en reparle.

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.


Ca ne coûte pas cher, c'est faux. Liste les différentes versions d'IE,
Mozilla/Netscape, Lotus Notes, Opera, ... Et fais les tests. Tu verras
si ça ne coûte pas cher.


Les AC ont de l'argent, non, au prix où elles vendent les certificats....


Là encore, tu mélanges, ou inverse les besoins.

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 !


Mais oui. Si le GIE CB publie une liste noire des cartes en opposition
mais que tu ne l'utilise pas, ça n'est pas de la faute du GIE quand
même!


Vous mélangez tout là. On parle d'un utilisateur final. Pas d'un
intermédiaire.


Mais qui se fait flouer dans mon analogie? Pas l'utilisateur final, le
commerçant, qui a choisi son terminal de paiement. Celui qui a le choix,
et qui a choisi une solution bancale. Il était peut-être mal renseigné,
mais ça n'est pas non plus de la responsabilité du GIE. Le GIE édicte des
règles, à chacun de faire son travail et de les respecter.

--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
Excusez-moi pour ce message perso mais y'a urgence.
Régis X de Chambéry et Thierry Y de Strasbourg sont priés de prendre
contact avec le Bureau de LUCCAS par mail.
-+- In : GNU - Le bonheur c'est simple comme un coup de fil -+-



Avatar
Erwann ABALEA
On Tue, 18 Jan 2005, Patrick Mevzek wrote:

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...


Non. Je n'ai pas dit cela. Il serait peut-être bon d'apprendre à lire.


Ca commence bien...


Ca tourne quand même en dialogue de sourd cette enfilade... Vos raccourcis
et remarques sur des choses que je n'ai pas écrites, c'est un peu lassant.
Non, Mozilla n'est pas un système Unix, je suis d'accord avec vous. Mais
d'un autre côté, je n'ai jamais dit cela, donc je ne vois pas en quoi ça
fait avancer les choses.

Je prend la Debian, et son package ca-certificates, qui provient en
grande partie de Mozilla:


Et donc on sait où sont les certificats.
(man dpkg et option -L)

Beaucoup de bruit pour rien.


Non, pour une réponse. Mais vous ètes libre de poser la question et
d'ignorer la réponse. Ne vous étonnez pas que le reste du monde fasse de
même.

Le fait que Debian et RedHat utilisent (ou souhaitent utiliser) la liste
des certificats de Mozilla pour la metter à disposition des autres
applications qui en auraient besoin est une réponse à la question (je
cite):
"> Arf, en retournant la question, où dans un système unix serait la liste
des AC reconnues ?"


En élargissant aux distributions basées sur Debian et RedHat, ça commence
à faire du monde. On reste toujours sur un Linux, certes.

Maintenant, si vous connaissez si bien Debian au point de vous contenter
d'un "dpkg -L ca-certificates" comme réponse, vous auriez pu vous forcer
un peu et chercher par vous-même.

--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
AB> Comment cela peut-il se débloquer ?
AT> Fuca.
Excusez-moi, je n'ai pas compris. Merci de répondre plus clairement.
-+- AB in Guide du Neuneu Usenet - Il est con c'type, hé ! -+-





Avatar
T0t0
"Patrick Mevzek" wrote in message
news:
L'AC sait a priori où est installé son certificat non ?


Non, absolument pas.

Là où s'est installé elle pourrait demander à vérifier que la CRL est
bien utilisée.


Et comment saurait-elle quand un certificat est utilisé ?
Une PKI ne fonctionne pas comme cela.

Ah, évidemment, ca demanderait un peu de travail et un peu d'argent, je
concois bien que ca embêterait les AC de ne plus faire quasimment 100% de
marge mais moins....


Cela n'a pas lieu d'exister puisque les mécanismes intégrés aux PKI
savent déjà gérer cela.

Les AC ont de l'argent, non, au prix où elles vendent les certificats....


C'est un beau raccourci. Ils ont des recettes et des dépenses. S'il y a
plus de recettes que de dépenses, il ont effectivement de l'argent, mais
je ne crois pas que ce soit le cas.


--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Avatar
Eric Razny
Patrick Mevzek wrote:

Pourquoi une AC, qui fournit des certificats et maintient des CRLs, ne
verifierait-elle pas que les CRLs en question sont bien utilisés, à


Bien. Je suis une AC, je publie ma CRL régulièrement. Comment est-ce que
je peux vérifier que telle ou telle application est bien configurée et
télécharge correctement la CRL? C'est n'importe quoi.



L'AC sait a priori où est installé son certificat non ?


Non.
Que le certificat soit installé sur un navigateur quelconque, utilisé
par un programme et ce quel que soit l'OS, on s'en tappe le coquillard.

Le but d'une AC est de fournir un service : je m'engage à ce que mes
certifs aient telles propriétés, à vérifier tel et tel point avant de
les générer (ex identité du sujet), à gérer mes crl de telle ou telle
manière etc.

Dans un prog java je gère directement mon magasin de certifs et je doute
que l'AC sache que j'utilise son root certificate pour des vérification.

Je suis aussi AC pour un projet. Dans "mes" programmes la vérif des
certificats est gérée correctement. Maintenant si le gus veut utiliser
son certif perso et mes certifs root ou intermédiaire pour autre chose
c'est son affaire. Et s'il merde dans ses vérifs je m'en tappe (et il
n'a pas intérêt à venir me voir pour me reprocher que *son* prog merde)

L'AC sait que son certif est au moins installé sur tel et tel produit
suite à un accord mais ne connait pas la liste complète des produits qui
l'utilisent.

Là où s'est installé elle pourrait demander à vérifier que la CRL est
bien utilisée.


Encore non. Elle s'en tape. Je suis garagiste et tu viens m'acheter des
plaquettes de frein pour les poser toi même. Mon job est de te fournir
des plaquettes de qualité, éventuellement de te donner un conseil mais
certainement pas de vérifier que tu les utilise correctement (très bien
en post moderne comme serre-livre :) ).

Ah, évidemment, ca demanderait un peu de travail et un peu d'argent, je
concois bien que ca embêterait les AC de ne plus faire quasimment 100% de
marge mais moins....


La ça implique une méconnaissance complète du sujet. Certes la marge des
AC semble être très conséquente mais les AC qui font leur job ont des
coûts réels (à commencer par les assurances pour couvrir leurs conneries
:)). Yvan a déjà indiqué que techniquement un certif crée par sa grand
mère (waou!) est de même nature que celui de verisign (juste au hazard,
je prends le plus décrié). Par contre je doute que M. Jachètout fasse
confiance au certif de cuisine utilisé par le site Toutpascher(et que
Mme Yvan-GrandMother indemnise Toutpascher si elle se gourre dans sa
gestion des certifs).

Même pour un petit projet c'est chiant d'avoir une machine dédié non
connectée et protégée physiquemet pour générer les certifs et d'aller
chercher le root certificate au coffre d'une banque pour générer les
certifs intermédiaire. Alors pour une société donc AC est le métier
j'imagine facilement les problèmes (techniques et humains)

Les AC ont de l'argent, non, au prix où elles vendent les certificats....


Et alors? Tu n'as qu'a t'en monter une :)
Elle vendent des certifs, elles s'engagent sur la génération des certifs
et la gestion des crl. Elles n'ont pas à s'engager sur l'utilisation
qu'en font ses clients. cf l'exemple des plaquettes plus haut.

Je veux bien (facilement) comprendre que tu ais une dent contre
certaines AC mais de la à raconter n'importe quoi il y a un monde.

Accessoirement tu n'es pas obligé de choisir l'AC le plus cher, mais de
chercher celle qui t'assure que ta cible à peut de chance de se prendre
un message d'erreur pour absence de root certificate pour la vérif.

Vous mélangez tout là. On parle d'un utilisateur final. Pas d'un
intermédiaire.


Ok. Si j'achète un téléphone à Noksem qui fonctionne avec un chipset
Thomgem et que mon téléphone merde parce que Noksem est pas foutu de
gérer correctement le bluetooth[1] je me retourne contre Noksem. Je ne
vais pas reprocher à Thomgem de vendre leurs produit à un client qui ne
sait pas s'en servir et les intégrer correctement!


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...


Ah ben faut pas utiliser Windows. Ca fait longtemps qu'on le dit hein...



Et qu'est-ce qui t'oblige à utiliser OE sous windows? tu peux utiliser
un produit qui gère lui même et correctement *son* magazin de certifs.

Eric

[1] Toute ressemblance avec un produit nommé 6600 n'est qu'une pure
coincidence ;)

--
L'invulnérable :
Je ne pense pas etre piratable, infectable par un trojen oui!
Vu sur fcs un jour de mars 2004.



Avatar
Patrick Mevzek
Les AC ont de l'argent, non, au prix où elles vendent les
certificats....


C'est un beau raccourci. Ils ont des recettes et des dépenses. S'il y a
plus de recettes que de dépenses, il ont effectivement de l'argent, mais
je ne crois pas que ce soit le cas.


Les AC sont déficitaires selon vous (je parle des grosses style Verisign)
et vendent des certificats à perte ?
Intéressant...

--
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>


Avatar
Patrick Mevzek
Beaucoup de bruit pour rien.


Non, pour une réponse. Mais vous ètes libre de poser la question et
d'ignorer la réponse. Ne vous étonnez pas que le reste du monde fasse de
même.


Si vous reprenez le thread depuis le début, l'histoire c'est que quand on
demande où c'est dans windows on a comme réponse: et d'abord où c'est
sous unix.

Le fait que Debian et RedHat utilisent (ou souhaitent utiliser) la liste
des certificats de Mozilla pour la metter à disposition des autres
applications qui en auraient besoin est une réponse à la question (je
cite):
"> Arf, en retournant la question, où dans un système unix serait la
liste
des AC reconnues ?"



Ce qui n'est pas ma question.

Maintenant, si vous connaissez si bien Debian au point de vous contenter
d'un "dpkg -L ca-certificates" comme réponse, vous auriez pu vous forcer
un peu et chercher par vous-même.


Relisez le thread, manifestement vous mélangez les contributions.
(ce qui explique que ca ressemble à un dialogue de sourds)
Ma question était : où c'est sous *windows* !
(ce à quoi il a été répondu dans un autre post, oui, je suis d'accord).

--
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>


Avatar
Patrick Mevzek
c'est son affaire. Et s'il merde dans ses vérifs je m'en tappe (et il
n'a pas intérêt à venir me voir pour me reprocher que *son* prog merde)


Je suis partisan d'approches plus pragmatiques, désolé.

L'AC sait que son certif est au moins installé sur tel et tel produit
suite à un accord mais ne connait pas la liste complète des produits qui
l'utilisent.


Cf mon autre réponse. Déjà si elle s'attelle à ce qu'elle connait et aux
trucs mainstream, ca devrait couvrir une bonne partie.
Oui, pas 100% en permanence, nous sommes d'accord.

Là où s'est installé elle pourrait demander à vérifier que la CRL est
bien utilisée.


Encore non. Elle s'en tape.


Bien sûr, dans votre vision des choses, où tout est de la faute de
l'utilisateur, et dans la vision de maximiser le profit pour l'AC.
Pas dans la mienne.

Ah, évidemment, ca demanderait un peu de travail et un peu d'argent, je
concois bien que ca embêterait les AC de ne plus faire quasimment 100%
de marge mais moins....


La ça implique une méconnaissance complète du sujet. Certes la marge des
AC semble être très conséquente mais les AC qui font leur job ont des
coûts réels (à commencer par les assurances pour couvrir leurs conneries
:)).


Mon 100% n'est pas à prendre au pied de la lettre, et vous ne dites pas
autre chose en disant: ``marge très conséquente''.
Donc, si on dit la même chose, vous semblez méconnaitre autant que moi :-)

certifs intermédiaire. Alors pour une société donc AC est le métier
j'imagine facilement les problèmes (techniques et humains)


Je n'ai pas dit qu'il n'y avait pas de problèmes.
Eu égard aux vérifications faites et au prix payé, ca laisse de la
marge, cependant...

Exemple parmi tant d'autres: un certificat sur *.example.com est facturé
genre 5 à 10 fois plus cher que sur www.example.com
Quelle est la raison ?

Les AC ont de l'argent, non, au prix où elles vendent les
certificats....


Et alors?


Et alors quand je propose X et qu'on me dit que X ca coute de l'argent,
je dis juste que l'argent il est probablement là, donc que cet aspect
n'est pas un problème pour faire X.

Tu n'as qu'a t'en monter une :)


L'argument qui tue...

Elle vendent des certifs,
elles s'engagent sur la génération des certifs et la gestion des crl.


Elles s'engagent ?
Vous voulez dire avec des garanties, des assurances, des moyens de
recours des clients finaux, des indemnisations concrètes au client
*final* ?

Il y a quelques pages intéressantes à ce sujet dans ``Web security,
privacy & commerce'' même si pas récentes. Si quelqu'un a des données
plus récentes, je suis preneur.

Et qu'est-ce qui t'oblige à utiliser OE sous windows? tu peux utiliser
un produit qui gère lui même et correctement *son* magazin de certifs.


Encore une fois prêcher un converti, essayer de le faire passer pour un
idiot, et répondre à côté, ne fais pas avancer le schmilblick, mais c'est
pas grave.
C'était qu'une idée lancée au cours d'une discussion, oubliez donc.

--
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>