Le HTTPS est la solution la plus simple pour fournir une couche de sécurité aux utilisateurs de son site ou application web. Mais il n'est pas toujours facile de correctement l'implémenter. Nous allons passer en revue les principaux écueils liés à ce protocole.
Qu'est-ce que le HTTPS ?
Le HTTPS est la version sécurisée du protocole HTTP. Il permet de se connecter à des sites Internet sans que le contenu des données échangées, ni même les URL complètes des sites visités, ne soit récupérables par un pirate informatique.
Toutefois, il ne suffit pas d'activer le HTTPS, il faut correctement le paramétrer. Chaque année, de nouvelles faiblesses sont découvertes dans le protocole TLS sur lequel se base le HTTPS afin de chiffrer les échanges de données. Ainsi, les administrateurs système doivent régulièrement faire évoluer les paramètres de sécurité afin de se parer d'éventuelles attaques.
Les différentes versions de SSL/TLS
Le protocole SSL (Secure Socket Layer) est apparu au milieu des années 90, avec pour but d'assurer l'intégrité et la confidentialité des données échangées, mais aussi l'authentification du serveur (et parfois, des clients). Deux versions ont été disponibles : le SSL v2 et le SSL v3. Ce protocole a rapidement été suivi par son évolution : le protocole TLS (Transport Layer Security), à partir du début des années 2000. Ce dernier connaît actuellement trois versions : TLS v1.0, TLS v1.1, TLSv1.2, et la version 1.3 devrait être disponible en 2017.
Utiliser le protocole SSL est aujourd'hui considéré comme non-sûr suite aux attaques DROWN (SSL v2) et POODLE (SSL v3). Le protocole TLS v1.0 a quant a lui été touché par l'attaque BEAST. Ainsi, il est recommandé de n'utiliser que les versions les plus récentes du protocole TLS : TLS v1.1 et TLS v1.2.
Les cipher suites, ou suites cryptographiques
Une suite cryptographique est un groupement d'algorithmes dont chacun va assurer la sécurité d'une partie de la communication entre un client et le serveur. Chaque suite se compose ainsi (source : Mozilla) :
- d'un algorithme d'établissement des clés (comme RSA, DH, ou ECDH) ;
- d'un algorithme d'authentification du tiers (comme RSA, DSA ou ECDSA) ;
- d'un algorithme de chiffrement des données (comme RC4, DES, AES) et taille de clés ;
- d'un algorithme de hachage permettant l'authentification et la vérification des messages (SHA1, SHA256).
La sécurité de ces suites cryptographiques dépend fortement de l'algorithme de chiffrement des données. En effet, c'est principalement lui qui est remis en cause ; on pense notamment à l'algorithme RC4, considéré comme obsolète suite à la découverte de plusieurs vulnérabilités. Plusieurs attaques affectent cet algorithme, dont la plus connue de toutes : Bar Mitzvah.
Au niveau des recommandations, Mozilla fournit sur son wiki une page pour déterminer la cipher suite la plus adaptée en fonction des contraintes de compatibilité de l'environnement étudié. Trois configurations-type sont ainsi disponibles : "Old", "Intermediate" et "Modern".
Les certificats
Un certificat est une carte d'identitié numérique permettent d'identifier un hôte. Il permet de s'assurer que l'on communique avec le bon serveur, et non un serveur contrôlé par un attaquant. On y lit notamment la période de validité du certificat, et l'autorité de certification qui a validé (ou signé) notre certificat. Il est nécessaire de faire attention à différents problèmes qui peuvent se poser par rapport au certificat par rapport aux propriétés suivantes :
- la période de validité ;
- la fonction de hashage ayant permis de signer le certificat ;
- le sujet du certificat (dans le cas d'un site, il s'agit du nom de domaine) ;
- l'autorité de certification ayant signé le certificat.
Si l'un de ces points n'est pas conforme, au mieux, le navigateur de l'utilisateur lui affichera un avertissement, et au pire, il empêchera l'accès au site. Bientôt, les navigateurs afficheront également un message d'erreur pour les certificats dont la signature a été générée avec l'algorithme SHA-1 plutôt que SHA-2. Il peut en effet être victime de collisions, c'est à dire qu'il est possible de générer un autre certificat avec exactement la même signature.
Il est donc recommandé de faire appel à des autorités de certifications reconnues et réactives par rapport aux normes de sécurité. Nous recommandons généralement Let's Encrypt ou StartSSL, qui ont l'avantage d'être gratuites.
La clé
Pour chiffrer les échanges, le serveur envoie son certificat à l'utilisateur, celui-ci contenant sa clé publique. Des faiblesses ont été trouvées suggérant que les clés de taille trop faibles pourraient mener les échanges à être déchiffrés, notamment par la NSA qui possède une forte puissance de calcul.
Il est aujourd'hui recommandé d'utiliser des clés d'une taille minimale de 2048 bits, voire de 4096 bits lorsque cela est possible.
La renégociation
Lors d'une connexion HTTPS, il arrive parfois que les paramètres de sécurité doivent être renégociés. Toutefois, laisser la possibilité aux clients de demander cette renégociation ouvre la possibilité pour un attaquant de forcer la renégociation à la baisse, pour que la connexion utilise des paramètres permettant un déchiffrement plus rapide des échanges.
Il est recommandé de désactiver la renégociation initiée par les clients, et d'activer le mode de renégociation sécurisée du serveur.
La compression
Le fait d'activer la compression sur le protocole SSL/TLS expose les données échangées à l'attaque CRIME, permettant notamment de récupérer des cookies de connexion via l'analyse statistique des paquets échangés entre un client et le serveur.
Il est recommandé de désactiver la compression sur le protocole SSL/TLS afin d'éviter cette attaque.
HSTS (HTTP Strict Transport Security)
Le HSTS est un mécanisme de sécurité assez récent. Il s'agit d'une instruction que le serveur renvoie aux navigateurs des clients, et qui leur indique que pendant une certaine durée (généralement plusieurs mois), ils ne doivent se connecter au serveur que de manière sécurisée.
Lorsqu'un navigateur se connecte pour la première fois à un site utilisant HSTS, il enregistre que pour ses futures visites, si la connexion au serveur ne peut pas s'établir de manière sécurisée (certificat expiré, nom de domaine différent du sujet du certificat...), la connexion doit tout simplement être bloquée. L'utilisateur ne pourra pas accepter le risque et passer outre l'avertissement de sécurité en ajoutant une exception.
Ce mécanisme permet de se prémunir des attaques de type Man in the Middle. En revanche, il y a deux inconvénients :
- Cela nécessite que les administrateurs système puisse toujours garantir une connexion sécurisée au serveur. Par exemple, il ne faut pas que le certificat arrive à expiration, et ce n'est pas si facile.
- Lors de sa première connexion au serveur, le client sera "vulnérable". En effet, ce n'est que lors de la première connexion que le client recevra l'instruction de la part du serveur, comme quoi la connexion doit être sécurisée. Un attaquant réalisant une attaque de type Man in the Middle dès la première connexion d'un client au site web pourra faire échouer ce mécanisme de sécurité.
Pour parer au deuxième inconvénient, il est possible de faire enregistrer son nom de domaine sur une liste qui est intégrée dans les navigateurs récents. Ainsi, le client sera en sécurité dès sa première connexion au serveur.
Conclusion
Nous avons passé en revue les principaux éléments de sécurité d'une connexion HTTPS. D'autres mécanismes existent, notamment TLS_FALLBACK_SCSV, pour éviter qu'un attaquant ne puisse faire baisser le niveau de chiffrement d'une connexion. D'autres mécanismes vont sans doute voir le jour.
Ainsi, il est important pour les administrateurs système de se maintenir au courant des nouvelles vulnérabilités trouvées, et sur les nouveaux mécanismes qu'il est possible de mettre en place afin d'assurer l'intégrité et la confidentialité des échanges client-serveur. En ce sens, AlgoSecure peut vous aider à analyser la configuration HTTPS de vos sites, à comprendre les problèmes détectés, et à mettre en place une configuration sécurisée.
À propos : Le blog d'AlgoSecure est un espace sur lequel notre équipe toute entière peut s'exprimer. Notre personnel marketing et commercial vous donne des informations sur la vie et l'évolution de notre société spécialisée en sécurité sur Lyon. Nos consultants techniques, entre deux tests d'intrusion ou analyses de risque, vous donnent leur avis ainsi que des détails techniques sur l'exploitation d'une faille de sécurité informatique. Ils vous expliqueront également comment sécuriser votre système d'informations ou vos usages informatiques particuliers, avec autant de méthodologie et de pédagogie que possible. Vous souhaitez retrouver sur ce blog des informations spécifiques sur certains sujets techniques ? N'hésitez pas à nous en faire part via notre formulaire de contact, nous lirons vos idées avec attention. Laissez-vous guider par nos rédacteurs : Alexandre, Amine, Antonin, Arnaud, Benjamin, Damien, Enzo, Eugénie, Fabien, Françoise, Gilles, Jean-Charles, Jean-Philippe, Jonathan, Joël, Joëlie, Julien, Jéromine, Ludovic, Lyse, Nancy, Natacha, Nicolas, Pierre, PierreG, Sébastien, Tristan, Yann, et bonne visite !