Journal SSL EV, étendue oui, validation euh...

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
47
28
déc.
2015

On va parler d’ingénierie sociale… Non, je plaisante, pour notre sujet ce niveau est trop élevé, on va juste parler de chaîne de validation rigolote.

Tout part d'un prix pas trop cher pour un SSL EV (parce que le EV, on on voit à tous les prix, du simple au sextuple facile) directement chez un vendeur qui gère la chaîne complète (pas un revendeur, mais bien un qui a son certificat racine dans les navigateurs, ps n'importe qui donc), j'avais envie de me faire plaisir à voir le nom de mon entreprise sur fond vert dans les navigateurs Internet (certains ont des passe-temps bizarres dirait mon admin sys), pas de raison que seules les grosses boites comme Apple se fassent plaisir.
Paiement facile (l'argent c'est important) sans jamais dire quelles sont les conditions précises pour la validation, je croyais bêtement que j'allais recevoir un courrier à mon adresse professionnelle physique pour vérifier l'identité de la personne morale.
J'avais fourni tout ce qui peut aider : numéro SIRET de mon entreprise etc.
Mis en attente, "le temps de faire les vérifications", je comprend.
10 jours plus tard, j'envoie un mail au support car je n'avais pas de nouvelles.
Réponse : ils n'ont pas pu identifier mon numéro de téléphone. Ok, admettons, je ne savais pas qu'une entreprise devait obligatoirement avoir un numéro de téléphone (bon, déjà ils ne me font pas le coup de demander un numéro de fax, car j'en ai eu des problèmes à ne pas avoir de fax, et non mon entreprise n'a pas 30 ans d'âge), je leur file une copie de ma facture de téléphone avec nom et adresse de l'entreprise, et… refusé. ha… Oui, refusé car il faut que le numéro soit sur un site style pages jaunes. bon, personne dans mon domaine utilise ce genre de chose, donc je leur propose mon extrait Kbis de l'entreprise, avec une adresse physique qui est la seule chose qui peut servir à valider une entreprise étant donné qu'un numéro de téléphone n'a aucune valeur juridique, plutôt mais non il faut un tel public. Le tel sur les registres DNS? Pas l'air de convenir non plus.

Étape 2, faisons donc un peu d’ingénierie sociale… non, déjà dit au début.
Car pour avoir son numéro de téléphone sur Pages Jaunes (ou dan le style, ils filent une liste d'une petite dizaine de sites "référence"), tenez vous bien, il suffit… de demander l'inscription sans aucune vérification que le numéro appartient à l'entreprise (ils appellent juste le numéro pour vérifier que tu veux ce numéro public)

Étape 3, on t’appelle pour vérifier que c'est bien l'entreprise (aparté: on te demande avant les horaires souhaités, pour t’appeler en dehors de ces horaires), et la on s'accroche : nom, prénom, fonction, je donne ces infos publiques (entreprise oblige, les infos sont sur infogreffe), et.. C'est tout. Ou presque. On me demande de passer un collègue. Bon, ils n'étaient déjà pas au point sur Internet et ils leur fallait un numéro de tel, je prend donc du temps pour expliquer qu'il arrive en 2015 que les entreprises soient mono-travailleur, mais aussi que les autres travailleurs soient sur un autre site; arghhhh… Pas prévu dans le script, mais personne m'a prévenu que les certificats SSL EV étaient réservés que pour les entreprises avec un numéro de téléphone et avec au moins 2 personnes sur le même site physique! N'ayant personne sous la main à part ma femme, cette dernière se retrouve avec le téléphone et dit son nom, prénom, fonction (en se demandant ce qu'elle vient faire la). Et c'est tout! A quoi est-ce utile? Mystère…

Résumons donc : pour obtenir un certificat SSL EV, il faut… Rien de l'entreprise. Juste faire une petite démarche sur un site perdu que le propriétaire légitime ne regarde pas mais "référence" pour le vendeur de certificat, afin de lister un numéro de téléphone quelconque. J'avais déjà entendu parler d'ingénierie sociale, où le propriétaire légitime se fait avoir par une manipulation pour "extraire" une information mais pour avoir un SSL EV le propriétaire légitime n'est jamais contacté. On demande des trucs stupides (un numéro de téléphone pour un site web, ha ha, ce numéro peut être quelconque, un nom / prénom sans avoir à donner de preuve) a un inconnu, c'est tout, en se reposant sur une chaîne de sécurité trouée (se reposer sur un site listant un numéro de téléphone sans faire de vérifications, est-ce vraiment valider?).
Je constate donc deux choses :
- N'importe qui peut avoir le nom qu'il veut dans le certificat SSL EV dès lors que l'entreprise visée n'a pas rempli "sa" page sur par exemple Pages Jaunes, ce qui arrive de plus en plus souvent (c'est de moins en moins important, les gens mettent plutôt leur numéro de téléphone sur leur site web, et puis Google n'est pas dans tous les villages de France donc on peut sans doute inscrire son tel avec Google comme nom pour un village perdu)
- N'importe qui peut trouver un certificat SSL EV au nom de son entreprise mais non légitime sans jamais avoir fait une seule erreur en sécurité.

C'est beau la sécurité sur Internet… Je ne m'attendais pas à une grosse validation, mais je ne m'attendais pas à aucune validation réelle (par exemple par vérification de la réalité du nom de l'entreprise, test de l'adresse physique… Bref, à ce que mon identité a été authentifée selon les normes les plus élevées de l'industrie dixit la pub)
Alors certes on n'a pas trouvé mieux (CACert était une bonne blague de gens se croyant plus forts que les autres mais dont même les plus libristes se sont mis à douter de la faisabilité passé l'euphorie du début, DANE a du mal à percer sans doute du fait de sa complexité de mise en œuvre et de maintenance tout en étant me semble-t-il que du niveau de SSL DV), on colmate les trous (on vire SHA-1 ou RSA-1024, on vire les certificats wildcards, on fait plus attention aux certificats révoqués, on met en place Certificate Transparency, on met du HSTS / Forward Secrecy…), on essaye de faire du SSL DV "pour tous" (Mozilla Let's Encrypt…), on essaye de faire passer tout le monde en chiffré (HTTPS Everywhere…) pour que son FAI ou bar du coin ne se fasse pas plaisir à lire le contenu, mais pour le EV j'ai quand même du mal maintenant à comprendre l’intérêt pratique (sorti de se faire de la thune) à part faire payer cher une sécurité placebo (parait que les utilisateurs ne voient pas la différence) même pour les gens à cheval sur la sécurité et regardant tout, et un joli affichage dans son navigateur qui ne promet aucune meilleure sécurité. Cela suffit aujourd'hui (pas encore de SSL EV avec CT qui a été conspué car pas filé à la bonne personne), mais pour combien de temps? Et finalement, est-il ou sera-t-il possible d'avoir un jour une validation réelle de l'existence physique d'une entité ayant un nom de domaine?

PS : bon, après, on peut rigoler, mais ça n'a pas l'air pire que les revues scientifiques à qui la personne qui veut avoir une validation de son article par les pairs fournit l'adresse mail de ses pairs en se disant que personne n'aura l'idée que le chercheur fournirai une adresse quelconque qu'il contrôle, non… (source)

  • # Vivement 2016

    Posté par  . Évalué à -10.

    Dans ta diatribe tu as oublié de casser la France et d'encenser l'Allemagne et les opposants à cop21…

    Presque un bingo zenitram complet.

  • # Et c'est joli au moins?

    Posté par  . Évalué à 6.

    Tu as oublié de mettre l'objet de ton désir : l'image du certificat vert sur ton navigateur :

    SSL EV

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Et c'est joli au moins?

      Posté par  (site web personnel) . Évalué à 3.

      L'objet de mon désir n'est qu'un élément secondaire et n'a aucun intérêt, donc pas un oubli.
      Sinon oui c'est joli ils ont même accepté les majuscules la où il faut :-D.

      Par contre je me demande pourquoi le fond de l'url est rouge chez toi.
      (Si c'est à cause du sha1 préféré pour la suite de chiffrement, ça sera bientôt modifié pour prendre en compte les priorités bizarres des navigateurs, c'est ce qui me manque pour être totalement content)

      • [^] # Re: Et c'est joli au moins?

        Posté par  (site web personnel) . Évalué à 1.

        Il ne restera plus qu'à désactiver le fingerprinting de ton Apache en plus de la réorganisation de la suite des ciphers, et ce sera pas mal :)

        Mes messages engagent qui je veux.

        • [^] # Re: Et c'est joli au moins?

          Posté par  (site web personnel) . Évalué à 2.

          Voila, suite des ciphers réorganisée pour que SHA soit en dernier, mais la réaction de FF et Chrome me surprend toujours (je priorise AES256 sur AES128, pour chaque combinaison, mais FF et Chrome s'entêtent à choisir du AES128), IE/Edge et Safari (et un Android 4.4 alors que 5.0 passe en 128) prennent du AES256. OK AES128 n'est pas encore troué, mais quand même bizarre de ne pas prendre du AES256 alors qu'on sait faire.
          Sélectionner AES256 avec SHA1 mais SHA128 avec SHA2, il y a des choix bizarres.

          Quand au fingerprint, pas encore troué l'argument qui convainc mon adminsys (je me fais violence, je délègue, et il ne faut ensuite pas imposer quoi que ce soit a l'adminsys, c'est le patron de ce domaine ensuite :) )

          • [^] # Re: Et c'est joli au moins?

            Posté par  . Évalué à 9.

            OK AES128 n'est pas encore troué, mais quand même bizarre de ne pas prendre du AES256 alors qu'on sait faire.

            La taille de la clef n’est pas tout. Oui, Firefox sait faire du AES-256, mais seulement en mode CBC, pas en mode GCM. Donc, même si ton serveur propose du AES256-GCM et du AES256-CBC, Firefox lui doit choisir entre AES128-GCM et AES256-CBC — et il n’y a rien d’anormal à privilégier le premier :

            128-GCM is far, far more desirable than 256-CBC.

            Et indépendamment des questions de modes d’opération, il y a d’autres raisons qui peuvent faire qu’un algorithme utilisant des clefs de 256-bits ne soit pas forcément plus sûr qu’un algorithme à clef de 128-bits. Dans le cas d’AES par exemple, il existe des attaques qui ciblent spécifiquement les versions 192/256-bits et qui sont inopérantes contre la version 128-bits. Bon, ce sont des attaques purement théoriques, mais ça illustre le fait qu’il vaut mieux réfléchir un peu avant de foncer bille en tête vers les clefs les plus grosses…

            (Au passage, une clef RSA de 4096-bits pour un certificat valable deux ans, je trouve ça complètement disproportionné.)

            • [^] # Re: Et c'est joli au moins?

              Posté par  (site web personnel) . Évalué à 2. Dernière modification le 28 décembre 2015 à 20:45.

              128-GCM is far, far more desirable than 256-CBC.

              "Firefox sait faire du AES-256, mais seulement en mode CBC, pas en mode GCM", ca casse quand même. C'est quand même bizarre vu qu'il sait le gérer en AES-128 et que des concurrents savent faire en AES-256 aussi?
              je suis d'accord avec le commentaire "It is a shame that Firefox cannot access servers which are limited to only allow the strongest cipher suites available."
              128-GCM is far, far more desirable than 256-CBC, OK, but 256-GCM is far, far more desirable than 128-GCM.

              Rappel de ce que j'ai dit : IE/Edge et Safari choisissent 256 (je sous entendais GCM en priorité), voila le résultat SSLLabs
              Android 4.4.2 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1
              Android 5.0.0 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1
              Chrome 47 / OS X R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
              Firefox 42 / OS X R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
              Edge 13 / Win 10 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
              Safari 9 / OS X 10.11 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

              pour les mêmes priorités, pour les mêmes générations.
              (et noter la "régression" sur Android, la je ne pige pas la suppression, peut-être un pb de perf/conso)

              Mozilla était en avance sur Microsoft sur la sécu, le voila en retard, ca ne fait pas bizarre?
              (bon, du coup pareil pour Chrome aussi, et pareil pour Apple aussi, j'aurai vraimeent inversé tout le monde là…)
              Note: je suis conscient que AES-128 n'est pas cassé aujourd'hui, mais on ne sait pas dequoi est fait demain, ca met toujours du temps quand une vulnérabilité est découverte pour migrer. Et c'est aussi une question d'image, c'est important l'image technique pour les geeks.

              (Au passage, une clef RSA de 4096-bits pour un certificat valable deux ans, je trouve ça complètement disproportionné.)

              Plus ou moins d'accord, après c'était une préference pas de moi et je n'ai pas pris le temps de démontrer que ca flingue beaucoup le temps de handshake, donc faute d'arguments c'est resté (et ca n'a pas l'air de faire trop de mal, faudra que je teste le délai réel un jour que je ne saurais pas quoi faire)

              • [^] # Re: Et c'est joli au moins?

                Posté par  . Évalué à 9.

                but 256-GCM is far, far more desirable than 128-GCM.

                Si tu lis le message référencé, tu verras que ce n’est pas une opinion partagée par tout le monde :

                On a scale of security AND speed
                128-GCM > 128-CBC
                128-GCM > 256-CBC
                128-GCM ~ 256-GCM

                Ou, plus loin dans le même débat :

                the difference between AES 128 and 256 isn't "medium-grade" vs "high-grade". it's more like "high-grade and pretty fast" vs "high grade and slow for no reason".

                _

                Et c'est aussi une question d'image, c'est important l'image technique pour les geeks.

                Ça doit dépendre des geeks, mais perso quelqu’un qui joue à qui à la plus grosse avec ses clefs cryptographiques ne me fait pas une bonne impression, ça me renvoie plutôt l’image de quelqu’un qui ne sait pas ce qu’il fait réellement et pousse simplement tous les leviers au maximum parce que c’est forcément mieux — comme ce type que j’ai vu affirmer sans rire qu’il fallait privilégier SHA-512 à SHA-3 sans autre raison que 512 est supérieur à 3…

              • [^] # Re: Et c'est joli au moins?

                Posté par  . Évalué à 5.

                (et noter la "régression" sur Android, la je ne pige pas la suppression, peut-être un pb de perf/conso)

                Indirectement :

                just to give a bit more detail, android 5.0 disabled AES-256 GCM to be more closely aligned with what google chrome supports.

                Et c’est bien pour des questions de performance que les développeurs de Chrome ont choisi de ne pas supporter AES256-GCM :

                We intentionally did not implement AES-256-GCM because the security value of the AES-256 is not worth the performance tradeoff.

                • [^] # Re: Et c'est joli au moins?

                  Posté par  (site web personnel) . Évalué à 0.

                  Autant j'ai compris avec vos liens et explications qu'un navigateur veuille prioriser AES128 pour les perfs quand il a le choix, autant je ne comprend pourquoi c'est désactivé.
                  Si demain on trouve une faille dans AES128 et pas dans AES256, on ne peux pas configurer le serveur en enlevant AES128 pour que les navigateurs prennent AES256, on a aucun moyen de dire "coucou ça craint maintenant, on monte", et des navigateurs ça reste plus que la durée de certificats SSL (WinXP est toujours la, heureusement que Microsoft lui a fait un patch pour supporter SHA2 maintenant qu'on se rend compte que SHA1 craint et qu'on migre les certificats vers SHA2).
                  Bon, restera les navigateurs "à jour" qui activeront AES256, certes, et il ne restera que les "vieux" trucs…

                  • [^] # Re: Et c'est joli au moins?

                    Posté par  (site web personnel) . Évalué à 6. Dernière modification le 28 décembre 2015 à 22:43.

                    C'est assez simple : si tu casses algorithmiquement AES128, tu casses aussi AES256. C'est très peu probable, comme tu dis, de "trouver une faille dans AES128 et pas dans AES256".

                    Donc comme AES256 n'est pas accéléré sur les processeurs mobiles (pas sur le Snapdragon S4 en tous cas : https://calomel.org/aesni_ssl_performance.html) et que le compromis puissance requise/sécurité n'a semble t'il pas convaincu les ingés chez Google, c'est désactivé…

                    Luke O'Connor (sans vouloir jouer de l'argument d'autorité, ce n'est pas non plus le premier clampin venu en crypto) a un avis assez similaire, et le NIST aussi :

                    NIST’s recommendation above includes the threat model not only of predicting the key, but also of cracking the encryption algorithm. The difference between cracking AES-128 algorithm and AES-256 algorithm is considered minimal. Whatever breakthrough might crack 128-bit will probably also crack 256-bit.

                    (source : http://lukenotricks.blogspot.fr/2010/04/aes-128-versus-aes-256-encryption.html)

                    EDIT : cela dit, la différence ne semble pas non plus extrêmement importante, selon Google :

                    A standard phone (which is always defined by whatever I happen to have in my pocket; a Galaxy Nexus at the moment) can do AES-128-GCM at only 25MB/s and AES-256-GCM at 20MB/s (both measured with an 8KB block size).

                    (Source : https://www.imperialviolet.org/2013/10/07/chacha20.html)

                    Mes messages engagent qui je veux.

          • [^] # Re: Et c'est joli au moins?

            Posté par  (site web personnel) . Évalué à 1.

            Je ne comprends pas, tu as moyen de modifier l'ordre des ciphers (donc avec un accès au fichier de conf, non ?), tu peux donc désactiver la signature du serveur, ou je suis à côté de mes pompes ?

            Normalement, la directive ServerSignature Off est utilisable en global, mais aussi individuellement pour chaque vhost.

            Mes messages engagent qui je veux.

          • [^] # Re: Et c'est joli au moins?

            Posté par  . Évalué à 3.

            et un Android 4.4 [prend du AES256] alors que 5.0 passe en 128

            Je ne sais pour Android 4.4 précisément, mais

            • Android 4.1 ne supporte que le mode CBC, en 128- et 256-bits ;
            • Android 5.0 supporte le mode CBC en 128- et 256-bits, et GCM en 128-bits uniquement (comme Firefox).

            Donc, rien d’étonnant encore une fois à ce qu’un Android 4.x choisisse AES256 (il a le choix entre AES128-CBC et AES256-CBC, il prend « le plus gros ») là où un Android 5.x choisira AES128-GCM (le critère déterminant est le mode, non la taille de la clef).

            • [^] # Re: Et c'est joli au moins?

              Posté par  (site web personnel) . Évalué à 1. Dernière modification le 28 décembre 2015 à 21:08.

              A moins que SSL Labs raconte n'imp (ce qui peut arriver), ce n'est pas vrai en pratique, ce que tu énonces, la preuve avec mon serveur :

              Android 4.4.2 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp384r1 FS
              Android 5.0.0 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp384r1 FS

              Tiré de : https://dev.ssllabs.com/ssltest/analyze.html?d=harvester.fr&s=176.31.119.121&hideResults=on

              Android 4.4.2 prend bien du 256-GCM là où Android 5.0 "régresse" (oui parce qu'on encule plutôt les mouches là, pour le coup…) avec du 128-GCM :)

              EDIT : Au temps pour moi, tu parles de la 4.1, qui ne gère que TLS 1.0 donc automatiquement du CBC. Cela dit, Zenitram parlait bien de la version 4.4 dans son post.

              Mes messages engagent qui je veux.

              • [^] # Re: Et c'est joli au moins?

                Posté par  . Évalué à 2.

                Cela dit, Zenitram parlait bien de la version 4.4 dans son post.

                Je sais, mais j’ai testé avec ce que j’avais sous la main. ;)

      • [^] # Re: Et c'est joli au moins?

        Posté par  . Évalué à 4.

        Tu ne connais pas Le Fond de l'URL est Rouge, célèbre documentaire de Chris Browser à propos du mouvement hacktiviste des années 2000 ?

  • # PKIX et édition scientifique, même combat

    Posté par  . Évalué à 10.

    ça n'a pas l'air pire que les revues scientifiques

    Marrant que tu dises ça, j’ai toujours pensé que le monde de l’édition scientifique était pourri et n’offrait pas ce qu’on attendait de lui, et maintenant que j’y pense, je me demande si ce n’est pas pour les mêmes raisons qui font que le système PKIX est pourri et n’offre pas ce qu’on attend de lui…

    • Les autorités de certification prétendent se livrer à des vérifications sérieuses avant de délivrer un certificat. De même, certains éditeurs prétendent faire de la « revue par les pairs » (peer review) alors qu’il est évident à voir certains papiers qu’ils n’ont jamais été relu par quiconque, encore moins un « pair » spécialiste du sujet — sinon comment expliquer qu’on puisse publier des articles ouvertement bidons générés par un pipotron ?

    • Il n’est pas dans l’intérêt des CA de refuser un certificat à un client. De même, il n’est pas dans l’intérêt des éditeurs de rejeter un papier. Je veux croire que ce n’est pas le cas des éditeurs « sérieux », mais c’est clairement le cas de la tripotée d’éditeurs douteux qui ont vu le jour ces dernières années, qui en surfant sur la vague de l’Open Access acceptent en pratique tout ce qu’on leur soumet (predatory publishers).

    • Même les plus grosses CAs (Comodo, Verisign, etc.) ne sont pas irréprochables. Même les éditeurs historiques prestigieux n’hésitent pas à fouler le principe de la relecture par les pairs, comme lorsque Nature Publishing a publié l’histoire des « STAP stem cells » contre l’avis des relecteurs pour qui les données expérimentales étaient insuffisantes pour soutenir les conclusions.

    • Le business des CA ne souffre manifestement pas des différentes révélations montrant qu’elles ne sont pas dignes de confiance. De même, les éditeurs historiques conservent tout leur prestige (demandez à n’importe quel chercheur s’il ne voudrait pas voir son prochain papier publié dans Nature ou Science…), sans être affectés par les cas révélant les faiblesses du système.

    • Les mécanismes de révocation (CRLs, OCSP) sont largement inopérants. De même, les rétractions d’articles scientifiques passent largement inaperçues, et les papiers rétractés sont encore cités comme si de rien n’était. (Le meilleur exemple — ou le pire, question de point de vue — est probablement celui du papier qui prétendait démontrer un lien entre autisme et vaccination, que les anti-vaccinations continuent de brandir longtemps après que personne n’a pu répliquer les résultats et même après que le caractère frauduleux du papier a été établi.)

    • [^] # Re: PKIX et édition scientifique, même combat

      Posté par  . Évalué à 7.

      Grosso-modo, on pourrait appliquer les mêmes remarques aux dépôts de brevets aussi.

    • [^] # Re: PKIX et édition scientifique, même combat

      Posté par  . Évalué à 10. Dernière modification le 29 décembre 2015 à 19:34.

      De même, certains éditeurs prétendent faire de la « revue par les pairs » (peer review) alors qu’il est évident à voir certains papiers qu’ils n’ont jamais été relu par quiconque

      Ou alors relu vite fait par des gens qui n'en ont rien à foutre. J'ai par exemple eu le cas où on m'a soumis un papier visiblement écrit pas un étudiant : la biblio était en grande partie copiée / collée d'autres articles (pas de bol, je lis toutes les références aussi, et à cette époque je traquais le plagiat sur Wikipedia pour m'amuser, donc je sentais bien les ruptures de style); les formules avaient des termes non définis ou des erreurs; ça annonçait de l'optimisation en conception de lanceurs (de fusées) à plusieurs étages, mais en vrai ça ne faisait que "montrer" que sur une modélisation basique telle méthode était meilleure que telle autre (ce que tout le monde savait)… L'interface de relecture me donnait accès au commentaire de l'autre relecteur qui disait en gros "ça a l'air intéressant" sans rien justifier de plus. Heureusement, aux vues des deux commentaires, le directeur de la publication a refusé le truc, mais si tout le monde lisait aussi légèrement les articles… C'était pas une super revue, mais quand même ! À l'inverse, j'ai aussi eu le cas de relecteurs chinois qui demandent simplement qu'on cite leurs papiers (qui n'ont strictement rien à voir) et rien d'autre.

  • # Théorie vs pratique

    Posté par  . Évalué à 4. Dernière modification le 30 décembre 2015 à 16:24.

    Si tu veux t’amuser, tu peux consulter les guidelines du CA/Browser Forum pour la délivrance des certificats EV (guidelines auxquelles Comodo déclare se conformer dans son Certificate Practice Statement), et comparer avec ton expérience…

    Par exemple :

    il faut que le numéro soit sur un site style pages jaunes.

    Qui est probablement considéré comme une Qualified Independent Information Source (section 11.11.5 des guidelines, p. 27), soit :

    a regularly-updated and publicly available database that is generally recognized as a dependable source for certain information. A database qualifies as a QIIS if the CA determines that:
    ① Industries other than the certificate industry rely on the database for accurate location, contact, and other information; and
    ② The database provider updates its data on at least an annual basis.

    _

    se reposer sur un site listant un numéro de téléphone sans faire de vérifications, est-ce vraiment valider?

    Les CA sont invitées (mais sans obligation, SHALL et non MUST…) à « utiliser un processus documenté pour vérifier la fiabilité » de la QIIS, je ne doute pas un seul instant qu’elles le font ⸮

    Bref, à ce que mon identité a été authentifée selon les normes les plus élevées de l'industrie dixit la pub

    C’est beau de croire la pub… S’il fallait croire la page que tu cites, les certificats EV « [assurent] ainsi aux utilisateurs que votre site est fiable ».

    C’est un mensonge éhonté, comme la section 2.1.3 des guidelines le stipule clairement :

    EV Certificates focus only on the identify of the Subject named in the Certificate, and not on the behavior of the Subject. As such, an EV Certificate is not [l’emphase est d’origine] intended to provide any assurances, or otherwise represent or warrant […] that it is “safe” [guillemets d’origine…] to do business with the Subject named in the EV Certificate.

    C’est d’ailleurs LE gros mensonge de tout le système TLS/X.509 appliqué au web (et la raison pour laquelle j’ai envie de jeter mon café à la face de « Laura du Web » et les autres « journalistes » dans son genre quand ils disent de ne pas donner son numéro de carte bleue avant d’avoir vérifié qu’il y a bien « un piti cadenas dans le bas de votre écran ») : la seule chose que ce système peut garantir (et encore, s’il tenait ses promesses, ce qui n’est pas le cas), c’est que le visiteur est bien sur le site sur lequel il voulait aller et que personne entre lui et le site n’intercepte la communication (c’est seulement ça que veut dire le « piti cadenas »). Mais ce que veut savoir le visiteur est beaucoup plus large que ça : il veut savoir s’il peut se fier au site qu’il a en face de lui, ce qui certes inclut d’être certain de son identité mais pas seulement…

    Ou, comme l’illustre très bien Grise Bouille avec l’exemple de Facebook : « Notez que le protocole HTTPS assure seulement le chiffrement des communications : il ne garantit pas du tout que le site visité est digne de confiance ! »

    • [^] # Re: Théorie vs pratique

      Posté par  . Évalué à 4.

      mais sans obligation, SHALL et non MUST

      shall et must sont synonymes

      http://www.ietf.org/rfc/rfc2119.txt

      • [^] # Re: Théorie vs pratique

        Posté par  . Évalué à 4.

        Bien vu, autant pour moi, j’ai confondu avec SHOULD.

        Ça me rassure du coup, parce qu’il est évident qu’une CA n’oserait jamais manquer aux obligations du CA/Browser Forum… n’est-ce pas ?

    • [^] # Re: Théorie vs pratique

      Posté par  . Évalué à 1.

      EV Certificates focus only on the identify of the Subject named in the Certificate, and not on the behavior of the Subject.

      Cet extrait dit bien que les certificats EV sont censés garantir l'identité du "sujet", or l'expérience de Zenitram montre que ce n'est pas le cas.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.