POODLE, Heartbleed... et quoi d'autre ?

Les banques se targuent d'être sûres et d'offrir "le meilleur" au niveau sécurité à leurs clients. Mais que vaut réellement la connexion entre vous et eux ? Votre banque est-elle une "Banquignole"?

    Informations

    Suite à une mise à jour importante de SSLyze, librairie employée par notre script, nous devons suspendre les mises à jour automatiques pour modifier l'application — certaines sorties ne sont plus correctement prises en compte.

    Les tests ne se font que sur la connexion aux sites, en aucun cas sur la partie applicative. Le site comporte banques (dernière mise à jour: ).
    La note moyenne est de (site) et (e-banking).
    Le maximum possible est de .

    Une mauvaise note ne veut pas dire que les données sont en accès libre !

    Du moment qu'une connexion SSL/TLS existe et est employée, les données en transit sont chiffrées. Le cassage du chiffrement (décryptage) demande des efforts (temps machine), et coûte en ressources.
    Si le chiffrement est réputé faible, cela demandera "moins" de temps machine pour le casser. Mais cela reste hors de portée de votre voisin ou même d'un hacker.

    Les résultats vous inquiètent ?

    Ne paniquez pas ! Ou du moins pas de suite. Signalez simplement à votre banque que la connexion n'offre pas toutes les garanties de confidentialité. Certaines réagissent favorablement, et prennent des mesures correctrices — la votre en fait peut-être partie.

    Comment ça marche ?

    Basé sur SSLyze, un script récupère les capacités de connexion des différents sites, analyse le tout, et procède à une notation. Le détail des notes est visible en cliquant le "+" en bas de chaque résultat.

    Vous ne trouvez pas votre banque ?

    Plusieurs raisons sont possibles : soit la banque utilise une application dédiée pour la partie e-banking, auquel cas nous ne pouvons pas tester la partie serveur (authentification par certificat SSL, difficulter à trouver l'adresse, etc), soit nous ne sommes pas tombés sur cette banque lors de nos recherches.
    Dans le second cas, vous pouvez nous envoyer un mail, nous verrons pour ajouter la banque.

    Pourquoi des fluctuations dans les nodes depuis le lancement ?

    Le dernier système mis en place était trop dur, et ne tenait pas compte d'une chose importante dans le processus de connexion SSL/TLS : l'ordre des ciphers (algorithmes de chiffrement) proposé par le serveur distant.
    Un débat a eu lieu, remettant en cause la manière de calculer le tout.
    De manière à simplifier et rendre les choses plus compréhensibles, certains points ont été écartés (localisation géographique des serveurs par exemple), d'autres ont été ajoutés (OCSP Stapling par exemple).
    Pour la partie la plus controversée (ciphers), on s'est basé sur les préférés, de manière à prendre en compte ce que le serveur demande avant tout.

    Détail de la notation

    • Certificat (commonName) : contrôle si le certificat correspond au nom de domaine.
    • Certificat (échéance) : contrôle si le certificat est encore valide.
    • Ciphers : contrôle les ciphers présents et employés.
    • Flash : contrôle la présence du plugin Flash d'Adobe, réputé pour ses failles de sécurité
    • Frame : contrôle si le site utilise des frames et si elles sont protégées correctement.
    • HSTS : contrôle la présence de l'en-tête HSTS.
    • OCSP stapling : contrôle si le serveur met en cache les résultats OCSP pour les servir aux visiteurs (plus de détails).
    • Protocoles : contrôle que les derniers protocoles sont biens activés (conseillé : TLSv1, TLSv1.1, TLSv1.2).
    • Redirection SSL : contrôle si le site force le SSL.
    • Signature : contrôle l'algorithme de signature du certificat (conseillé : SHA256).
    • Taille de la clef : contrôle la taille de la clef associée au certificat (minimum conseillé : 2048b).
    • Trackers : contrôle la présence d'outils de métriques externes.