La problématique des communications non sécurisées
Reprenons l’exemple de nos puces RFID de la première partie. Vous l’aurez compris, cet exemple montre la vulnérabilité que représente un canal de communication non sécurisé.
Prenons un autre exemple plus proche de nous. Imaginez que vous vous connectiez à un routeur sans fil non fiable, comme un accès Wi-Fi public gratuit. Vous essayez alors d’accéder à votre compte en banque via le site de votre banque en ligne. Dans la plupart des cas, vous auriez obtenu une erreur de certificat vous indiquant que le site de votre banque ne possède pas les certificats appropriés. Pour un rappel sur les certificats, je vous invite à vous référer à ce cours sur la cryptologie.
En d’autres termes, le navigateur vous prévient que le site de votre banque ne possède pas de « carte d’identité » valide (faille sur la fonction authentification).
Vous ne faites pas attention (c’est les vacances) et vous acquittez le message d’erreur. Vous vous connectez à votre compte avec vos identifiants, vous réalisez quelques opérations : tout semble normal !
En réalité, une personne malveillante a pu mettre en place un serveur qui ressemble à celui de votre banque. Quand vous vous y connectez, ce serveur rapatrie la page web de votre banque, la modifie un peu et vous la présente. Lorsque vous vous connectez, ce serveur intermédiaire enregistre les détails de votre compte, se connecte à votre place, accède aux détails de votre compte et vous en envoie une copie. Il s'agit d'une faille sur la fonction confidentialité.
Découvrez les axes de protection
L’exemple précédent met en évidence les fonctions de sécurité compromises : la confidentialité des données échangées, leur intégrité et l’authentification.
Pour se protéger, la mise en place de protocoles de sécurisation de données comme TLS (Transport Layer Security), successeur de SSL (Secure Socket Layer), est recommandée. L’objectif initial de TLS était la sécurisation du protocole HTTP, mais son champ d’application s’est élargi depuis : protection d’autres services comme SMTP ou LDAP, création de réseaux privés virtuels (VPN), sécurisation de réseaux sans fil (EAP-TLS).
La confidentialité
Pour éviter l’écoute par un tiers, les informations échangées ne doivent pas pouvoir être espionnées. Cette fonctionnalité est assurée par des algorithmes de chiffrement symétriques pour l’échange des données (AES 256, RC4, DES, BlowFish) et asymétriques (RSA, DSA, Diffie Helmann) dans la phase d’authentification et d’échange de la clé secrète.
L’intégrité
Le client et le serveur doivent pouvoir s’assurer que les messages transmis ne sont pas altérés et qu’ils proviennent bien de l’expéditeur attendu. Dans le cas de TLS, ces fonctionnalités sont assurées par la signature des données (HMAC, MD5, RIPEMD, SHA-1).
L’authentification
Ce point important permet de s’assurer de l’identité du programme, de la personne ou de l’entreprise avec laquelle on communique. Cette fonctionnalité est implémentée grâce à l’utilisation de certificats X.509.
Mais, au fond, quelles sont les bonnes pratiques à mettre en œuvre ?
Mettez en place les bonnes pratiques avec TLS
L’utilisation répandue du protocole TLS est le sujet de nombreuses études qui aboutissent régulièrement à la découverte de nouvelles vulnérabilités. Compte tenu des corrections et des améliorations apportées au fil des années, à la fois aux spécifications et aux implémentations, il est essentiel d’utiliser les dernières versions des équipements et logiciels impliqués dans la sécurisation des communications.
Recommandation : utilisez des composants logiciels à jour
Les limitations successives qui ont été identifiées depuis la création de SSL en 1995 ont motivé plusieurs mises à jour des spécifications. Les retours d’expérience de l’industrie ont permis de mettre en lumière les défauts de certaines versions des protocoles.
Recommandations sur les versions de protocoles
Les connexions doivent être réalisées avec la version TLS1.2. À noter que l'organisme d'élaboration des standards Internet vient d'approuver la norme de sécurité TLS 1.3.
La version SSL v2 est fortement déconseillée en toutes circonstances. Il faut également privilégier l’usage de composants logiciels qui ne prennent pas en charge cette version du protocole.
Il est également recommandé que préalablement à l’échange de clés, le client et le serveur soient authentifiés. Les alternatives anonymisées sont à proscrire.
Recommandations sur l’échange des clés
La propriété de confidentialité persistante doit être assurée. Il faut pour cela employer une suite cryptographique reposant sur un échange Diffie–Hellman éphémère (ECDHE ou, à défaut, DHE).
Concernant le choix entre une clé de 128 bits ou de 256 bits pour AES, il n’existe à ce jour aucune attaque pratique qui remette en cause la confiance accordée à AES-128. Cependant, AES-256 étant jugé plus robuste, son utilisation est préférée à celle de AES-128.
Recommandation sur le chiffrement par bloc
Les suites qui mettent en œuvre l’algorithme de chiffrement par bloc AES-256 sont à privilégier.
Une fois la session TLS établie, chaque message est protégé en intégrité. Lorsque la suite cryptographique n’utilise pas de mode de chiffrement intègre, il s’agit d’un motif d’intégrité calculé par le mode HMAC, qui s’appuie sur une fonction de hachage. Les suites standardisées pour TLS permettent l’utilisation de MD5, de SHA-1 ou d’un élément de la famille SHA-2.
Or, MD5 a fait l’objet de nombreuses attaques et la robustesse de SHA-1 a été remise en cause.
Recommandation sur les signatures permettant l'authentification
La signature des messages HMAC permettant l’authentification doit être construite avec un algorithme de la famille SHA-2 comme SHA-256 ou bien SHA-384.
Ces quelques bonnes pratiques principales garantissent une communication sécurisée. Pour aller plus loin dans l’implémentation (notamment sur les extensions conseillées et la mise en place d’une IGC à base de certificat X509), je vous conseille la lecture des documents suivants :
Les recommandations de sécurité relatives à TLS, par l'ANSSI ;
SSL/TLS, 3 ans plus tard, par Olivier Levillain.
En résumé
Dans le prochain chapitre, je vous propose de voir en détail un point majeur de vulnérabilité des applications, l’authentification, et les recommandations pour durcir les accès.
