Banquignols — Test de connexion SSL

Par SwissTengu @SwissTengu @SwissTengu — 04.02.2015
EthACK vient de lancer l'application Banquignols1. Le but est de tester et noter la qualité des connexions offertes par différentes banques en Suisse (environ 180).

L'application prend en compte les protocoles offerts, ainsi que les algorithmes de chiffrement supportés, en plus de quelques autres critères. Notre objectif est d'attirer l'attention du public sur le fait que les banques, censées être garantes du secret de vos avoirs, ne semblent pas toutes faire le maximum pour assurer une connexion sécurisée au plus près des bonnes pratiques actuelles.

Attention cependant : une mauvaise note ne veut pas dire que vos données sont accessibles par tout le monde, loin de là : du moment qu'une connexion SSL/TLS est présente, cela signifie que le contenu de vos interactions avec le site est chiffré.
Du coup, ce n'est pas votre voisin qui pourra savoir combien vous gagnez. Par contre, si le chiffrement est faible, ça peut être à la portée d'un état.

Aussi, l'application ne fait aucun test d'intrusion ou de recherche de failles au niveau des applications ­— les implications légales sont trop importantes pour qu'on se permette de faire cela sans un minimum de préparation, de prise de contact et, surtout, d'acceptation de la part des entités testées.
Du coup, la BCGE, qui pourtant a eu une fuite de données non négligeable, s'en sort avec une note potable.

Ce qui est inquiétant : la moyenne, à l'heure actuelle, n'est que de 7.70 sur 10 pour les sites de e-banking. Elle devrait être d'au moins 8.5 voire 9, sachant que, sur un plan purement technique, le 9 est "facilement" accessible. Le 10, par contre, avec notre barème, est peu probable à l'heure actuelle (un peu de challenge ne fait pas de mal ;) ).

Si vous vous sentez concernés par la sécurité qu'offre votre banque, et que la note vous inquiète, n'hésitez pas à la contacter. Nous avons approché une des banques présentes dans le listing qui présentait une note particulièrement basse, et, en suivant nos indications et en profitant de nos actions pour accélérer des procédures, la banque en question a pu remonter sa note de quelques points.

Pas toutes les banques vont réagir comme celle-ci — mais si un certain nombre de demandes arrivent, peut-être que ça les fera bouger.

Encore une fois, la sécurité n'est pas en cause (du moins, on ne peut pas s'en rendre réellement compte avec nos tests), il s'agit avant tout d'une question de principe : offrir au client le top au niveau confidentialité de sa connexion.

Dans l'idéal, voici ce qu'une banque devrait fournir :
  • connexion sécurisée sur l'ensemble du site, pas que le e-banking
  • forcer la connexion sécurisée
  • désactiver les protocoles SSLv2 et v3, et ne laisser que TLSv1, v1.1 et v1.2
  • avoir une clef privée dont la taille est au minimum de 2048 bits
  • employer un algorithme de signature SHA2 au lieu de SHA1
  • offrir une majorité de ciphers (algorithmes de chiffrement) fournissant la confidentialité persistente
  • désactiver les ciphers réputés peu sûrs (il y en a un wagon)
  • ordonner correctement les ciphers, et forcer l'ordre du serveur (ce point n'est pas testé)

En plus, s'agissant d'une banque, les données et points d'accès devraient être en Suisse.

Au final, ce n'est pas compliqué. Certaines banques laissent SSLv3 activé parce qu'elles ont remarqué qu'elles ont une majorité de clients avec des vieux navigateurs. Il faut savoir que ces personnes tournent avec un Internet Explorer 6 sur du Windows XP en général, et que le combo IE6/XP ne sont plus du tout supportés… Du coup, leur système n'est pas à jour, et possède sans nul doute des failles importantes.
On peut donc se demander si ça ne rendrait pas service à ces personnes de se retrouver bloquer, et obligées à mettre à jour leur machine. Pas forcément avec du Windows, en passant ;).

Concernant l'application elle-même, le code source est ouvert et est hébergé sur github2. Si vous pensez que certains tests peuvent être ajoutés, ou que vous voulez l'employer pour votre propre compte, ne vous gênez surtout pas ;).

Nous espérons que ce site éveillera les consciences, et forcera les banques à réagir comme celle que nous avons contactée : appliquer des correctifs (et nous rencontrer pour discuter sécurité et protection des données).

Nous tenons encore à le répéter : les tests ne sont en aucun cas intrusifs. Il s'agit d'une "prise d'empreinte", complètement passive, et ne diffère pas trop d'une utilisation standard des sites.


Commentaires (23)

par napster2core — 06.02.2015, 08:15 — PermaLink
Tiens, un article exactement sur le même sujet (sécurité SSL), mais là appliqué au méthodes de la NSA:
http://linuxfr.org/news/nsa-a-...

Ça peut pas faire de mal, et il y a peut-être des techniques pas testées par le script de banquignols.
par SwissTengu — 06.02.2015, 12:49 — PermaLink
Les tests sont déjà pas mal étendus — moins précis que ceux de Qualys certes, mais, pour un script fait en vitesse, il ne s'en sort pas si mal. Et les résultats sont déjà assez désastreux comme ça pour les sites testés.

Parmi les trucs qu'on pourrait ajouter, il y a effectivement deux points : la compression (CRIME) et l'ordre des ciphers.
On a déjà renforcé les contrôles et, surtout, exploité plus en avant les informations qu'on récoltait (d'où une sacrée dégringolade des notes ce matin).

Par contre, il est fort probable que Banquignols soit repris dans le cadre d'un projet "un peu" plus gros, avec un nouveau code (modulaire, threadé, etc), meilleurs tests etc. Plus à venir prochainement si tout va bien :).

Là, c'était le tour de chauffe. Les banques ne sont de loin pas les seules entités qu'on vise, au contraire… Cette année pourrait bien faire un peu de bruit à ce niveau en Suisse.
par Crigou — 07.02.2015, 19:52 — PermaLink
Madame, Monsieur.
Sur votre site Ethack, je n'arrive pas à accéder aux tests de connexion SSL. Mon navigateur est IE11 sous Win 8.1. Pourriez-vous m'aider svp ? Christian Weber.
par Alex — 08.02.2015, 09:35 — PermaLink
Dommage d'avoir écrit tout un script (en perl - argh!) alors que sslyze (https://github.com/nabla-c0d3/...) fait la même chose d'une manière plus modulaire (et probablement mieux).
par Crigou — 08.02.2015, 10:39 — PermaLink
Un grand merci à l'administrateur d'avoir promptement répondu (par courriel) à ma question ci-dessus: utiliser plutôt Firefox. Résultat des courses: je peux accéder aux tests de connexion SSL aussi bien en FF qu'en IE.
par Alex — 08.02.2015, 16:38 — PermaLink
Je viens de passer un bon moment à essayer de reproduire ces résultats afin de voir si effectivement les banques suisses si mauvaises que cela (je vous épargne toute la liste des problèmes rencontrés suite des dépendances en cascade et les problèmes avec des libraires à jour). Ma conclusion est que la distribution des points actuelle est peu réaliste et trompeuse. L’écho de certains médias quant à ce texte est exagéré et sous-estime le niveau actuel de "sécurité". Voici 3 exemples de limitations flagrantes (je vais éviter de dire "mensonges"...):
- L’ordre des ciphers proposés par le serveur est essentiel quant à la sécurité d’une communication. Et pourtant c’est l’un des points manquant de ce test. Faire des calculs de ratio entre le nombre de ciphers offrant des propriétés de Perfect Forward Secrecy (PFS) versus les ciphers standards est tout simplement ridicule et trompeur, car c’est l’ordre des ciphers plutôt que leur nombre qui prime. Mieux vaut avoir 75% de choix de ciphers sans PFS, mais avoir les 25% avec PFS en premier dans la liste. Ce paramètre fait que certains services se retrouvent avec -1.5 points au lieu de +2 points, ce qui fausse toute objectivité du test (variation possible de 35% de la note).
- Si la clé publique du serveur n'est pas de 4096 bits, une pénalité de -0.5 est appliquée. Aucune autorité de certification sérieuse (je ne considère pas StartCom comme étant une CA sérieuse) ne vend de telles certificats, car ceux à 2048 bits sont jugés suffisants pour les 3 ans maximum qu’ils ont à servir. Utiliser des certificats de 4096 bits au lieu de 2048 demande 6 à 8 fois plus de calculs pour un gain de sécurité jugé actuellement nul.
- Le lieu d'hébergement du serveur peut influencer 40% de la note - +2 si en Suisse, -1 au USA/UK. Les autres pays sont notés +1 (y.c. Canada, Australie et Nouvelle-Zélande, pourtant aussi membre des Five Eyes...), heureusement pour les auteurs du test car sinon ethack.org aurait un rating de 4.5 au lieu de 6.5 vu que c'est hébergé en Allemagne. Le lieu d’hébergement n’a strictement rien à voir avec le titre de "Test de connexion SSL".

Pour conclure, voici les résultats de quelques autres sites testés avec le même script. Google et Twitter ont été choisis car ils sont à l’avant-garde en ce qui concerne les efforts de protection de la confidentialité (ce qui ne veut pas forcément dire de vie privée...) de leurs utilisateurs sur Internet :
- 1.5 points pour api.twitter.com (1 pfs, -0.5 ciphers, 1 ssl, 2 protocols, -1 pays, -1 certificat)
- 3 points pour www.twitter.com (1 pfs, -0.5 ciphers, 2 ssl, 2 protocols, -1 pays, -0.5 certificat)
- 1.5 points pour accounts.google.com et www.google.com (1 pfs, -1.5 ciphers, 2 ssl, 2 protocols, -1 pays, -1 certificat)

Les guignols dans cette affaires ne sont pas les banques, mais ceux qui publient ou croient à des tests peu fiables (pour ne pas dire trompeurs). Pour ceux qui sont réellement soucieux de la sécurité de leur banque, utilisez https://www.ssllabs.com/ssltes... ou téléchargez sslyze (https://github.com/nabla-c0d3/...) et faites-vous votre propre idée.
par Crigou — 09.02.2015, 08:55 — PermaLink
Merci à Alex pour le lien
https://www.ssllabs.com/ssltes...
vers un autre test en ligne, avec lequel je me suis amusé à tester 2 domaines clairement départagés par SwissTengu, Postfinance étant mieux coté que la banque Coop par exemple. Il apparaît ainsi les scores suivants:
A pour postfinance.ch
B pour bankcoop.ch
À moins que je me trompe, il ne faudrait donc pas jeter le bébé avec l'eau du bain.
par Alex — 09.02.2015, 21:09 — PermaLink
L'idée de base est en effet bonne, ce que je reproche surtout est l'instrumentalisation des résultats, par exemple quand je lis dans le Temps que - je cite Cédric Jeanneret - "[...] jusqu’à ce qu’une prise de conscience s’installe et que les banques prennent des mesures correctives". Ou encore quand magiquement les résultats empirent en l'espace de 2 jours car - je cite à nouveau: "Je me suis contenté d’exploiter plus en détail les données recueillies".

Non justement, ces interprétations sont fausses et si un professionnel tels que SSLLab donne une note de A ou B à Postfinance ou Coop, cela montre qu'ils sont plus haut que que le test tente de suggérer (cf la citation dans l'article comme "globalement mauvais"). Comme je l'ai démontré plus haut, jusqu'à 75% de la note peut dépendre de critères faux ou non liés à SSL (ciphers et pays d'hébergement). De plus la citation "En revanche, un hacker ou un connaisseur avec quelques ressources adéquates n’aura aucune peine à le faire." est ridicule car de telles attaques restent très compliquées et avec une liste de prérequis conséquente.

Je ne nie pas que certaines banques sont plus mauvaises que d'autres, mais pour pouvoir faire pression il faut utiliser des faits basés sur d'autres moyens de mesures, une autre notation et éviter les approximations / semis vérités du test actuel.

Pour conclure, voici quelques exemples pour montrer ce décalage:
- banking.vadianbank.ch - score à 1 pour ce test, B selon SSLLab
- accounts.google.com - score à 1.5 pour ce test, B selon SSLLab

Une mesure honnête serait de reconnaître son erreur et revenir au système de notation d'avant le 6 févier qui me semble être plus objectif et qui donne une image plus fidèle de la réalité.
par SwissTengu — 10.02.2015, 10:02 — PermaLink
On s'absente 2-3 jours et y a le feu on dirait ;).

Reprenons dans l'ordre :

On n'était pas tombé sur sslyze — on va voir comment il marche, comment il compte etc. On avait eu d'autres scripts du genre, mais pas vraiment pratiques…

VeriSign et d'autres supportent des certificats à 4096b.
Le problème : on pense "maintenant, 2048 c'est suffisant, et pour 3 ans c'est OK". C'est là une erreur de jugement : les techno évoluent, la puissance de calcul tout autant. Des transmissions enregistrées maintenant sont conservées pour usage ultérieur, par exemple pour casser le chiffrement quand la techno/puissance sera présente.
Passer à des tailles de 4096b, c'est aussi un gage de protection à plus long terme dans ce cas précis.
Le "sérieux" de StartSSL est une appréciation personnelle — pour notre usage "ils sont OK", dans le sens qu'on a une connexion SSL/TLS reconnue par une majorité de navigateurs à un prix correct (voire, pour être franc, "normal" compte tenu de ce qu'est le job d'une CA).
Nous n'avons pas d'utilité supplémentaire, ni besoin d'autres garanties ;).

Le lieu d'hébergement influence aussi la confiance que l'on peut avoir dans une connexion : si le réseau entre nous et le serveur est sous contrôle étranger, disons US, on est en droit de se poser quelques questions vis-à-vis de l'enregistrement des connexions et des tentatives d'attaques par des entités aussi diverses que variées.
Ce n'est pas comme si les banques suisses n'avaient aucun problème… Si des données arrivent à être récupérées, ils ne vont pas se gêner.
Du coup, oui, des points sont décomptés (bonne remarque pour le Canada, l'Australie et Nouvelle-Zélande, encore que ces pays ne soient pas représentés dans les tests actuels).
On peut argumenter pour savoir si la France, l'Allemagne, l'Italie ou encore le Liechtenstein sont plus "de confiance". Débat ouvert à mon niveau.

L'ordre des ciphers : OUI. Clairement, c'est à prendre en compte, sur deux plans:
- le serveur doit forcer son ordre
- l'ordre doit présenter les plus costauds avant.
C'est une limitation non-négligeable, on en est conscient. Mais le "on" s'arrête à une seule personne…

Les notes : globalement, oui, c'est mauvais. Désolé, mais sur ce point, on ne va pas changer. Postfinance s'en sort bien avec un 8, qui la démarque positivement, au même titre qu'elle a un A par Qualys. La Banque Coop (5.5 selon le script) s'en sort pas trop mal, et le B de Qualys semble effectivement le valider, tout comme cela indiquerait que le script "rate" deux points si on fixe le A de Postfinance à 10 (encore qu'il y a le A+…).

La modification du 6 février est due principalement à une autre personne ayant argumenté que nous étions, a contrario, trop laxistes par rapport à la présence de quelques ciphers désuets (DES/RC4), ainsi qu'au niveau du comptage des points pour le PFS ou encore les algorithmes de signature (SHA1 vs SHA2).
La correction était peut-être trop drastique, à voir les réactions (justifiées sur le fond) d'Alex.

Du coup :
- Le script est "dur", c'est un fait. Mais cela a permis à une banque au moins de secouer leur infra et de faire accélérer des processus déjà lancés (on ne peut pas communiquer le nom pour le moment, désolé). Et ça, c'est une bonne chose.

- Le script est imparfait : c'est aussi un fait. Des patches peuvent être soumis, ou des améliorations proposées.

- Nous allons regarder du côté de sslyze, selon comment il remplacera le script, si tant est qu'il comble les lacunes actuelles sans en rajouter ailleurs.

<chapeau=SwissTengu>
Ah, aussi : les articles du Temps ont été faits à mon insu… Du coup, les citations n'engagent que les auteurs des articles. Aussi, d'où sort cette citation :
En revanche, un hacker ou un connaisseur avec quelques ressources adéquates n’aura aucune peine à le faire.

Il ne me semble pas avoir parlé d'un hacker ou connaisseur, mais plus d'un État… Le temps machine nécessaire pour péter le chiffrement (ou "simplement" le stockage et les points d'accès pour sniffer le tout) dépasse de loin le budget et les capacités du quidam moyen, et j'ai lourdement insisté sur ce point à chaque fois que j'avais mon mot à dire.
Du coup… source ?
</chapeau>

Voilà. Un article sortira le moment venu concernant les corrections et la ré-appréciation des notes. En attendant, ça reste dans l'état
par Crigou — 10.02.2015, 12:49 — PermaLink
Que SwissTengu se soit mis en relation avec une certaine banque est une excellente initiative. Le but des tests SSL est en effet d'améliorer sans relâche la sécurité informatique des instituts financiers.
par SwissTengu — 10.02.2015, 15:28 — PermaLink
@Alex : merci pour le sslyze, il va être intégré pour remplacer une série de tests, le temps de mieux maîtriser son fonctionnement. L'output XML est fort pratique, et pourra être reprise directement.
On va aussi voir comment "normaliser" la liste des sites de manière à profiter au mieux du multi-threading proposé par sslyze, ça permettra d'accélérer les choses (et, pourquoi pas, de proposer une mise à jour plus fréquente).

T.
par Alex — 11.02.2015, 06:17 — PermaLink
Ravis qu'au moins une partie du feedback ait été pris en compte (cf sslyze).

> Il ne me semble pas avoir parlé d'un hacker ou connaisseur, mais plus d'un État… Le temps machine nécessaire pour péter le chiffrement (ou "simplement" le stockage et les points d'accès pour sniffer le tout) dépasse de loin le budget et les capacités du quidam moyen, et j'ai lourdement insisté sur ce point à chaque fois que j'avais mon mot à dire.
> Du coup… source ?

Extrait de http://www.letemps.ch/Page/Uui... (paywall - accessible uniquement avec enregistrement préalable):
L’application Banquignols réévalue tous les deux jours la qualité des sites de 186 enseignes. De «globalement mauvaises», les moyennes passent à «inquiétantes»
[...]
On reprend les mêmes et on recommence. Mercredi, Cédric Jeanneret, membre du Parti pirate vaudois, a publié un test de la qualité des sites web et des portails e-banking de 186 banques en Suisse. Grâce à une application baptisée «Banquignols» , il a réitéré l’exercice vendredi. Mais en poussant un peu plus la contrainte en ligne. Constat: les performances web des établissements se sont sérieusement détériorées.

«Je compte poursuivre l’expérience tous les deux jours, jusqu’à ce qu’une prise de conscience s’installe et que les banques prennent des mesures correctives», résume l’évaluateur.
[...]
Quarante-huit heures plus tard, le bilan s’est aggravé. La moyenne nationale des sites bancaires n’était plus que de 2,58/10. Avec un festival de notes négatives, les plus mauvaises élèves étant Royal Bank of Scotland, Royal Bank of Canada (–3,5/10 chacune) et HSBC (–4,5/10). Côté e-banking, les résultats généraux ont chuté à 4,69/10. Le recul collectif – toutes plateformes confondues – est ainsi d’environ trois points.

Toutes les banques testées y ont perdu des plumes. Même celles qui s’étaient distinguées mercredi, comme UBS ou PostFinance, avec des notes de 9/10 et de 8/10, réduites à 8/10 et 5,5/10.
[...]
«Cette expérience démontre que votre voisin ne parviendra pas à casser vos données ou sniffer vos connexions avec votre banque. En revanche, un hacker ou un connaisseur avec quelques ressources adéquates n’aura aucune peine à le faire», prévient Cédric Jeanneret. Et l’expert de conclure: «Le risque immédiat est que des services gouvernementaux, comme ceux des Etats-Unis, profitent de ces failles pour puiser des données de clients bancaires en Suisse.»
[...]

=> L'article crie clairement au loup alors que rien ne s'est passé entre les deux jours, mis à part l'introduction d'un nouveau système de notation contestable. Et l'article ne laisse aucun doute que la citation de mon précédent commentaire est attribué à Cédric Jeanneret:

En attendant, sslyze donne l'ordre des ciphers du serveur et devrait permettre de corriger le bias le plus important de ce test (qui, je le rappelle, peut faire varier une note de 35% et ce sans fondement technique). Et sslyze donne également d'autres points oubliés, tels que la compression, la possibilité de renegociation de session non sécurisée initiée par le client, le stapling OCSP (qui a des propriétés TRES intéressantes au niveau vie privée et performance) etc.

Je répondrai aux autres points dès que j'ai le temps de retrouver quelques références (notamment les clés 2048 bits).
par SwissTengu — 11.02.2015, 07:20 — PermaLink
Je suis tombé sur l'article en fouillant. La dernière citation est sortie du contexte et modifiée… M'enfin classique :(.
Vais voir si l'auteur peut la reformuler pour coller à mes propos — qui sont les mêmes que dans l'article que nous commentons : un particulier ne peut pas (sauf pour jouer et s'il a du temps à perdre… beaucoup de temps), par contre un état, c'est autre chose.

Le "inquiétant" n'est pas de moi.

Aussi, une mention en gras a été ajoutée sur la page de banquignols concernant la portée des tests — à voir, il y a aussi une incompréhension, pourtant pas faute d'avoir insisté (aussi ici), à moins que certains ne répondent à côté exprès (ce qui reste possible).

Au fait, seriez-vous partant pour participer à l'élaboration d'un barème ?
par Crigou — 11.02.2015, 20:52 — PermaLink
Pour établir un barème, je suggère que le développeur du test parte d'un barème existant, par exemple (SSL Labs, page 5, Scoring):
https://www.ssllabs.com/downlo...
pour ensuite le modifier, voire l'adapter aux spécificités bancaires suisses.
par Crigou — 12.02.2015, 22:47 — PermaLink
Bien jolis, tous ces tests SSL sur serveur. Mais avec ça, il ne faut pas oublier de taquiner un tantinet le navigateur du client:
https://www.ssllabs.com/index....
ce que j'ai fait avec IE: erreur due à SSLv3 (vulnérabilité à Poodle), et corrigée en désactivant l'option SSLv3.
Par contre, avec Safari / iOS, aucune possibilité de déconnecter SSLv3. So bad.
par Alex — 14.02.2015, 14:12 — PermaLink
Voici quelques réponses concernant certains points erronés mentionnés plus haut. Je n'ai finalement pas pris le temps de sourcer chaque affirmation, mais si on est vraiment pas d'accord je prendrai le temps...

> Le problème : on pense "maintenant, 2048 c'est suffisant, et pour 3 ans c'est OK". C'est là une erreur de jugement : les techno évoluent, la puissance de calcul tout autant.

Faux, la communauté cryptographique estime qu'actuellement l'état de l'art pour factoriser une clé RSA reste sous 1024 bits, probablement autour de 800 ou 900 bits. Les avancées dans ce domaine sont influencés par des avancées mathématiques autour de la factorisation des nombres premiers qui, historiquement, se font avec des étapes de 100 à 200 bits. L'influence de la loi de Moore sur ce domaine est minimale.


> Des transmissions enregistrées maintenant sont conservées pour usage ultérieur, par exemple pour casser le chiffrement quand la techno/puissance sera présente.

Faux, le certificat n'est plus qu'utilisé pour garantir l'authenticité du serveur. La propriété de Perfect Forward Secrecy s'assure que des communications SSL/TLS capturées aujourd'hui ne pourront pas être déchiffré une fois le certificat compromis (ou cassé).


> Passer à des tailles de 4096b, c'est aussi un gage de protection à plus long terme dans ce cas précis.

Sommes-nous d'accord pour dire que casser une clés 2048 n'est pas juste 2x plus difficile qu'une clé 1024? Il est clair que plus est mieux, mais cela n'apporte rien dans ce cas précis dans un horizon-temps de quelques années.


> Le "sérieux" de StartSSL est une appréciation personnelle — pour notre usage "ils sont OK", dans le sens qu'on a une connexion SSL/TLS reconnue par une majorité de navigateurs à un prix correct (voire, pour être franc, "normal" compte tenu de ce qu'est le job d'une CA).

A quoi sert un certificat 4096 bits s'il est signé par une CA intermédiaire avec une clé de 2048 bits (comme c'est le cas de StartSSL)? A rien, car un attaquant dans ce cas va casser la clé de la CA intermédiaire...


> Le lieu d'hébergement influence aussi la confiance que l'on peut avoir dans une connexion [...]

Quel est le but de ce classement? Une évaluation technique ou un classement politique? Le lieu d'hébergement ne peut pas être un critère s'il s'agit d'un classement basé sur la technique.


> Mais le "on" s'arrête à une seule personne…
ET
> On va aussi voir comment "normaliser" la liste des sites de manière à profiter au mieux du multi-threading proposé par sslyze, ça permettra d'accélérer les choses (et, pourquoi pas, de proposer une mise à jour plus fréquente).

Ecrire des modules en Python pour SSLyze pour replacer un script Perl de 1000 lignes me semble être une bonne idée pour éventuellement permettre une meilleure participation au projet. Mais là c'est une appréciation très personnelle...


> Au fait, seriez-vous partant pour participer à l'élaboration d'un barème ?

Cf ma remarque d'avant: un barème avec quelles bases d'évaluation? Des appréciations politiques ou uniquement des faits techniques?
par SwissTengu — 15.02.2015, 16:59 — PermaLink
Le système d'évaluation a été revu, et clarifié sur le site.

Le barème se base uniquement sur des points techniques (exit donc le pays), et prend en compte le fait que le serveur demande certains ciphers en premier plutôt que d'autres.
Les notes négatives ont été supprimées — les moyennes globales s'en retrouvent donc un peu augmentées.

De manière générale, on retrouve plus ou moins les mêmes résultats d'avant le 6 février. Les notes sont cependant sur 12 points, parce que certains points ont été contrôlés en plus (OSCP Stapling par exemple (oui, ethack ne l'a pas, on va voir pour l'activer)).
Les points nous semblent un peu mieux distribués/attribués. On garde une déduction de point si SSLv2 et SSLv3 sont activés ­— cela semble normal.

Du coup, si vous avez des idées/remarques sur le décompte, n'hésitez pas — mais on est assez confiant quant à la qualité de cette version-ci.
Le détail de la note est décrit précisément, pour plus de transparence et clarté.

Par contre, on garde Perl ;).
par Alex — 15.02.2015, 19:42 — PermaLink
> De manière générale, on retrouve plus ou moins les mêmes résultats d'avant le 6 février. Les notes sont cependant sur 12 points, parce que certains points ont été contrôlés en plus (OSCP Stapling par exemple (oui, ethack ne l'a pas, on va voir pour l'activer)).

Merci pour la mise à jour - un rapide coup d'oeil sur les résultats me semble que cela reflète assez bien la situation actuelle: certains sont bons, d'autres peuvent faire des efforts, mais on n'est globablement pas dans une situation mauvaise. La sécurité de SSL/TLS a été pendant de nombreuses années un point considéré comme "aquis". Ce n'est que depuis 1 à 2 ans que les nouvelles attaques et de nouvelles contre-mesures sont développées, avec un rythme d'innovation bien plus important qu'avant. J'ai malgré tout encore quelques points :)

Au niveau des notes globales:
Un point à ne pas oublier est que la configuration du serveur est une chose, mais que le choix du client fait beaucoup également. Bien entendu que HSTS est très utile, mais Internet Explorer ne le supporte pas encore (IE 12 comprendra cet entête HTTP). Oui la version de Flash fournie par Adobe a régulièrement des bugs de sécurité, mais la version fournie avec Chrome (et bientôt Firefox) est moins vulnérable. Oui avoir SSLv2 ou SSLv3 activé peut permettre certaines attaques, mais pour cela il faut utiliser un vieux système d'exploitation et/ou navigateur. Certains sites vont considérer qu'il est mieux de permettre à des clients non supportés de se connecter - par exemple en lecture seule - plutôt que de leur refuser totalement l'accès.


Lu sur https://banquignols.ethack.org...
> OCSP stapling : contrôle si le serveur répond aux requêtes OCSP.

Ce n'est pas tout à fait juste: dans le cas de l'OCSP stapling, une réponse OCSP, mise en "cache" par le serveur lui-même, est fournie directement au navigateur lors de la connexion initiale au serveur. Cela évite que le navigateur doive lui-même faire la vérification OCSP, étape qui nécessite du temps et compromet sa vie privée (un serveur OCSP sachant quelle adresse IP ayant consulté quels sites). On pourrait d'ailleurs rajoutés des tests pour savoir si les certificats délivrés contiennent bien un point de vérification CRL et OCSP. Mais cela reste assez aléatoires, comme démontré par Netcraft il y a quelques temps (cf http://news.netcraft.com/archi... et les autres articles à ce propos sur le même blog).


> On garde une déduction de point si SSLv2 et SSLv3 sont activés ­— cela semble normal.
ET
> Du coup, si vous avez des idées/remarques sur le décompte, n'hésitez pas

Un autre critère potentiellement intéressant - notamment pour les sites ayant encore SSLv3 actif - est le TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks. Même s'il s'agit que d'un draft datant de 2014 de IETF (https://tools.ietf.org/html/dr...), ce méchanisme est déjà bien implémenté que ce soit côté client (au moins Chrome et Firefox) et serveur (OpenSSL dès version 1.0.1j, 1.0.0o et 0.9.8zc), notamment grâce aux efforts de quelques employés de Google. Les tentatives de "TLS downgrad attack" sont impossibles si SCSV est actif côté serveur et que le navigateur supporte cette fonction. Cela veut dire que les banques qui ont actuellement encore SSLv3 mais également SCSV ne méritent pas la déduction de 0.5 point actuellement effectuée.

Un autre point: le commonName d'un certificat n'est pas le seul champ dans lequel le nom de domaine peut être défini (cf https://github.com/EthACKdotOr...). Il est également nécessaire de vérifier que le nom ne soit pas parmi les divers SANs (subject alternative names). Donc UBS avec ebanking-ch2.ubs.com devrait gagner au moins 1 point car vous n'avez pas une erreur de certificat lorsque vous vous y connectez, non?

Autres remarques en vrac:
- Les résultats pour la partie publique de Credit Suisse sont fausses - bug lors du parsing ou lors des interrogations?
- Le script de détection des ciphers PFS me semble encore contenir des erreurs. Pourquoi AEK BANK 1826 Genossenschaft reçoit 3 points pour ses ciphers sur le site public, et uniquement 1.5 sur l'ebanking? Les deux sites proposent des ciphers PFS - l'un se basant sur les courbes elliptiques et un autre sur l'état de l'art des ciphers TLSv1.2.
par SwissTengu — 16.02.2015, 05:59 — PermaLink
J'ai malgré tout encore quelques points :

Comme dit, c'est ouvert ;).

HSTS est très utile, mais Internet Explorer ne le supporte pas encore (IE 12 comprendra cet entête HTTP)

Donc vaudrait mieux n'attribuer qu'un demi point, à cause d'un navigateur pourri ? Mouech… Le nivellement par le bas n'est pas forcément une chose qu'on pratique…

Certains sites vont considérer qu'il est mieux de permettre à des clients non supportés de se connecter

Certes, c'est le cas de l'UBS par exemple — on aurait moyeu de tester le résultat d'une tentative de connexion avec SSLv3, mais ce n'est de loin pas trivial (pour ne pas dire propre à chaque site…).
Là encore, c'est un peu du nivellement par le bas — les machins ne supportant pas plus haut que SSLv3, c'est du IE6 sur XP. Les deux dépréciés de longue date…

Ce n'est pas tout à fait juste: dans le cas de l'OCSP stapling, une réponse OCSP, mise en "cache" par le serveur lui-même

On ne voyait pas comment formuler la chose — on va revoir ça.

le TLS Fallback Signaling Cipher Suite Value (SCSV)

Effectivement — on va voir si SSLyze en tient compte/si l'info est présente dans leur xml. Si non, faudra qu'on trouve un moyen de tester ça. Qui sait, ça donnera peut-être un module SSLyze (oui, on parle aussi python) ;).

le commonName d'un certificat n'est pas le seul champ dans lequel le nom de domaine peut être défini

erk… oui, juste. On va reprendre le bout de SSLyze qui se charge très bien de valider ceci — correction à venir dans quelques minutes.

Les résultats pour la partie publique de Credit Suisse sont faux

heuuu… intéressant. On va sortir le debugger.

Le script de détection des ciphers PFS me semble encore contenir des erreurs.

Effectivement, pourtant il devrait trouver le DHE, vu l'expression régulière employée (EC)?DH…

Merci pour le feedback, on va voir pour améliorer la chose.
par SwissTengu — 16.02.2015, 06:33 — PermaLink
- La partie "Certificat (commonName)" est OK (le temps qu'on pousse un nouveau résultat)
- la partie DH vs ECDH est OK — le problème était double: mauvais parsing de notre côté, et critère trop élevé (2048b pour DHE, alors que 1024 semblent OK).
par SwissTengu — 16.02.2015, 11:57 — PermaLink
Et pour le Crédit Suisse : SSLyze se ramasse des timeouts, et génère une sortie douteuse pour ne pas dire complètement fausse… "normal" donc que ça plante plus loin — mais pas très pratique du coup… Je vais voir avec le dev de SSLyze s'il a une idée.
par Alex — 16.02.2015, 17:46 — PermaLink
> Effectivement — on va voir si SSLyze en tient compte/si l'info est présente dans leur xml. Si non, faudra qu'on trouve un moyen de tester ça. Qui sait, ça donnera peut-être un module SSLyze (oui, on parle aussi python) ;).

Il me semble que c'est une information donnée par SSLyze - ou peut être est-ce dans un pull request non intégré au master.


> Et pour le Crédit Suisse : SSLyze se ramasse des timeouts, et génère une sortie douteuse pour ne pas dire complètement fausse

Rate limiting / "tarpitting" pour éviter les personnes trop curieuses? :)
par Alex — 16.02.2015, 20:13 — PermaLink
Pour ceux qui s'intéressent au sujet, un bon résumé du RFC 7457 - "Summarizing Known Attacks on TLS and DTLS" est disponible en français sur http://www.bortzmeyer.org/7457....
Ajouter un commentaire