Journal panne de l'OCSP chez StartSSL/StartCom

Posté par (page perso) . Licence CC by-sa
Tags :
11
5
avr.
2015

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 (page perso) . É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.

    Opera le fait depuis 10 ans.

  • # Certificats de classe 1 seulement

    Posté par . É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 . É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 !).

  • # Mais non ! \o/

    Posté par . Évalué à 4.

    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.

    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 (page perso) . Évalué à 4. Dernière modification le 05/04/15 à 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 :

      Échec de la connexion sécurisée

      Une erreur est survenue pendant une connexion à blabla. Le serveur OCSP n'a pas de statut pour le certificat. (Code d'erreur : sec_error_ocsp_unknown_cert)

      La page que vous essayez de consulter ne peut pas être affichée car l'authenticité des données reçues ne peut être vérifiée.
      Veuillez contacter les propriétaires du site web pour les informer de ce problème.

      alf.life

      • [^] # Re: Mais non ! \o/

        Posté par . Évalué à 2.

        On peut toutefois désactiver la sécurité en question dans les préférences de Firefox, mais qui va le faire ?

        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 (page perso) . É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 (page perso) . Évalué à 2.

            Dans about:config j'ai les valeurs par défaut suivantes (Iceweasel 31.5.3):

            security.OCSP.GET.enabled false
            security.OCSP.enabled true
            security.OCSP.require false

            Peut-être que le require a été changé par une extension/option ?

            • [^] # Re: Mais non ! \o/

              Posté par (page perso) . É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 (page perso) . Évalué à 0.

      les noobs qui prennent des certifs chez cette boite parce que c'est gratuit

      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 . É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 (page perso) . Évalué à 3. Dernière modification le 05/04/15 à 23:20.

          gogols

          Tout de suite l'insulte, ça en dit long…
          (le classique de l'attaque personnelle plutôt que les idées)

          qui croient que la gratuité sans contrepartie existe dans le monde des CA incluses dans les navigateurs.

          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.

          des leçons de tolérance

          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 . Évalué à -3.

            payer 50€ tous les 5 ans

            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 (page perso) . Évalué à 2.

              Merci d'éviter les attaques ad hominem qui n'ont rien à faire ici.

            • [^] # Re: Mais non ! \o/

              Posté par (page perso) . Évalué à 2.

              Sauf que :

              1. La révocation coûte 25 USD et pas 50€ [1]
              2. Il n'est pas possible de redemander un certificat émis et en cours de validité (bon, il existe des parades).

              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 . Évalué à -5.

            Ah oui et puis ça aussi c'est collector :D

            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.

            Et juste après, il revient sur le moment où il a placé le mot "noob" :

            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.

            Un grand dilemme classique !

            splash!

  • # Non, Opera aussi

    Posté par (page perso) . É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 (page perso) . Évalué à 2.

      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.

      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 (page perso) . Évalué à 8. Dernière modification le 06/04/15 à 14:57.

        Faire une telle généralisation c'est aller un peu vite en besogne.

        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 (page perso) . É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.

    • Il cause des problèmes de latence
    • Il ne marche pas lorsque le client est derrière un pare-feu/proxy un peu trop restrictif
    • Il crée un goulot d'étranglement sur une techno qui a été créée pour ne pas en avoir.
    • Il facilite grandement les attaques par DDOS ….

    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 (page perso) . Évalué à 2. Dernière modification le 06/04/15 à 15:43.

      À mon humble avis, c'est plutot l'OCSP que StartCom dans cette histoire.

      Une technologie est neutre, c'est celui qui a décidé d'activer OSCP dont il faut parler.

      ce n'est pas pour rien que les navigateurs principaux le désactive par défaut.

      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)

      Il y a déja eu pas ma lde cas similaire dans le passé.

      Mais pourquoi alors Mozilla l'active par défaut?

      • [^] # Re: Exceptionel ? Pas vraiment.

        Posté par (page perso) . Évalué à 1. Dernière modification le 06/04/15 à 21:16.

        Ou comment tirer un gros Scud sur Mozilla de manière indirecte ;-).

        Ç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 (page perso) . É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 (page perso) . Évalué à 5.

            le réglage est également sur «non requis» par défaut

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

            Une erreur est survenue pendant une connexion à blabla. Le serveur OCSP n'a pas de statut pour le certificat. (Code d'erreur : sec_error_ocsp_unknown_cert)

            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 (page perso) . Évalué à 2.

              dont les serveurs OCSP tardent à être informés de l’émission de nouveaux certificats.

              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 (page perso) . Évalué à 4. Dernière modification le 07/04/15 à 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 (page perso) . É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 . Évalué à 1.

      Il ne marche pas lorsque le client est derrière un pare-feu/proxy un peu trop restrictif

      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 (page perso) . Évalué à 2.

        Accessoirement, on peut faire de l'OCSP via HTTP.

      • [^] # Re: Exceptionel ? Pas vraiment.

        Posté par (page perso) . Évalué à 3. Dernière modification le 06/04/15 à 21:15.

        C'est pas la faute d'OCSP ça. Sinon autant dire que tous les protocoles autres que HTTP sont mauvais par design.

        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 (page perso) . Évalué à 1.

        Il ne marche pas lorsque le client est derrière un pare-feu/proxy un peu trop restrictif

        C'est pas la faute d'OCSP ça.

        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 à ceux qui les ont postés. Nous n'en sommes pas responsables.