Tarif Certificat (ex Verisign)

Le Mon, 24 May 2004 17:34:18 +0000, Franck DARRAS a écrit :

J'aurai voulu avoir une idée sur les tarifs pour certifier un certificat
SSL soit en mode 40bit, soit 1024.
Je ne connais que Verisign, as t-on besoin d'aller voir ailleurs.

Il faut toujours comparer. Thawte, par exemple, est nettement moins cher
que Verisign. Il y a aussi des hébergeurs qui proposent des tarifs plus
compétitifs parce qu'ils achètent leurs certificats en gros (comme au
marché). Bref, il faut comparer.

--

?!?! Rappelle moi ta définition de blonde ? :-)
Blonde : Sujet de blagues nulles de mecs au QI < 15

Stéphane (QI de 42)
-+- S in GFA : "J'ai une très bonne estime de moi-même" -+-

"Cedric Blancher" <blancher@cartel-securite.fr> wrote in message
news:pan.2004.05.25.09.43.37.583354@cartel-securite.fr

Il faut toujours comparer. Thawte, par exemple, est nettement moins cher
que Verisign. Il y a aussi des hébergeurs qui proposent des tarifs plus
compétitifs parce qu'ils achètent leurs certificats en gros (comme au
marché). Bref, il faut comparer.

Je confirme que Thawte offre un bon service. Alors que chez Verisign,
j'ai eu des problèmes avec des cartes accélératrices Rainbow car
l'autorité intermédiaire avait une clef de signature de 1000bits...

Quant à la problématique de chiffrement à 40bits ou 128bits, il y
a aussi du foutage de gueule. De ce que j'a pu en comprendre, des
certificats standards vendus comme garantissant du 40bits font très
bien du 128bits (la taille du chiffrement utilisée provient de la
négociation client-serveur et non de la taille des clefs asymétriques
utilisées) Cependant, une faible minorité de navigateurs négocie un
chiffrement à 40bits (IE < 5.5 et Netscape < 4.7) Les certificats dits
à 128bits permettent en fait de "forcer" le chiffrement à 128 bits.
Il y a de ca un an quand je gérais des certifs, la différence de prix
était exorbitante (*3) pour un résultat quasi identique.
Donc cet aspect est aussi à regarder si les échanges peuvent
supporter un chiffrement à 40bits dans une minorité de cas.




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

On 25 May 2004, T0t0 wrote:

"Cedric Blancher" <blancher@cartel-securite.fr> wrote in message
news:pan.2004.05.25.09.43.37.583354@cartel-securite.fr

Il faut toujours comparer. Thawte, par exemple, est nettement moins cher
que Verisign. Il y a aussi des hébergeurs qui proposent des tarifs plus
compétitifs parce qu'ils achètent leurs certificats en gros (comme au
marché). Bref, il faut comparer.

Je confirme que Thawte offre un bon service. Alors que chez Verisign,
j'ai eu des problèmes avec des cartes accélératrices Rainbow car
l'autorité intermédiaire avait une clef de signature de 1000bits...

C'est pas un problème chez VeriSign, c'est un problème de ta carte
Rainbow...

Quant à la problématique de chiffrement à 40bits ou 128bits, il y
a aussi du foutage de gueule. De ce que j'a pu en comprendre, des
certificats standards vendus comme garantissant du 40bits font très
bien du 128bits (la taille du chiffrement utilisée provient de la

Oui, si le client le supporte.

négociation client-serveur et non de la taille des clefs asymétriques
utilisées) Cependant, une faible minorité de navigateurs négocie un
chiffrement à 40bits (IE < 5.5 et Netscape < 4.7) Les certificats dits

Quand tu parles de "faible minorité", tu te bases sur quels chiffres? Au
passage, il y a eu des versions d'IE 5.5 et Netscape 4.7 "export", donc
concernés par ces certificats SGC.

à 128bits permettent en fait de "forcer" le chiffrement à 128 bits.

Pas exactement de les "forcer", plutôt de les "autoriser" à faire du 128
bits.

Il y a de ca un an quand je gérais des certifs, la différence de prix
était exorbitante (*3) pour un résultat quasi identique.
Donc cet aspect est aussi à regarder si les échanges peuvent
supporter un chiffrement à 40bits dans une minorité de cas.

Une banque ne peut généralement pas se permettre ce genre de choses, de
même que d'autres sociétés (qui doivent fournir le 'best effort', sans
garantir le résultat).

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
bien que ma carte son supporte le 800*600, linux est afficher en
480*640, comment changer ce parametre ?
-+-T in GNU : Linux habens découvre le multimedia -+-

"Erwann ABALEA" <erwann@abalea.com> wrote in message
news:Pine.LNX.4.33.0405260942550.12539-100000@patchwork.seclogd.org

C'est pas un problème chez VeriSign, c'est un problème de ta carte
Rainbow...

Mouaif, des clefs de 1000 bits, c'est moyen standard quand même...
Je n'ai vu ce type de certificat que chez eux (j'ai pas non plus fait
de recherche poussée...)
N'empêche que Verisign n'a pas été capable de me fournir un
certificat équivalent signé avec une taille de clef standard. Il a
fallu acheter un certif trois fois plus cher... Ce qui clairement
pour moi est une certaine forme d'incompétence de leur part.

Quand tu parles de "faible minorité", tu te bases sur quels chiffres?

Des logs de notre site (puisque c'est dans ce cadre que l'étude a été
faite)
Mais sinon, il y a cela:
<http://www.mindmined.com/tools/webslave/popups/popular_browsers.html>
Ce n'est pas exhaustif, mais bon, ce serait de la mauvaise foi que de
croire le contraire, à mon avis.

Une banque ne peut généralement pas se permettre ce genre de choses, de
même que d'autres sociétés (qui doivent fournir le 'best effort', sans
garantir le résultat).

Chacun son truc, effectivement. Ce n'est qu'un conseil donné à Franck
suite à sa question.



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

On 26 May 2004, T0t0 wrote:

"Erwann ABALEA" <erwann@abalea.com> wrote in message
news:Pine.LNX.4.33.0405260942550.12539-100000@patchwork.seclogd.org

C'est pas un problème chez VeriSign, c'est un problème de ta carte
Rainbow...

Mouaif, des clefs de 1000 bits, c'est moyen standard quand même...

C'est pas moins standard que des clés RSA de 1001 bits. Ce qui n'est pas
standard, c'est de considérer qu'un module RSA fait 512, 768, 1024 ou 2048
bits. Ce sont des 'valeurs magiques' imposées par un constructeur qui ne
correspondent à rien. Un autre truc non standard, c'est que la CAPI de
Microsoft ne sait pas mettre en oeuvre une clé RSA avec un exposant
publique plus grand que 2^32. C'est très con, c'est une limitation
arbitraire et une complication volontaire de leur API.

Je n'ai vu ce type de certificat que chez eux (j'ai pas non plus fait
de recherche poussée...)

Tu pourrais trouver des certificats de 1023 bits par exemple.

N'empêche que Verisign n'a pas été capable de me fournir un
certificat équivalent signé avec une taille de clef standard. Il a

Revois ta définition de 'standard', et ton jugement.

fallu acheter un certif trois fois plus cher... Ce qui clairement
pour moi est une certaine forme d'incompétence de leur part.

Pour moi (qui bosse dans la PKI), ce que tu prends pour de l'incompétence
de leur part n'est en fait qu'une méconnaissance de la PKI de ta part.

Quand VeriSign te délivre un certificat, celui-ci est signé par une
Autorité de Confiance (AC). VeriSign a négocié avec Netscape et Microsoft
pour intégrer cette AC dans leurs navigateurs, afin que les certificats
signés par cette AC soient reconnus nativement par ces navigateurs. C'est
exactement pour cette raison que tu vas voir Thawte ou VeriSign ou
n'importe quel autre fournisseur de certificats reconnus par les
navigateurs plutôt que de fabriquer tes propres certificats sur ton coin
de table (ce qui est ultra simple).
Donc quand tu souhaites que VeriSign te délivre un certificat signé par
une nouvelle AC dont le module RSA a une taille 'acceptable' par ta carte
Rainbow, tu souhaites en fait que VeriSign fabrique une nouvelle AC selon
tes critères, renégocie avec Microsoft, Netscape et autres l'intégration
de cette nouvelle AC dans leurs navigateurs (contre pognon, évidemment),
que Microsoft, Netscape, et les autres publient une nouvelle version de
leur navigateur avec cette nouvelle AC, et que tes clients se mettent à
jour. Tu veux ça pour quand, et à quel prix?

Sérieusement, l'AC a été créée comme ça, le choix de 1000 bits peut
paraître débile, il est arbitraire mais parfaitement standard et ne
devrait poser de problème qu'à des développeurs crétins (du genre de ceux
qui inventent des booléens à 3 états ou qui te proposent de cliquer sur
'Démarrer' pour éteindre ton PC), et si tu utilises de tels produits,
ça n'est pas de la faute des autres... Faut quand même pas déconner. ;)

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Malheureusement c'est dur, a force de découper les points godwin que
je gagne, de lire quoi que ce soit sur mon écran.
-+- JC in GNU : couper (au burin) - coller (à la glue) -+-

"Erwann ABALEA" <erwann@abalea.com> wrote in message
news:Pine.LNX.4.33.0405270948530.21592-100000@patchwork.seclogd.org

C'est pas moins standard que des clés RSA de 1001 bits. Ce qui n'est pas
standard, c'est de considérer qu'un module RSA fait 512, 768, 1024 ou 2048
bits. Ce sont des 'valeurs magiques' imposées par un constructeur qui ne
correspondent à rien.

Arf, je ne pense pas en fait. Pour moi, il s'agit avant tout d'un
compromis sécurité offerte<->temps de calcul
Après le fait de tomber sur un chiffre rond sur lequel tout le
monde est d'accord, je ne sais pas exactement pourquoi...
Mais à priori, je n'ai jamais vu personne remettre ces principes en
cause. Donc effectivement, de ce que j'en sais, ce n'est en rien une
norme, mais un best-practice que l'on retrouve dans quasiment tout
logiciel de crypto.

Tu pourrais trouver des certificats de 1023 bits par exemple.

Je pourrais, mais j'en trouve pas...
Que des clefs de 1024 bits, c'est ouf hien !!! que tout le monde ne
profite pas ainsi de la possibilité d'utilisé un nombre aléatoire
de bits pour créer une clef... et choisisse ce chiffre magique !

Pour moi (qui bosse dans la PKI) ce que tu prends pour de l'incompétence
de leur part n'est en fait qu'une méconnaissance de la PKI de ta part.

C'est possible, je ne bosse pas dans la pki ;-)

Quand VeriSign te délivre un certificat, celui-ci est signé par une
Autorité de Confiance (AC).

A priori, il est signé par une autorité intermédiaire qui elle-même
peut ou non être signée directement par l'autorité de confiance
contenue dans mon navigateur.
Un best-practice d'une PKI est de ne pas signer directement des
certificats utilisateurs ou serveurs par l'autorité racine, mais par
une autorité fille. Ainsi, si par malheur l'autorité intermédiaire est
corrompue, ta PKI n'est pas bonne à jeter à la poubelle.
Ce n'est pas une norme, mais juste un best-practice. Thawte par
exemple ne le fait pas toujours...

Dans mon cas, c'est cette autorité intermédiaire qui avait une clef
de 1000 bits et qui foutait le bordel.

Donc quand tu souhaites que VeriSign te délivre un certificat signé par
une nouvelle AC dont le module RSA a une taille 'acceptable' par ta carte
Rainbow, tu souhaites en fait que VeriSign fabrique une nouvelle AC selon
tes critères, renégocie avec Microsoft, Netscape et autres l'intégration
de cette nouvelle AC dans leurs navigateurs (contre pognon, évidemment),
que Microsoft, Netscape, et les autres publient une nouvelle version de
leur navigateur avec cette nouvelle AC, et que tes clients se mettent à
jour. Tu veux ça pour quand, et à quel prix?

Du calme, tu extrapoles un peu rapidement un problème que tu ne
connais pas..
Verisign possède une foultitude d'autorités intermédiaires, filles de(s)
l'autorité(s) contenue(s) dans les navigateurs. Ce que je souhaitais
était simplement d'obtenir un certificat dont la chaîne de
certification ne comportait pas de clef à 1000bits. C'est tout à fait
possible puisque c'était le cas du certificat de test que nous avions
obtenu de leur part pour tester les cartes Rainbow.
Donc en gros, je leur demandais simplement d'émettre un certif issu
d'une autre autorité de certification qui me permette d'utiliser mes
cartes dans le même cadre que celui de mes tests.

Sérieusement, l'AC a été créée comme ça, le choix de 1000 bits peut
paraître débile, il est arbitraire mais parfaitement standard et ne
devrait poser de problème qu'à des développeurs crétins (du genre de ceux
qui inventent des booléens à 3 états ou qui te proposent de cliquer sur
'Démarrer' pour éteindre ton PC), et si tu utilises de tels produits,
ça n'est pas de la faute des autres... Faut quand même pas déconner. ;)

C'est une vision des choses.
A mon avis, s'il continuent à faire ce genre de choses, ils vont perdre
des clients puisque ce petit incident nous a amené à faire une étude
de marché qui a montré qu'en passant chez thawte, on allait faire
une économie de 23 000€ :-))
Il n'ont peut être pas pris en compte que les développeurs crétins
savaient calculer les euros ;-)



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

Bonjour,

On 28 May 2004, T0t0 wrote:

"Erwann ABALEA" <erwann@abalea.com> wrote in message
news:Pine.LNX.4.33.0405270948530.21592-100000@patchwork.seclogd.org

C'est pas moins standard que des clés RSA de 1001 bits. Ce qui n'est pas
standard, c'est de considérer qu'un module RSA fait 512, 768, 1024 ou 2048
bits. Ce sont des 'valeurs magiques' imposées par un constructeur qui ne
correspondent à rien.

Arf, je ne pense pas en fait. Pour moi, il s'agit avant tout d'un
compromis sécurité offerte<->temps de calcul

Le temps de calcul d'une clé 1024 bits est légèrement plus grand que celui
d'une clé de 1000 bits, et on estime qu'il faut environ 2.2 fois plus de
temps pour casser du 1024 bits que pour casser du 1000 bits, à la louche;
ce qui ne fait pas du 1000 bits un mauvais choix, puisqu'une telle clé est
encore de nos jours hors de portée. Mais il n'y a aucun compromis à faire
ici. L'AC, c'est VeriSign, ta carte crypto n'a pas à vérifier que le
certificat que tu lui présentes est bien signé par l'AC tartempion (c'est
au client de faire ce travail, pas au serveur).

Après le fait de tomber sur un chiffre rond sur lequel tout le
monde est d'accord, je ne sais pas exactement pourquoi...

Moi non plus, mais ce sont certainement de mauvaises raisons. Beaucoup de
programmeurs/cryptographes amateurs considèrent que puisqu'on compte une
capacité par multiple de 1024, alors c'est que c'est comme ça qu'on doit
pratiquer dans tous les domaines où l'informatique met son nez. Manque de
bol, on manipule ici des nombres exprimés en base 2, et il n'y a pas plus
de raison de considérer qu'un nombre de 1024 bits est plus 'légitime'
qu'un nombre de 1000 bits qu'il n'y a de raison de considérer que le
nombre 2004 (exprimé en décimal) qui s'écrit sur 4 chiffres est plus
'légitime' que le nombre 195 qui ne s'écrit que sur 3 chiffres. En
d'autres termes, la longueur d'un nombre ne rend pas un nombre plus ou
moins standard. Sa valeur, peut-être, mais pas sa longueur. Est-ce qu'un
fichier de 10245 octets est 'plus standard' qu'un fichier de 10240 octets?

De la même manière, pourquoi ne pas accepter un module de 1000 bits (qui
après tout est quand même un multiple de 8, et un tel module remplit donc
complètement 125 octets sans laisser de trou), alors que le même produit
accepte un nombre de 17 bits (oui, l'exposant public Fermat 4, qui est
65537 est un nombre de 17 bits de long)?

Il faudrait demander à Rainbow pourquoi leur carte n'accepte pas une telle
clé, mais je ne serais pas surpris que la véritable raison soit une pure
limitation arbitraire...

Mais à priori, je n'ai jamais vu personne remettre ces principes en
cause. Donc effectivement, de ce que j'en sais, ce n'est en rien une
norme, mais un best-practice que l'on retrouve dans quasiment tout
logiciel de crypto.

Là, faudra travailler dur pour me démontrer ça. J'ai un peu l'habitude
techniquement de manipuler des logiciels de crypto, et aussi du matos, et
même le monde réel te démontre le contraire: VeriSign (et particulièrement
cette AC) est le plus gros vendeur de certificats serveurs, et ça n'a posé
de problème à personne que la clé publique ait un module de 1000 bits...

Que personne ne remette en cause qu'une clé RSA doit s'exprimer sur 1024
bits plutôt que 1023 n'est pas une bonne raison. Ca n'est pas parce que
des milliards de mouches bouffent de la m*rde que c'est bon, et ça n'est
pas parce que des millions d'utilisateurs utilisent Windows que ça en fait
un bon produit.

Tu pourrais trouver des certificats de 1023 bits par exemple.

Je pourrais, mais j'en trouve pas...
Que des clefs de 1024 bits, c'est ouf hien !!! que tout le monde ne
profite pas ainsi de la possibilité d'utilisé un nombre aléatoire
de bits pour créer une clef... et choisisse ce chiffre magique !

Au temps pour moi, je n'ai pas remis mes infos à jour. Il y a quelques
mois, on trouvait encore du 1023 bits dans les AC, et même du 512 bits (ce
qui est beaucoup plus grave). Mais je viens de vérifier sur un Windows
2000 et sous Mozilla, je n'ai que du 1024, 2048, 4096, et 1000 bits.

Pour moi (qui bosse dans la PKI) ce que tu prends pour de l'incompétence
de leur part n'est en fait qu'une méconnaissance de la PKI de ta part.

C'est possible, je ne bosse pas dans la pki ;-)

Quand VeriSign te délivre un certificat, celui-ci est signé par une
Autorité de Confiance (AC).

A priori, il est signé par une autorité intermédiaire qui elle-même
peut ou non être signée directement par l'autorité de confiance
contenue dans mon navigateur.

Non, du moins pas pour un certificat standard. Un certificat Serveur
classique (ce que VeriSign appelle à tort certificat 40 bits) est signé
directement par la racine. On ne parle que de VeriSign ici.

Un best-practice d'une PKI est de ne pas signer directement des
certificats utilisateurs ou serveurs par l'autorité racine, mais par
une autorité fille.

Le contraire peut s'argumenter. Avoir un niveau supplémentaire d'AC permet
de 'compartimenter' les utilisateurs finaux, ce que ne permet pas une AC
'à plat' (comme la "RSA/VeriSign Secure Server CA"). Mais comme tout le
monde n'a pas besoin de compartimenter les utilisateurs, un modèle de PKI
à plusieurs étages n'est pas toujours requis. Et en pratique, beaucoup de
PKI sont 'à plat', et ça ne dérange personne.

Ainsi, si par malheur l'autorité intermédiaire est
corrompue, ta PKI n'est pas bonne à jeter à la poubelle.

Ca c'est la théorie. En pratique, si une AC est corrompue, c'est
l'entreprise qui met en oeuvre cette AC qui est bonne à jeter à la
poubelle.

Dans mon cas, c'est cette autorité intermédiaire qui avait une clef
de 1000 bits et qui foutait le bordel.

Voir plus haut.

Donc quand tu souhaites que VeriSign te délivre un certificat signé par
une nouvelle AC dont le module RSA a une taille 'acceptable' par ta carte
Rainbow, tu souhaites en fait que VeriSign fabrique une nouvelle AC selon
tes critères, renégocie avec Microsoft, Netscape et autres l'intégration
de cette nouvelle AC dans leurs navigateurs (contre pognon, évidemment),
que Microsoft, Netscape, et les autres publient une nouvelle version de
leur navigateur avec cette nouvelle AC, et que tes clients se mettent à
jour. Tu veux ça pour quand, et à quel prix?

Du calme, tu extrapoles un peu rapidement un problème que tu ne
connais pas..

Je ne dirais pas pour qui je travaille, mais c'est (relativement) facile à
savoir. ;)

Verisign possède une foultitude d'autorités intermédiaires, filles de(s)
l'autorité(s) contenue(s) dans les navigateurs. Ce que je souhaitais
était simplement d'obtenir un certificat dont la chaîne de
certification ne comportait pas de clef à 1000bits. C'est tout à fait
possible puisque c'était le cas du certificat de test que nous avions
obtenu de leur part pour tester les cartes Rainbow.
Donc en gros, je leur demandais simplement d'émettre un certif issu
d'une autre autorité de certification qui me permette d'utiliser mes
cartes dans le même cadre que celui de mes tests.

Ben oui, mais c'est en passant par une autre de leurs AC. Ils font du
certificat Classe 3 pour les serveurs, mais c'est seulement pour les
certificats SGC, qui coûtent effectivement plus cher (parce qu'il leur a
fallu négocier également avec le gouvernement US, et que les navigateurs
doivent intégrer un petit bout de code exprès pour cette technologie;
également parce qu'ils sont les seuls à fournir cette possibilité).

En gros, VeriSign a 2 AC qu'ils utilisent pour emettre des certificats
serveur: la classique "RSA/VeriSign Secure Server CA", et la "VeriSign
Class 3 Public Primary Certification Authority". La "Class3" est 'flaggée'
dans les navigateurs pour autoriser le SGC, donc quand tu as un certificat
serveur faisant partie de la hiérarchie "Class3", tu es autorisé à faire
du SGC. Tu comprends donc pourquoi VeriSign ne pouvait pas te fournir de
certificat serveur sous une autre AC au même prix...

Ton certificat de test a été signé par une AC de test, qui est une clé
privée en soft dans leur centre de prod, et dont le certificat n'est pas
intégré dans les navigateurs du marché. Donc si tu voulais un certificat
qui offre les mêmes garanties de fonctionnement qu'un certificat de test,
pas la peine de dépenser ton pognon, tu le fais toi-même...

Sérieusement, l'AC a été créée comme ça, le choix de 1000 bits peut
paraître débile, il est arbitraire mais parfaitement standard et ne
devrait poser de problème qu'à des développeurs crétins (du genre de ceux
qui inventent des booléens à 3 états ou qui te proposent de cliquer sur
'Démarrer' pour éteindre ton PC), et si tu utilises de tels produits,
ça n'est pas de la faute des autres... Faut quand même pas déconner. ;)

C'est une vision des choses.
A mon avis, s'il continuent à faire ce genre de choses, ils vont perdre
des clients puisque ce petit incident nous a amené à faire une étude
de marché qui a montré qu'en passant chez thawte, on allait faire
une économie de 23 000€ :-))

D'un autre côté, c'est aussi une économie de travail chez VeriSign, et
comme l'argent arrive dans la même poche...

Et ils font comme ça depuis plusieurs années, ça a toujours fonctionné,
donc je ne vois pas pourquoi ils changeraient.

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