Dans le cadre de son activité SSL Labs, Ivan Ristic du Qualys SSL Labs (Centre de recherches sur TLS et PKI qui fournit des outils de sécurité, de la documentation ainsi que des études sur les écosystèmes) passe beaucoup de temps à aider les autres à renforcer leur sécurité TLS. Soit directement ou en développant des outils et en rédigeant de la documentation. Avec le temps, il a remarqué que déployer TLS en toute fiabilité était de plus en plus compliqué alors que ce devrait être le contraire.
C’est pourquoi il présente dans DataSecurityBreach.fr un modèle de maturité TLS, un modèle de déploiement conceptuel avec une feuille de route pour une sécurité TLS puissante. Ce modèle offre cinq niveaux de maturité.
Au Niveau 1 se trouve le chaos. Sans aucune politique ni règle associée à TLS, votre sécurité est aux mains du hasard (par exemple la configuration constructeur par défaut), d’individus ou plus généralement d’initiatives ad-hoc. Si bien que vous ne savez pas ce dont vous disposez ni quelle sera votre sécurité. Même si vos sites existants bénéficient d’une bonne sécurité, impossible de garantir que cela sera aussi le cas pour vos nouveaux projets. Tout le monde commence à ce niveau.
Le Niveau 2, celui de la configuration, ne concerne que la sécurité du protocole TLS et ignore les protocoles supérieurs. C’est de ce niveau dont nous parlons le plus, mais c’est généralement celui le plus facile à atteindre. Pour les systèmes modernes, il s’agit essentiellement d’un problème de reconfiguration des serveurs. Les systèmes plus anciens peuvent nécessiter une mise à niveau, ou, en dernier recours, un proxy plus sécurisé installé en frontal.
Le niveau 3, celui de la sécurité applicative, concerne la sécurisation de ces protocoles applicatifs supérieurs pour éviter des problèmes susceptibles de compromettre le chiffrement. Pour ce qui est des sites Web, ce niveau exige d’éviter de mélanger du texte en clair avec du contenu chiffré au sein de la même application ou sur la même page. Autrement dit, l’ensemble de la surface applicative doit être chiffrée. En outre, tous les cookies applicatifs doivent être bloqués et leur intégrité doit être vérifiée dès leur arrivée afin de se protéger contre des attaques à base d’injection de cookies.
Le Niveau 4, celui de l’engagement, a trait à l’engagement sur le long terme en matière de chiffrement. Concernant les sites Web, ce niveau est atteint en activant HTTP Strict Transport Security (HSTS), une norme relativement récente et prise en charge par les navigateurs modernes (par exemple supportée par IE sous Windows 10). HTTP Strict Transport Security applique un modèle de sécurité TLS plus strict pour mettre en échec les attaques visant à supprimer SSL ainsi que celles incitant les utilisateurs à cliquer sur les avertissements relatifs aux certificats.
Enfin, au niveau 5 se trouve une puissante sécurité. Vous définissez votre propre protection privée dans le Cloud PKI pour vous prémunir contre la plus importante faiblesse de l’infrastructure PKI, à savoir la possibilité pour une quelconque autorité de certification d’émettre un certificat pour un site Web sans la permission de son propriétaire. Pour ce faire, la technique d’« épinglage » des certificats (« public key pinning ») permet de restreindre le nombre d’autorités de certification susceptibles d’émettre des certificats pour vos sites Web. Il est également possible d’adopter une approche plus sécurisée en approuvant chaque certificat individuellement.
La simplicité conceptuelle du modèle de maturité de la sécurité TLS permet de savoir facilement où nous en sommes et ce qu’il reste à améliorer. Nous pourrons ainsi nous concentrer sur ce qui importe vraiment. Même s’il offre la meilleure sécurité, le niveau 5 nécessite beaucoup de travail et gère des risques inexistants pour la plupart des sites. Et s’il ne fait pas l’unanimité, le Niveau 4 reste le niveau minimum reconnu comme sécurisé et vers lequel devraient tendre la plupart des entreprises.
