Journal Quand la Caisse d'Épargne force ses clients à réactiver des protocoles de sécurité obsolètes

Posté par  . Licence CC By‑SA.
Étiquettes :
32
19
juil.
2020

Bonjour,
Client de la Caisse d'Épargne (dont je cherche clairement à en partir, et l'histoire du jour n'est pas la seule raison), quelle ne fut pas ma surprise de découvrir que le site Web de ma banque me demande ni plus ni moins que de rétablir des protocoles de sécurité que les navigateurs Web ne supportent plus : TLS 1.0 et 1.1
Pour consulter la liste des agences, et leurs coordonnées, pas le choix : il faut réactiver TLS 1.0 ou 1.1

Par curiosité, j'ai fait 2-3 recherches à ce sujet : Apple, Google, Microsoft et Mozilla ont annoncé en 2018 la fin de leur support, pour 2020.

Ce qui a donc laissé 2 ans aux banques pour s'organiser, et activer sur leurs serveurs le support de TLS 1.2 (dont la norme date de 2008), voire 1.3 (2018).

Et, si j'en crois ce site Web comparatif, ma banque est très loin d'être la seule à la bourre !

  • # Pour être exact

    Posté par  . Évalué à -10.

    Ce n'est pas la Caisse d'Épargne qui te demande de rétablir les protocoles de sécurité, mais c'est Firefox qui te le propose pour que tu puisses accéder au cadre contenu dans la page.

    • [^] # Re: Pour être exact

      Posté par  . Évalué à 10.

      Pour être exact, c'est la Caisse d'Épargne qui lui demande de réactiver des protocoles obsolètes, et Firefox qui lui propose de le faire.

      • [^] # Re: Pour être exact

        Posté par  (site web personnel, Mastodon) . Évalué à -5.

        Pour être encore plus exact c'est un site tiers (fc1.1bis.com d'après la capture) qui utilise un protocole obsolète. Sûrement pour du tracking à la con en plus. Mais pour le coup, ce n'est pas vraiment la faute de la Caisse d'Épargne.

        • [^] # Re: Pour être exact

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

          Mais pour le coup, ce n'est pas vraiment la faute de la Caisse d'Épargne.

          le choix des fournisseurs tiers (et même, déjà, oser déléguer un bout de sécurité en tant que banque) et leur contrôle que la sécurité est prise au sérieux est clairement la responsabilité de la Caisse d'Epargne, donc sa faute. Il ne faut surtout pas les dédouaner de leur responsabilité dans la sécurité pourrie d'un tiers qu'ils "imposent" à leurs clients.

          Mais surtout peut-être un jour se dire que la vie privée qui se balade dans la nature, c'est aussi laisser traîner des traces sur des serveurs tiers, même si la mode est actuellement à mettre un max de site tiers… J'en viendrai presque à souhaiter une belle faille (plus que la revente de nos activités sur le site de la banque) sur un site tiers des banques et que leur autorité de tutelle leur mette une belle amende pour leur faire comprendre que la vie privée c'est important. Je me dis que c'est qu'une question de temps (Twitter et leur sécurité, ça leur est revenu dans la gueule "que" cette semaine).

    • [^] # Re: Pour être exact

      Posté par  . Évalué à 5.

      Firefox me le propose, parce que le site que je cherche à consulter ne propose rien d'autre que es 2 protocoles obsolètes.
      Donc si : c'est bien la CÉ qui me demande de les utiliser (et Firefox qui m'avertit qu'ils sont obsolète, mais que si je le souhaite je peux encore les utiliser, en les réactivant).

  • # La Caisse d'Épargne est à la ramasse

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 19 juillet 2020 à 15:00.

    La CE est complètement à la ramasse au niveau numérique.

    Non respect du RGPD (scripts de tracking américains injectés dans l'espace privé, où il y a tous les détails bancaires!!!), script JS qui datent de 2010 avec le nom des développeurs et des console.log qui se baladent un peu partout.

    Leur site ou des parties sont down très très souvent.
    Leur service client est digne d'une banque des années 1995, à coup d'envois de mail avec des scan papier, des justifications foireuses et des process qui durent des mois (envoyer un chèque par la poste d'une CE à une autre CE d'un autre région au lieu de faire un virement).

    Et pour couronner le tout, leurs frais sont exorbitant.

    Bref, fuyez cette banque, au niveau national (j'ai changé de région plusieurs fois) !

    J'avais fait un ptit thread sur Twitter à l'époque https://twitter.com/edhelas/status/1213031376393519104

    • [^] # Re: La Caisse d'Épargne est à la ramasse

      Posté par  . Évalué à 8.

      une amie travaillant dans un systeme bancaire m'avais expliqué le pourquoi de la regionalisation des groupe bancaire.

      Les risques sont dilué au niveau regional, et les bénefice au niveau nationale \o/. D'ou un cloisonement très fort dans certaine banque entre chaque région, a se demander si ce n'est pas des pme regionale

  • # À jour ?

    Posté par  . Évalué à 4.

    Je pense que le comparatif vers lequel tu pointes mérite une petite mise à jour et sans doute un peu plus d'explication sur la méthode utilisée.

    En tout cas, ma banque qui fait partie du groupe noté E ne semble pas avoir de soucis du côté TLS1.2. La version française de la banque est même en 1.3.

    Bref, je pense pas que l'écosystème bancaire soit si catastrophique que dans ta banque.

    • [^] # Re: À jour ?

      Posté par  . Évalué à 2.

      Les notes sont attribuées selon les tests effectués par cryptcheck.fr, qui évalue selon la méthode de chiffrement détectée la plus faible (plus de détails ici).

      • [^] # Re: À jour ?

        Posté par  . Évalué à 4.

        • [^] # Re: À jour ?

          Posté par  . Évalué à 2.

          CryptCheck ne peut pas s'auto-tester :-)

        • [^] # Re: À jour ?

          Posté par  (site web personnel) . Évalué à 8. Dernière modification le 19 juillet 2020 à 21:42.

          Les sites que tu listes sont (à part LinuxFr) à destinations d'un public large, donc comprenant des gens qui ne mettent pas à jour leur équipement. Pour eux, il faut malheureusement pas désactiver les trucs vieillots genre RSA ou SHA1 sinon ces clients sont bloqués, et pour le moment bloquer ces clients "coûte" plus cher que garder les vieux trucs (qui ne réduisent pas la sécurité pour les gens à jour, merci TLS 1.2 et la non possibilité d'inciter à prendre un vieux protocole si au milieu).

          Pour LinuxFr, j'imagine que c'est une flemme "tant que ça marche" (+le fait que ça ne fait pas de mal pour le moment) car je doute qu'il y ai beaucoup de monde avec IE6/XP dessus…

          Mais sinon, oui ça a l'air de faire partie des sites "intégristes" qui ne regardent que si tu supportes un "mauvais" protocoles même si c'est pour supporter des vieux clients sans réduire la sécurité des nouveaux clients. C'est à prendre en tant que tel (genre pour un site dont tu connais bien les clients, par exemple la partie admin de ton site sur un sous-domaine qui serait blindé au max en autorisé que la crème de la crème car tu connais très bien les utilisateurs et tu leur imposes un truc à jour), perso je préfère genre SSLLabs qui me semble plus faire attention à la compatibilité qui ne réduit pas la sécurité (Google comme LinuxFr sont notés B car il y a une volonté de tuer TLS 1.1 alors que Google le fournit toujours, bon la c'est un choix pas très cohérent de mon point de vue car on devrait surtout viser les sites qui ne propose que TLS 1.1 ou inférieur, dommage).

          • [^] # Re: À jour ?

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

            merci TLS 1.2 et la non possibilité d'inciter à prendre un vieux protocole si au milieu).

            Ça c’est globalement faux. Il existe pas mal de moyen de contraindre un site à négocier une suite pétée à partir du moment où le serveur supporte une suite merdique.
            Tu peux très bien négocier du AES128-SHA voire du DES-CBC3-SHA alors que tu es bien en TLSv1.2 (cas de google.fr).

            • [^] # Re: À jour ?

              Posté par  (site web personnel) . Évalué à 0. Dernière modification le 19 juillet 2020 à 21:52.

              google.com a "Downgrade attack prevention: Yes, TLS_FALLBACK_SCSV supported" et rien de négatif sur SslLabs.
              Suffisant, pas suffisant, débat?

              • [^] # Re: À jour ?

                Posté par  (site web personnel) . Évalué à 7. Dernière modification le 19 juillet 2020 à 21:56.

                SCSV permet simplement de ne pas downgrade vers TLSv1.1 si le client et le serveur supportent TLSv1.2 (le serveur verra passer une demande en 1.1 avec le flag SCSV et va hurler).
                Ça ne permet pas de protéger d’un downgrade de (TLSv1.2) ECDHE-ECDSA-AES256-GCM-SHA384 vers (TLSv1.2) DES-CBC3-SHA qui est pété depuis 2016 et sweet32 si le site en face supporte les 2.

                En gros ça protège le protocole (TLSv1.2/1.1/1.0) et pas les ciphers suites (AES, 3DES, RC4…), il faut attendre TLSv1.3 pour corriger ça avec un handshake lui-même signé (en TLSv1.2 il ne l’est pas).

          • [^] # Re: À jour ?

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

            Mais sinon, oui ça a l'air de faire partie des sites "intégristes" qui ne regardent que si tu supportes un "mauvais" protocoles même si c'est pour supporter des vieux clients sans réduire la sécurité des nouveaux clients

            Le problème est que trop de sites se réfugient derrière cette pseudo-compatibilité pour ne pas faire évoluer leur sécurité. 3DES est pété depuis déjà 2016 (4 ans bordel…) et on le trouve encore sur les banques & le reste.
            Un navigateur qui ne supporte PAS TLS1.2 ou AES suppose que tu utilises un navigateur/OS type Android 4.3 (><) et moins ou Firefox 26 et moins. Des trucs de 2015 qui étaient DÉJÀ pétés en 2016 et la disparition de 3DES.

            Ces sites montrent bien un véritable problème de sécurité pour ne pas avoir fait les mises-à-jour nécessaires et mettre tous les autres utilisateurs (qui eux ont fait les mises-à-jours) en péril…

            • [^] # Re: À jour ?

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

              Comme tu pourras le voir ici, une suite de chiffrement permettant d’être A+ est compatible avec la quasi-totalité du monde à l’exception de IE6/XP, qui sont une hérésie en 2020 de toute façon.

              Une suite qui serait conforme avec le futur A+ (disparition de SHA-1) est conforme avec l’intégralité de la planète aussi, minus 2-3 trucs complètement obsolètes en 2020…

              • [^] # Re: À jour ?

                Posté par  (site web personnel) . Évalué à 6. Dernière modification le 19 juillet 2020 à 22:07.

                Un navigateur qui ne supporte PAS TLS1.2 ou AES suppose que tu utilises un navigateur/OS type Android 4.3

                […]

                Une suite qui serait conforme avec le futur A+ (disparition de SHA-1) est conforme avec l’intégralité de la planète aussi, minus 2-3 trucs complètement obsolètes en 2020…

                Moi-même petit fournisseur d'app Android, j'ai des utilisateurs qui râlent même en 2020 quand je casse la compatibilité Android 4.2 (en pratique stats d'hier : 0.2% d'Android avec version <=4.3), c'est une réalité quoi qu'on pense du niveau de sécurité qu'on veut, et il faut assumer les virer, pas se dire qu'ils n'existent pas (bon je vais sans doute tenter de virer ma compatibilité WinXP de mon plus gros logiciel, j'espère qu'en 2020 mes quelques râleurs de 2018 auront upgradé ou du moins seront assez minoritaires…).

                A noter que 0.2% ça peut être rien pour toi, mais pour un support client de millions de personnes, c'est de la thune à dépenser pour dire aux clients d'upgrader leur bousin ce qui peut assez mal passer. Tu ne peux pas ne pas faire la différence entre des entités qui gèrent TLS 1.3 avec CHACHA20 mais aussi TLS 1.1 et des entités qui gèrent que TLS 1.1.

                PS : pour le downgrade de suite de chiffrement, au temps pour moi, remplacer 1.2 par 1.3… Le besoin est donc surtout de gérer 1.3, et si je comprend bien alors 1.1 peut être encore gérer sans risque pour les clients 1.3. bon resterait les clients 1.2 vulnérable du coup, à méditer…

                • [^] # Re: À jour ?

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

                  A noter que 0.2% ça peut être rien pour toi, mais pour un support client de millions de personnes, c'est de la thune à dépenser pour dire aux clients d'upgrader leur bousin ce qui eut assez mal passer. Tu ne peux pas ne pas faire la différence entre des entités qui gèrent TLS 1.3 avec CHACHA20 mais aussi TLS 1.1 et des entités qui gèrent que TLS 1.1.

                  Axa ou N26 l’ont fait. Je ne vois du coup pas ce qu’il y a d’insurmontable.

                  https://cryptcheck.fr/https/connect.axa.fr

                  PS : pour le downgrade de suite de chiffrement, au temps pour moi, remplacer 1.2 par 1.3… Le besoin est donc surtout de gérer 1.3, et si je comprend bien alors 1.1 peut être encore gérer sans risque pour les clients 1.3.

                  Ils ont déjà du mal à supporter 1.2, alors 1.3, si on l’a d’ici 10 ans je serais étonné…

                  Et encore une fois, avoir du 1.3 & des trucs pétés dans la boucle, c’est s’ouvrir la porte à toutes les fenêtres. On ne peut/doit pas parier la sécurité de son bordel sur une conjonction improbable d’éléments divers et variés…
                  « Alors tu es safe si tu as du 1.3 ou du 1.2 avec du SCSV et je laisse des trucs pétés uniquement sur 1.1 en espérant que tu ne tomberas pas dessus par l’opération du saint-esprit »
                  D’autant plus que SCSV est présent dans le handshake non signé de TLSv1.2 donc en théorie est shootable par une attaque active du même niveau technique que le fallback de cipher.

                  • [^] # Re: À jour ?

                    Posté par  (site web personnel) . Évalué à 4. Dernière modification le 19 juillet 2020 à 22:14.

                    D’autant plus que SCSV est présent dans le handshake non signé de TLSv1.2 donc en théorie est shootable par une attaque active du même niveau technique que le fallback de cipher.

                    Je veux dire par là que SCSV protège uniquement des attaques (semi) passives consistant à bloquer la connection TCP à la détection d’une connexion TLSv1.2 en espérant que le client va retenter derrière en TLSv1.1.

                    À partir du moment où on considère un attaquant actif capable d’éditer le flux, alors il shootera SCSV de la même manière qu’il modifierait les paquets pour supprimer les ciphers safe et forcer une connection vers 3DES. Il lui suffit de supprimer le flag SCSV de la demande de connexion TLSv1.1. Le handshake n’étant pas signé…

                  • [^] # Re: À jour ?

                    Posté par  . Évalué à 4.

                    https://cryptcheck.fr/https/connect.axa.fr
                    donne exactement le même résultat que
                    https://cryptcheck.fr/https/axa.fr

                    Sauf que le premier est A+ et le second est E.
                    Quelle est la différence ?

                    • [^] # Re: À jour ?

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

                      Il est étonnant que "axa.fr" marche, il est indiqué en "Revoked" chez ssllabs. Et ça redirige sur www.axa.fr. ils ne sont pas parfait :) (ils ont l'air d'avoir un petit soucis HSTS aussi, que ssllabs n'aime pas).
                      La différence doit venir de la (essaye www.axa.fr qui n'a pas le soucis, mai https://cryptcheck.fr/https/www.axa.fr dit que c'est trop gentils car accepte les vieux trucs, comme quoi ils ne veulent pas virer tout le monde partout :) ).

                • [^] # Re: À jour ?

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

                  C'est marrant on en revient toujours au problème de la vente forcée de l'OS sur des matériels qui ne sont pas conçus pour être mis à jour, et dont le fabricant se fiche complètement du support.

                  Ici par exemple, le seul truc Android que j'ai est une tablette Polaroid de base, avec un 4.x dessus, qui n'est même plus référencée chez le fabricant.

                  Bon je ne m'en servais plus que pour Giggity, mais même les sites webs des conférences passent en HTTPS et donnent une erreur du coup…

                  Quant au banques, si au moins elles n'obligeaient pas à utiliser des applis merdiques et propriétaires pour le 2FA… Et encore ils n'ont pas osé à la CÉ (ils sont en retard mais bon, c'est pas nouveau).

                  • [^] # Re: À jour ?

                    Posté par  (site web personnel) . Évalué à 6. Dernière modification le 20 juillet 2020 à 11:31.

                    Quant au banques, si au moins elles n'obligeaient pas à utiliser des applis merdiques et propriétaires pour le 2FA… Et encore ils n'ont pas osé à la CÉ (ils sont en retard mais bon, c'est pas nouveau).

                    DSP2 impose(ra) forcément du « propriétaire » à ce niveau.
                    Plus exactement il impose une 2FA « contextuelle » pour éviter les man-in-the-middle. Ça suppose d’afficher des données supplémentaires à l’OTP pour que l’utilisateur puisse identifier de manière fiable le demandeur de l’OTP.

                    Dans le cas d’une validation de virement ou de paiement, c’est par exemple le montant de la transaction ainsi que son destinataire, pour éviter un attaquant qui ferait proxy et te débiterait le montant qu’il souhaite à son propre profit si on se limitait au seul OTP.

                    Dans celui de la connexion, ça pourrait être l’affichage d’un symbole spécifique connu uniquement de toi et de ta banque. Une banque belge dont j’ai perdu le nom avait implémenté ça dans un token OTP matériel d’ailleurs, mais je n’en retrouve plus la référence…

                    En pratique ça demande(ra) donc du développement spécifique à chaque banque et même si la théorie derrière est libre et commune (T-OTP), chaque banque risque d’avoir sa propre application ou fonctionnement pour couvrir ce besoin de « contextualisation ».

                    C’est même la raison n°1 de pourquoi les banques préfèrent encore violer la DSP-2 et ont demandé une rallonge de 2 ans pour continuer avec le SMS, elles n’ont actuellement pas de solution conforme à disposition.

                  • [^] # Re: À jour ?

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

                    Je crois que tu as contourné la mesure d'obsolescence programmée intégrée dans le port USB de la tablette en question. Faut pas se plaindre après si c'est plus maintenu :o)

        • [^] # Re: À jour ?

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

          https://cryptcheck.fr/https/cryptcheck.fr

          Certains y arrivent pourtant :)

        • [^] # Re: À jour ?

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

          Il donne la note la plus mauvaise, or 3DES est cassé.

          "La première sécurité est la liberté"

    • [^] # Re: À jour ?

      Posté par  (site web personnel) . Évalué à 3. Dernière modification le 19 juillet 2020 à 22:03.

      Bref, je pense pas que l'écosystème bancaire soit si catastrophique que dans ta banque.

      Il faudrait que je refasse tourner la moulinette, mais en mai 2019, c’était une grosse catastrophe…
      https://imirhil.fr/tls/banks.html

  • # CE et numérique

    Posté par  . Évalué à 2.

    Bonjour,

    Anecdote.
    Très tôt le matin d'un jour de mars 2017, je décide de consulter mon compte CE, via Firefox.
    Je charge le site de la CE, la fenêtre "Accès aux comptes" s'ouvre, je tape mon identifiant dans la case adéquate, je valide et la fenêtre d'accès au code confidentiel s'affiche. Je tape mon code et les petits points s'affichent.

    Comme je n'enregistre pas mes identifiants, s'ouvre la petite fenêtre de dialogue en proposant l'enregistrement. Dans cette fenêtre figurent deux cases, l'une pour l'identifiant, en clair, l'autre pour le code, avec des points à la place des chiffres.
    Et là, à la place de l'identifiant, Firefox affiche, en clair, donc, le code que j'avais entré dans la fenêtre d'accès aux comptes!
    Je refais la manip, je change de PC, je tente sur un smartphone, puis une tablette : tout pareil.
    Je passe sur Internet Exporer, je regarde sur d'autres sites bancaires : pas d'anomalie.
    Le défaut n'apparaissait qu'avec Firefox, et uniquement sur le site de la CE.

    J'imagine être dans un métro, vouloir (bien imprudemment, certes!) consulter mon compte sur mon smartphone. Et voilà que mon code s'affiche en clair alors que mon voisin de derrière, forcément au courant du bug, jette un coup d'oeil par dessus mon épaule?!?

    Je tente d'avertir le siège de la CE à Paris, mais à 7:30, personne au bout du fil ne semble concerné. Je passe à mon agence: cela ne peut pas venir de la CE, c'est mon PC qui a un défaut, bien sûr, où avais-je la tête! Je tente de joindre le service technique compétent à la CE, mais il était fermé. J'envoie un mail à ma conseillère financière: aucune réponse. Je tente d'autres agences, d'autres régions: aucun résultat.

    Le défaut disparaîtra des mois(!) plus tard…

Suivre le flux des commentaires

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