Quiconque jette un coup d'œil sur les spécifications actuelles d’EBICS pourra s’étonner de constater que la version prescrite pour le protocole de sécurisation des échanges sur Internet, Transport Layer Security (TLS), est toujours la version 1.0. A un certain moment, ce fut un choix judicieux: lorsque les spécifications EBICS ont été publiées, le protocole TLS 1.0 était la technologie la pus avancée. À l'époque, en effet, il avait surtout été jugé important de ne pas utiliser le protocole SSL. Ce choix avait d'ailleurs garanti une excellente protection par exemple contre la vulnérabilité logicielle POODLE, et ce, aussi bien pour les éditeurs que pour les exploitants: EBICS excluait l’utilisation du protocole SSL et les applications EBICS étaient protégées contre POODLE. Ceci étant dit, POODLE n'aurait eu de toute façon pratiquement aucune chance avec un client EBICS: Lors d'une telle attaque, l'agresseur contraint en effet le client à envoyer des milliers de requêtes au serveur HTTPS, pour, par exemple, obtenir le cookie de la session. Or, EBICS n'utilise aucun cookie de session et les logiciels clients ne sont pas des applications web avec lesquelles JavaScript peut être utilisé pour envoyer des milliers de requêtes. Mais essayez d’expliquer cela aux auditeurs!
Et il ne s'agissait là que de l'une des attaques malveillantes portant des noms amusants: HEARTBLEED, par exemple, mettait à profit une erreur dans l'implémentation TLS d'OpenSSL. Et sans oublier non plus la menace BEAST. Pourtant, comme dans le cas de la menace POODLE, EBICS est également protégé contre une attaque BEAST. Malgré tout la réputation du protocole TLS 1.0 est durablement compromise et tous les sites recommandent de passer au successeur, plus sûr, le protocole TLS 1.2.
Cela fut admis dans le cadre d’EBICS et des demandes de modification ont été planifiées afin de prendre charge TLS 1.2. Malheureusement, la sortie de cette nouvelle version prend du retard et les auditeurs nous demandent souvent : Pourquoi EBICS utilise-t-il encore le protocole TLS 1.0 ? Un argument du genre «parce ce que c'est ce qui est prescrit dans les spécifications » n'est certainement plus une raison valable si l'on tient compte du fait que le BSI (federal office for information security) conseille officiellement d'éviter cette version. C'est d'ailleurs la raison pour laquelle vous trouverez désormais sur le site officiel EBICS des recommandations en matière de sécurité qui conseillent d'utiliser la version TLS 1.2 – sans expliquer comment concilier cette recommandation et la spécification.
Nous avons testé 82 serveurs EBICS en Allemagne et en France : Seulement 52 serveurs ont pu communiquer avec nous en utilisant le protocole TLS 1.2. Si vous décidez donc aujourd'hui en tant que fabricant de produits clients de ne plus supporter TLS 1.0, vous ne pourrez plus vous connecter à environ un tiers des serveurs EBICS. Et la situation risque d'être encore pire pour les exploitants de serveurs qui communiquent avec des produits clients utilisant les différentes versions.
Quelles sont alors les possibilités? Proposer la version TLS 1.2 sans toutefois interdire la version TLS 1.0. Cette solution est possible aussi bien pour les clients que pour les serveurs; lors de la prise de contact - ou handshake - TLS, les deux parties se mettent d'accord sur la variante commune la plus sûre – du moins en théorie. Ceci a d'ailleurs effectivement fonctionné sur 28 des serveurs testés. Mais nous avons aussi trouvé deux serveurs qui interrompent systématiquement la communication dès lors que le client propose la version TLS 1.2. Ceci est particulièrement désagréable pour les fabricants de produits clients étant donné que les clients ne peuvent alors tout simplement pas proposer la version TLS 1.2 «au cas où». Et s'ils le font tout de même, ils prennent le risque de ne pas pouvoir communiquer avec quelques serveurs.
Nous avons naturellement informé les opérateurs de ces deux serveurs EBICS. Comme notre test ne couvrant pas tous les serveurs EBICS, nous recommandons aux exploitants de contrôler eux-mêmes le comportement de leur serveur EBICS.
Une question subsiste cependant: Quel serait le risque lié à un décryptage du protocole TLS dans EBICS ; quelles seraient les données visibles? Les données de l'ordre elles-mêmes sont cryptées une seconde fois et restent invisibles pour l'agresseur. Il reste donc uniquement le cadre XML dans lequel sont intégrées les données de l'ordre ou, comme on les nomme également depuis l'affaire Snowden : les métadonnées. Il s'agit là principalement du type d'ordre ou du format de fichier, de l'ID client et de l'ID participant. En d'autres termes, pas vraiment grand-chose. Cela suffira-t-il à calmer les esprits : c’est une autre histoire.
Curd Reinert
0 commentaires:
Enregistrer un commentaire