Certificat SSL

DAPL <pasdespam@free.fr> writes:

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 ?

Essentiellement, oui.

Apres, dans certains cas, la "valeur ajoutee" de ces societes peut se
justifier nettement plus (si on decide de leur faire gerer une PKI
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....


A +

VANHU.

Bonsoir,

On Wed, 12 Jan 2005, DAPL wrote:

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 ?

Entre autres. Il y a aussi:
- l'utilisation de ressources cryptographiques évaluées
- une plate forme de production: backups, disaster recovery off-site, ...
- des règles de sécurité physique et logique stricte (je le sais)
- des vérifications effectuées pour te délivrer un certificat (non, ça ne
consiste pas seulement à vérifier que ton compte est approvisionné)

Tout ça coûte cher.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Depuis ce matin, j'ai une IP en 213.@@@.@@@ et des plumes.
C'est devenu apparement une IP statique.
Mon contrat me donne droit à une IP dynamique..
-+- TW in <http://neuneu.mine.nu> : Neuneu se fixe -+-

Erwann ABALEA wrote:

Bonsoir,

On Wed, 12 Jan 2005, DAPL wrote:

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 ?

Entre autres. Il y a aussi:
- l'utilisation de ressources cryptographiques évaluées
- une plate forme de production: backups, disaster recovery off-site, ...
- des règles de sécurité physique et logique stricte (je le sais)
Je doute que nous en soyons réellement à ce niveau de sécurité pour un

simple certificat utilisateur à quelques dizaines d'euros (justement une
telle infrastructure coûte cher et un certificat utilisateur n'est pas
suffisamment rentable). Pour un certificat serveur à 200 ou 300 euros je
veux cependant bien le croire.
Pff, le marketing est encore passé par là.

- des vérifications effectuées pour te délivrer un certificat (non, ça ne
consiste pas seulement à vérifier que ton compte est approvisionné)
Ben voyons, on s'en est bien rendu compte, en 2001, lorsque Verisign a

attribué un certificat au nom de Microsoft à un simple développeur (ne
travaillant pas chez Microosft). ;-)
Ce certificat lui permettait de signer ses programmes au nom de Microsoft,
nom apparaissant lors de l'installation du logiciel en question (<<
faites-vous confiance aux programmes provenant de Microsoft ? >>).

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.

Tout ça coûte cher.

db
--
email : usenet blas net

Bonjour,

On Thu, 13 Jan 2005, Dominique Blas wrote:

Erwann ABALEA wrote:

On Wed, 12 Jan 2005, DAPL wrote:

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 ?

Entre autres. Il y a aussi:
- l'utilisation de ressources cryptographiques évaluées
- une plate forme de production: backups, disaster recovery off-site, ...
- des règles de sécurité physique et logique stricte (je le sais)
Je doute que nous en soyons réellement à ce niveau de sécurité pour un

simple certificat utilisateur à quelques dizaines d'euros (justement une
telle infrastructure coûte cher et un certificat utilisateur n'est pas
suffisamment rentable). Pour un certificat serveur à 200 ou 300 euros je
veux cependant bien le croire.

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.

Pff, le marketing est encore passé par là.

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é. ;)

- des vérifications effectuées pour te délivrer un certificat (non, ça ne
consiste pas seulement à vérifier que ton compte est approvisionné)
Ben voyons, on s'en est bien rendu compte, en 2001, lorsque Verisign a

attribué un certificat au nom de Microsoft à un simple développeur (ne
travaillant pas chez Microosft). ;-)

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? 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? Appliqué à un autre domaine,
on dirait que c'est l'exception qui confirme la règle.

Ce certificat lui permettait de signer ses programmes au nom de Microsoft,
nom apparaissant lors de l'installation du logiciel en question (<<
faites-vous confiance aux programmes provenant de Microsoft ? >>).

Oui. Mais pendant un an seulement.

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. Si vous étiez un commerçant,
accepteriez-vous d'utiliser un terminal de paiement qui ne télécharge pas
la liste noire des cartes bancaires? Pourquoi dès qu'il s'agit
d'informatique la sécurité devient tellement chiante qu'elle est 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.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Il n'est pas question de modération !!!
Les gens ont à se prononcer sur les caractéristiques d'une
robot-modération
-+- BC in Guide du Neuneu Usenet - C'est robot pour être vrai -+-

On 13 Jan 2005 00:46:14 GMT, Dominique Blas <nospam@spam.int>:

faites-vous confiance aux programmes provenant de Microsoft ?
Ce certificat a été révoqué dans les semaines qui ont suivi mais qui vérifie
la validité d'un certificat de nos jours ?

Pour le coup, si je dois installer un programme ou un driver parce que
j'en ai besoin, je ne me même soucie pas de savoir s'il est signé ou
pas.


--
;-)

Pff, le marketing est encore passé par là.

Non.

Perso, je pense que si.

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 ?

Ben voyons, on s'en est bien rendu compte, en 2001, lorsque Verisign a
attribué un certificat au nom de Microsoft à un simple développeur (ne
travaillant pas chez Microosft). ;-)

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.

Quand c'est une grosse bourde, ca se voit bien sûr.
Mais ce n'est pas parce qu'on ne voit rien, qu'il n'y a pas de bourdes...

Ce certificat lui permettait de signer ses programmes au nom de
Microsoft, nom apparaissant lors de l'installation du logiciel en
question (<< faites-vous confiance aux programmes provenant de
Microsoft ? >>).

Oui. Mais pendant un an seulement.

Ca en laisse du temps pour faire des installations....

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

Pour faire baisser les prix, et prendre du monopole à Verisign/Thawte,
les différents outsiders (et Thawte aussi d'ailleurs) n'ont fait que
simplifier les procédures...

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 !

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

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
2) les CRLs employées ?

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 ?

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

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

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

Pff, le marketing est encore passé par là.

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

Un professeur émérite nous a tous fait croire en 1986 que les poussières
radioactives de Tchernobyl s'étaient arrêtées à nos frontières jusqu'à ce
qu'un autre professeur émérite (non corrompue par la politique celle-là)
lui fasse ravaler ses dires.

[...]

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.
Je ne prétends pas délivrer de certificats à la planète entière ni
réglementer l'usage des TLD à ma façon.

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.
Je vois mal comment une boîte étrangère pourrait enquêter sur la justesse
d'une demande française. Via sa filliale ?
Raison pour laquelle je privilégie les tiers de confiance français et
préférence sans techno étrangère impliquée !

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é.
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 ?
Ceci d'autant que peu de personnes, peu d'applications vont vérifier la
réalité du certificat racine de l'autorité reconnue.

[...]

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

Oui et non. Elle est à mon avis avant tout liée aux usages. C'est peut-être
assez sain quelque part.

Si vous étiez un commerçant,
accepteriez-vous d'utiliser un terminal de paiement qui ne télécharge pas
la liste noire des cartes bancaires?
Non mais je l'aurais extrêmement mauvaise de constater que j'ai payé ce

terminal, que les banques me prélèvent jusqu'à 4% du montant de la vente et
que les montants en dessous de 10 euros ne me sont pas garantis et que par
dessus le marché la CB française est trouée comme une passoire. Mais c'est
un débat qui n'a pas à avoir lieu ce ng.
En tant que consommateur ça me fait suffisament c*** de constater que le
coupon commerçant comporte mon numéro de CB en entier.

Pourquoi dès qu'il s'agit
d'informatique la sécurité devient tellement chiante qu'elle est 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 forcément c'est un pb d'usage également,

db

--
email : usenet blas net

"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 ? si ce n'est les
application de cet OS qui les utilisent ?
A priori, le magasin des certificats locaux de windows est là:
C:WINDOWSsystem32MicrosoftCryptoRSAMachineKeys
Et ceux des CA dans la base des registres.

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

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 ?

Pour windows, à partir du moment où le système accède à ces certificats,
tu pourras aussi y accéder. Il n'y a aucune impossibilité, c'est une
question d'interface.




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

On Fri, 14 Jan 2005, T0t0 wrote:

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

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 ?

De plus en plus de distributions Linux utilisent la liste des AC du projet
Mozilla, et mettent cette liste à disposition des logiciels qui utilisent
de près ou de loin de la PKI. La remarque est donc pertinente.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Tu as une vision obsolète du Net. Les groupes sont hébergés chez les
FAI maintenant. Il FAUT que leur gestion change.
-+- Rocou in GNU : l'avenir appartient à ceux qui neuneutent tôt -+-