Bonjour,
comme certains l'auront probablement remarqué, les serveurs OCSP de StartCom rencontrent des difficultés ce week end, bloquant ainsi l'accès à de nombreux services.
Pour rappel l'OCSP est un protocole permettant aux clients TLS de vérifier la révocation d'un certificat ; tandis que StartCom est l'éditeur du service StartSSL, un des rares fournisseurs de certificats gratuits et reconnus par la majorité des navigateurs.
Malheureusement ce n'est pas la première fois que leurs serveurs OCSP sont en rade, et pour ma part ça remet fortement en question l'intérêt de leur solution. Du coup j'ai commandé en urgence certains certificat chez d'autres CA.
À noter que parmi les navigateurs web courants, seul Firefox semble effectuer ces vérifications OCSP, et serait donc le seul impacté. Vous vous en doutez, il en est de même niveau email pour Thunderbird.
Espérons que le déploiement de l'OCSP stapling (grosso modo, un cache directement sur le serveur utilisant le certificat SSL) limitera ces problèmes de dépendance à l'avenir… À moins que la véritable solution soit d'abandonner toute dépendance envers ces “autorités de confiance”, via DANE qui déplace cette gestion directement au niveau des entrées DNS de chacun ?
# Ca n'a pas l'air très fiable
Posté par Astaoth . Évalué à 1.
Déjà que je n'arrivais pas à me connecter avec un compte nouvellement créé chez eux, je vais me contenter de mon certificat auto-signé encore quelques temps.
Emacs le fait depuis 30 ans.
# Certificats de classe 1 seulement
Posté par Flink . Évalué à 1.
À noter qu’il semble que ça ne touche que les certificats de classe 1 (comprendre ceux qui sont gratos).
Étrangement je n’ai pas remarqué de souci d’OCSP sur les certificats de classe 2 (pourtant le serveur OCSP semble être le même, tout du moins à la même adresse).
# Bientôt une alternative pour les certificats SSL gratuits ?
Posté par SaintGermain . Évalué à 6.
Pour ma part je remercie StartCom (c'est vraiment pratique pour les sites perso) mais je suis surtout avec intérêt : Let’s Encrypt
Il y a apparemment un aperçu ici : lets-encrypt-preview
Parce que je ne sais pas pour vous mais pour moi le renouvellement et la révocation des certificats, cela ne me passionne pas beaucoup.
Sinon un site que j'utilise pour comparer le coût des certificats : https://www.gogetssl.com
Par exemple on a en ce moment des certificats "wildcard" pour 71$ sans engagement de durée (si vous avez trouvé moins cher je suis preneur !).
[^] # Re: Bientôt une alternative pour les certificats SSL gratuits ?
Posté par Tonton Benoit . Évalué à 3.
70$ chez ssl2buy.com, mais il semble y avoir une promo permanente à 42$, au moins un an que cette "offre valable un mois" fonctionne.
Faut toujours guetter les bonnes affaires, début 2014 j'ai raté de quelques jours une offre de lancement à 13$/an chez un revendeur Nord Européen.
[^] # Re: Bientôt une alternative pour les certificats SSL gratuits ?
Posté par SaintGermain . Évalué à 1.
Bravo tu as trouvé mieux (et pourtant j'avais cherché !).
J'avoue que je ne comprends pas pourquoi il faut payer (beaucoup) plus pour un SSL wildcard (surtout dans le cas d'une vérification par email).
Vivement que Let's Encrypt soit là !
# Mais non ! \o/
Posté par eingousef . Évalué à 4.
On parle bien de l'autorité qui file des certificats gratuits et qui ne demande à ses clients de passer à la caisse que pour les révoquer une fois qu'ils sont compromis ? Ne t'inquiète pas, les noobs qui prennent des certifs chez cette boite parce que c'est gratuit ne font jamais révoquer leurs certificats de toute façon ! L'inaccessibilité de leurs serveurs OCSP ne doit pas rendre la sécurité beaucoup plus mauvaise qu'elle ne l'est déjà. Aucun risque donc ! \o/
*splash!*
[^] # Re: Mais non ! \o/
Posté par Kioob (site web personnel) . Évalué à 4. Dernière modification le 05 avril 2015 à 21:13.
J'aurais dû le préciser en fait, mais ça n'a pas pour effet de désactiver la sécurité en question : cela invalide temporairement tous les certificats (de classe 1, cf message de Flink ci dessus). Firefox affiche en effet une belle erreur, sans possibilité de l'ignorer. On peut toutefois désactiver la sécurité en question dans les préférences de Firefox, mais qui va le faire ?
Le message d'erreur en question :
alf.life
[^] # Re: Mais non ! \o/
Posté par eingousef . Évalué à 2.
Je ne sais pas quelle version de firefox tu utilises, mais chez moi (Iceweasel 31.5.3), cette option est décochée par défaut (et je l'ai toujours vu décochée par défaut sur les autres logiciels mozilla aussi).
*splash!*
[^] # Re: Mais non ! \o/
Posté par Kioob (site web personnel) . Évalué à 2.
Ah étonnant, il était actif par défaut sur tous les postes Windows au boulot, ainsi que dans Iceweasel sur les Debian. Et on n'a franchement jamais cherché à toucher à ça.
alf.life
[^] # Re: Mais non ! \o/
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2.
Dans about:config j'ai les valeurs par défaut suivantes (Iceweasel 31.5.3):
Peut-être que le require a été changé par une extension/option ?
[^] # Re: Mais non ! \o/
Posté par Kioob (site web personnel) . Évalué à 2.
En fait j'ai exactement ces valeurs. Et pourtant, impossible d'accéder aux sites concernés durant la panne en question.
D'où l'astreinte en ce joli dimanche matin, parce que «ahhh y a plus rien qui marche» au boulot.
alf.life
[^] # Re: Mais non ! \o/
Posté par Zenitram (site web personnel) . Évalué à 0.
Ha oui, tous ceux qui ne pensent pas comme toi sont forcément des noobs.
Peut-être qu'ils ne le sont pas…
[^] # Re: Mais non ! \o/
Posté par eingousef . Évalué à -6.
LOL le zenitruc non seulement il essaye de me donner des leçons de tolérance, mais en plus il fait partie des gogols qui croient que la gratuité sans contrepartie existe dans le monde des CA incluses dans les navigateurs.
Mais va jouer aux billes sur l'autoroute mec :D
*splash!*
[^] # Re: Mais non ! \o/
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 05 avril 2015 à 23:20.
Tout de suite l'insulte, ça en dit long…
(le classique de l'attaque personnelle plutôt que les idées)
La personne à qui tu réponds dit juste que les gens qui prennent ces certificats gratuits le font peut-être en connaissance de cause et parient qu'ils auront moins à payer en révocation qu'en achat plutôt que d'être noob
tu préfères payer 30€/an pour éviter de payer 50€ tous les 5 ans (et encore, un Heartbleed ça doit arriver plus que tous les 5 ans, après il faut être noob pour pommer son certificat et avoir besoin de le révoquer), c'est ton choix, mais peut-être que d'autres font simplement un autre calcul, c'est tout.
Appeler noob les personnes qui ne sont pas d'accord avec toi, c'est de la tolérance?
Effectivement, j'ai un problème de tolérance envers l'intolérance, grand dilemme classique.
PS : je n'ai rien contre les gens à qui ça arrive de pommer un certificat, ça arrive, ils ne sont pas noob, c'est juste pour répondre ici.
[^] # Re: Mais non ! \o/
Posté par eingousef . Évalué à -3.
Ah parce que tu t'imagines qu'ils vont les payer les 50€ ? Tu t'imagines que ceux qui veulent pas payer l'inclusion de leur certif dans les navigateurs vont se sentir prêt à débourser 50 balles le jour où celui-ci se retrouvera dans la nature ? Mouarf t'es bien naïf :)
Ils vont créer un nouveau certif, le faire valider, remplacer l'ancien sur leur serveur et rien dire à personne et ça leur coûtera peau d'zob. Et ceux qui le trustent encore tant pis pour leur gueule.
Ce qu'ils veulent c'est afficher un joli cadenas dans le brouteur sans que celui-ci gueule, hein, le reste ils s'en foutent.
PS: On dit "paumer", pas "pommer". T'as vraiment un problème avec les fruits, hé, gogol :D
*splash!*
[^] # Re: Mais non ! \o/
Posté par Xavier Teyssier (site web personnel) . Évalué à 2.
Merci d'éviter les attaques ad hominem qui n'ont rien à faire ici.
[^] # Re: Mais non ! \o/
Posté par Antoine (site web personnel) . Évalué à 2.
Sauf que :
Et étant utilisateur de leur service, je trouve ça plutôt juste de faire payer la validation (qui est l'étape qui prends du temps en grosse partie humain) plutôt que de l'émission de certificats (qui est pratiquement automatisée à 100%). En dehors des assurances, il n'y a à ma connaissance pas grand chose qui justifie que certaines CA se gavent autant sur l'émission d'un certif.
Concernant les frais de révocation, ça ne me choque pas plus que ça. Je ne vois même pas ça comme un pari à faire sur le fait que l'on révoque très rarement puisque ces frais sont à la louche équivalents aux prix d'un certif chez pas mal d'autres CA. Il ne faut pas oublier aussi que c'est certainement un process en partie humain chez eux et qu'ils ont un intérêt à ne pas trop faire grossir leur CRL.
[1] https://www.startssl.com/?app=25#72
[^] # Re: Mais non ! \o/
Posté par eingousef . Évalué à -5.
Ah oui et puis ça aussi c'est collector :D
Et juste après, il revient sur le moment où il a placé le mot "noob" :
Un grand dilemme classique !
*splash!*
# Non, Opera aussi
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 6.
Opera aussi gère OCSP depuis un paquet d'années, et c'était justement bien galère, parce que les serveurs OCSP sont très souvent down, vu que tout le monde s'en branle, du coup ça faisait des lenteurs pas très agréables.
De plus OCSP est encore une connerie qui envoie des infos privées à une tierce partie quand on visite un site web, c'est pourquoi il est conseillé de désactiver cette "fonctionnalité". Même Chrome ne l'active pas, pour des raisons de "respect de la vie privée", c'est dire !
(Oui je conseille aussi de vider la liste des CA et ne pas faire confiance aux CA installés dans les navigateurs, qui ne sont souvent absolument pas vérifiés et donnent des certificats à n'importe qui pour n'importe quel domaine. Cf. encore récemment la débâcle de CNNIC, que Mozilla a décidé de virer de Firefox… 5 ans après que le monde entier ait commencé à leur dire que CNNIC n'était pas un CA fiable. Purée.)
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Non, Opera aussi
Posté par jcs (site web personnel) . Évalué à 2.
Faire une telle généralisation c'est aller un peu vite en besogne. Pour modérer un peu je voudrais tout de même préciser que les AC des navigateurs doivent bien être vérifiées. Une certification (et donc un audit) ETSI, CA/Browser Forum ou ISO 21188 est une condition sine qua non de tous les programmes d'inclusion d'AC. Et la plupart des AC font bien leur travail. Mais comme dans tout processus d'audit il peut y avoir des erreurs, des manquements, des attaques et même de la triche, comme par exemple lors des affaires Comodo, Diginotar, ANSSI ou CNNCI. Dans ce cas les différents acteurs (navigateurs, auditeurs, organismes de certifications…) cherchent toujours à améliorer les processus d'inclusion et de contrôle et d'opérations des AC. En outre les initiatives telles que HSTS, Public Key Pinning, Certificate transparency ou encore DANE tentent de réduire l'impact en cas d'émission frauduleuse de certificat.
[^] # Re: Non, Opera aussi
Posté par Firwen (site web personnel) . Évalué à 8. Dernière modification le 06 avril 2015 à 14:57.
Non, il a entièrement raison.
Le système de CA est cassé depuis des années, et tout le monde le sait.
https://www.youtube.com/watch?v=Z7Wl2FW2TcA
À l'heure actuelle, il y a environ plus de 1000 CA considéré comme valides dans la plupart des navigateurs: c'est une aberration.
Il suffit qu'UNE SEULE d'entre elles ait été corrompue ou trouve sympa de collaborer avec la NSA/FSB/GCHQ/DGSE/(inserer autre ici) pour que l'intégralité du système soit compromis.
Aussi "sérieuse" que peuvent être certains CA, ça ne change rien au problème. Et ni OCSP, ni les CRL ni HSTS ne fournit une solution acceptable à ça.
Le certificate pinning ne marche que pour les quelques "gros" acteurs du secteurs, le certificate transparency est uniquement à l'état de prototype et ne règle pas tous les problèmes. DANE est une blaque de complexité qui remplace un monstre par un autre.
À l'heure actuelle, si vous voulez réellement "sécuriser" votre application métier en interne… Le seul moyen est de créer votre propre CA et d'éliminer tous les autres….
Solution qui est bien évidemment inacceptable pour le Web.
Bref, c'est la merde.
# Exceptionel ? Pas vraiment.
Posté par Firwen (site web personnel) . Évalué à 4.
À mon humble avis, c'est plutot l'OCSP que StartCom dans cette histoire.
Il y a déja eu pas ma lde cas similaire dans le passé.
L'OSCP est mauvais par design, et ce n'est pas pour rien que les navigateurs principaux le désactive par défaut.
Même si ça sent grandement le troll, je dirais que même les CRLs étaient mieux conçu que OCSP….
[^] # Re: Exceptionel ? Pas vraiment.
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 06 avril 2015 à 15:43.
Une technologie est neutre, c'est celui qui a décidé d'activer OSCP dont il faut parler.
Ou comment tirer un gros Scud sur Mozilla de manière indirecte ;-).
Ouch.
(mais effectivement, activer OSCP et OSCP en lui-même sont de fausses bonnes idées, ça arrive, le tout est de corriger et le virer, la correction du problème est pire que le problème)
Mais pourquoi alors Mozilla l'active par défaut?
[^] # Re: Exceptionel ? Pas vraiment.
Posté par Firwen (site web personnel) . Évalué à 1. Dernière modification le 06 avril 2015 à 21:16.
Ça c'est ton interprétation ou ta croisade personnelle mon cher Zenit.
Chez moi, et c'est le paramètre par défaut de ma distro. Firefox a effectivement OCSP activé par défaut mais configuré comme "non requis", donc pas de problème.
[^] # Re: Exceptionel ? Pas vraiment.
Posté par Kioob (site web personnel) . Évalué à 1.
Soit il y a un problème d'implémantation soit les serveurs StartSSL répondaient effectivement mais mal : comme indiqué précédemment, sous Debian et Windows le réglage est également sur «non requis» par défaut. Et pourtant, impossible d'accéder à ces services durant toute la journée de dimanche.
alf.life
[^] # Re: Exceptionel ? Pas vraiment.
Posté par gouttegd . Évalué à 5.
À ma connaissance, le réglage par défaut est de tenter de confirmer la validité du certificat en contactant le serveur OCSP, mais d’accepter quand même le certificat si jamais le serveur OCSP ne répond pas (soft-fail, par opposition au hard-fail, où l’impossibilité de contacter le serveur OCSP entraîne automatiquement le refus du certificat).
Ici, d’après le message d’erreur que tu rapportes :
Le serveur OCSP a bel et bien répondu, mais il a répondu qu’il ne connaissait pas le certificat que tu lui demandes de vérifier (ce qui signifie : « je n’ai pas émis ce certificat »).
Dans ce cas de figure, le réglage soft-fail ou hard-fail n’a aucune importance (il ne fait de différence que lorsque le serveur OCSP ne répond pas). Même en mode soft-fail, le navigateur ne peut pas ne pas tenir compte d’une réponse négative du serveur OCSP (sinon à quoi bon demander en premier lieu ?).
Le problème semble purement du côté de Startcom, dont les serveurs OCSP tardent à être informés de l’émission de nouveaux certificats.
[^] # Re: Exceptionel ? Pas vraiment.
Posté par Zenitram (site web personnel) . Évalué à 2.
Euh… Ca change pas mal le contenu du journal ce que tu dis.
OSCP a des problèmes (sous entendu de manière général) != OSCP a des problèmes sur les nouveaux certificats (sous entendu une petite partie des certificats).
Ce n'est pas terrible, mais ça casserait pas mal l'attaque des détracteurs de StartCom (suffit d'attendre un peu, rien de bien horrible à partir du moment où on le sait).
[^] # Re: Exceptionel ? Pas vraiment.
Posté par gouttegd . Évalué à 4. Dernière modification le 07 avril 2015 à 14:25.
Il y a peut-être eu un autre problème plus compliqué que ça, sur un rapport de bug lié quelqu’un rapporte la même erreur (certificat inconnu) pour un certificat émis il y a plusieurs mois. Cela semble résolu puisque le serveur OCSP répond désormais que le certificat est valide (testé à l’instant), mais ça laisse quand même planer un doute sur la qualité du service OCSP…
Et ce doute va faire que lorsqu’un serveur OCSP de Startcom renverra une réponse négative à juste titre, tout le monde l’ignorera en disant « non mais les serveurs OCSP de Startcom, ils n’ont jamais été fiables, vas-y, passe outre le message d’erreur »…
[^] # Re: Exceptionel ? Pas vraiment.
Posté par Kioob (site web personnel) . Évalué à 2.
Si ce n'est que là il s'agissait de certificats en production depuis plusieurs mois (8 mois pour être exact).
Pour ce qui est du délai sur les nouveaux certificats, oui, j'étais déjà au courant (ce délai a d'ailleurs été fortement réduit ces derniers mois).
alf.life
[^] # Re: Exceptionel ? Pas vraiment.
Posté par eingousef . Évalué à 1.
C'est pas la faute d'OCSP ça. Sinon autant dire que tous les protocoles autres que HTTP sont mauvais par design.
*splash!*
[^] # Re: Exceptionel ? Pas vraiment.
Posté par flan (site web personnel) . Évalué à 2.
Accessoirement, on peut faire de l'OCSP via HTTP.
[^] # Re: Exceptionel ? Pas vraiment.
Posté par Firwen (site web personnel) . Évalué à 3. Dernière modification le 06 avril 2015 à 21:15.
De mon point de vue c'est de la faute d'OCSP et de son design.
OCSP n'est pas seulement un protocole mais une "solution" pour fournir, entre autre, un système de révocation à TLS.
Non seulement cette solution ne prend même pas un cas de figure aussi courant en compte, mais en plus elle rend TLS inopérant quand il se présente.
Si tu design un protocole censé "renforcer" la sécurité d'une solution existante. Tu le fais au minimum sans pénaliser l'existant.
Même les CRLS qui sont généralement configurées pour "fetcher" de manière asynchrones les listes via un protocol X, ou DANE, ne souffrent pas de ce problème.
[^] # Re: Exceptionel ? Pas vraiment.
Posté par Zenitram (site web personnel) . Évalué à 1.
C'est la faute d'OSCP, si : un protocole qui bloque une connexion si pas de communication possible doit passer par la où on est allé chercher l'information qu'on veut valider, et pas sur un autre serveur non plus.
vu qu'on veut valider un nom de domaine et la session TLS, il faut donc faire un design qui passe par le DNS ou le même chemin.
tiens, c'est d'ailleurs pour ça que OCSP n'a pas la côte et qu'on pense à DANE et OSCP stapling, pour corriger les défauts de conception d'OCSP ;-).
D'OSCP stapling: "OCSP stapling addresses most of the issues with the original OCSP implementation", que je traduis rapidement par : c'est la faute d'OCSP ça.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.