La confidentialité en ligne ne consiste plus simplement à rester à l’abri des regards indiscrets. Le cryptage sur le Web joue un rôle clé en garantissant notre confidentialité et il évolue constamment.
Autrefois réservés aux pages de connexion et de paiement, les protocoles cryptographiques comme Transport Layer Security (TLS) ont récemment gagné en importance, offrant un moyen aux points de terminaison d'être authentifiés et de communiquer de manière confidentielle. Au cours des deux dernières années, les normes TLS ont également été mises à jour. Les navigateurs bloqueront bientôt les implémentations anciennes et faibles du protocole, telles que TLS 1.0 et 1.1. De nouveaux protocoles sont également introduits pour verrouiller les protocoles non sécurisés encore largement utilisés aujourd’hui.
Il est facile de comprendre pourquoi les entreprises peuvent avoir du mal à suivre le rythme. Au début de l’année dernière, par exemple, des chercheurs en sécurité ont découvert le tout premier échantillon de malware utilisant le protocole de cryptage émergent du système de noms de domaine, DNS-over-HTTPS (DoH).
Le paysage TLS n’est plus ce qu’il était et les organisations doivent rester au courant des derniers développements pour garantir que les sites Web sont déployés et maintenus en toute sécurité tout au long de leur durée de vie.
Dans la plupart des cas, les entreprises comprennent les avantages que les nouvelles mises à jour TLS peuvent apporter et semblent réceptives au changement. Par exemple, le dernier rapport de télémétrie TLS de F5 Labs a révélé que près d'un tiers des un million de sites Alexa les plus visités acceptaient les connexions TLS 1.3. À bien des égards, cela s’avère être une bonne décision commerciale. La plupart des navigateurs Web les plus populaires prennent déjà en charge la nouvelle norme, qui apporte de nombreux avantages en termes de sécurité et de performances.
Cependant, l’adoption de la dernière version de TLS n’est pas encore une option pour tout le monde.
Si tel est le cas, les entreprises devraient envisager de désactiver complètement les échanges de clés RSA en supprimant les suites de chiffrement qui les proposent. Une étude de F5 a révélé que plus d’un tiers des sites Web les plus populaires au monde proposent toujours RSA comme algorithme cryptographique préféré, même si les chercheurs en sécurité trouvent toujours des moyens de l’attaquer. Cela inclut la vulnérabilité ROBOT vieille de 19 ans qui permet d'effectuer des opérations de déchiffrement et de signature RSA avec la clé privée d'un serveur TLS. Selon une étude de F5 Labs, un peu plus de 2 % des principaux sites du monde sont probablement encore vulnérables à cet exploit.
Comme avec d’autres logiciels, les chercheurs en sécurité découvrent souvent des vulnérabilités dans les bibliothèques TLS. C’est pourquoi il incombe aux organisations de s’assurer qu’elles sont alertées lorsque leur serveur Web, leur équilibreur de charge ou leur contrôleur de distribution d’applications reçoit des mises à jour de leur pile TLS. Les politiques de mise en œuvre rapide des correctifs sont également essentielles.
Il est également important de noter que toute autorité de certification (CA) peut créer un certificat pour absolument n’importe quel domaine sur le Web. Pour cette raison, il est prudent de limiter l’autorisation à seulement deux ou trois autorités de certification connues et fiables. Cela peut être réalisé en créant des enregistrements d'autorisation d'autorité de certification DNS (CAA). De plus, l’application de l’en-tête HTTP Strict Transport Security (HSTS) aux applications Web fournira une couche de sécurité supplémentaire, car les navigateurs ne tenteront de charger un site en toute sécurité que via HTTPS. Il s’agit d’une étape cruciale qui peut aider à prévenir les attaques réseau qui forcent le chargement de pages non sécurisées, permettant aux attaquants d’espionner, de réécrire et de rediriger le trafic réseau.
Bien que les enregistrements DNS CAA aient été créés pour empêcher l'émission erronée de certificats pour des domaines valides, les fraudeurs tentent rarement de créer un certificat pour un domaine existant, tel que mybank.com. Au lieu de cela, ils créent des certificats pour les domaines qu’ils possèdent en utilisant le nom de marque « mybank » comme sous-domaine, comme mybank.attacker.com.
Heureusement, chaque fois qu'un certificat est créé par une autorité de certification, il est enregistré dans une base de données distribuée à l'échelle mondiale (les journaux de transparence des certificats). La surveillance des journaux CT est un moyen utile d'être alerté lorsqu'un domaine ou une marque est usurpé par des acteurs malveillants.
Avec HTTPS désormais omniprésent, il y a également davantage de chiffrements, de clés et de certificats à gérer. Combiné à l’adoption croissante des méthodologies DevOps, cela signifie que la vitesse de changement et de déploiement augmente constamment.
Tout comme les outils et les tests de sécurité sont intégrés à la chaîne d’outils d’automatisation, la configuration de HTTPS doit également l’être. Cela implique d’examiner la création orchestrée de certificats numériques et de développer des politiques internes qui définissent les normes, telles que la longueur minimale de clé et les suites de chiffrement. L’automatisation de cette nature aidera également à gérer les certificats qui arrivent à expiration, en les renouvelant automatiquement avant qu’une interruption de service ne se produise.
Malheureusement, de nombreuses failles de confidentialité et de sécurité existent encore, même lorsque TLS est déployé correctement. Des protocoles tels que DNS-over-HTTPS (DoH) émergent pour aider à combler ces lacunes et, s’ils améliorent la confidentialité des utilisateurs du Web, ils peuvent également rendre plus difficile pour les équipes de sécurité des entreprises d’identifier et de bloquer le trafic malveillant. Dans certains cas, cela nécessite de désactiver DoH pour les réseaux d’entreprise ou de déployer des services DoH internes pour vos utilisateurs. Ces services fonctionneront avec votre proxy Web et aideront à filtrer le trafic indésirable.
En fin de compte, même le meilleur déploiement TLS au monde ne peut pas empêcher l’injection de code malveillant par des logiciels malveillants côté client ou sa compromission en raison de scripts tiers. C'est pourquoi nous recommandons toujours de comprendre les limites du HTTPS et les lacunes présentes.
Une chose est sûre : le cryptage est en constante évolution. La longueur des clés augmente, les certificats sont automatisés, les gouvernements imposent des restrictions et de nouveaux protocoles émergent. C’est ce changement constant qui représente un nouveau degré de risque pour de nombreuses organisations et leurs clients. Un mauvais déploiement de TLS ne passera pas inaperçu auprès des pirates informatiques, des régulateurs et des compagnies d’assurance en cybersécurité, et il peut soulever de sérieuses questions sur le reste de l’infrastructure d’une organisation.