Analyse: CERT Alert TA17-075A

L'interception volontaire des communications HTTPS affaiblit le niveau de sécurité

Origine: Bulletin d'alerte CERT TA17-075A

Cette alerte du CERT était attendue. De plus en plus de systèmes de sécurité interceptent le trafic HTTPS, notamment pour détecter des programmes malveillants qui peuvent potentiellement y circuler sans être repérés sinon, mais aussi pour d'autres raisons comme pour éviter la fuite d'informations sensibles.

Note: TLS = protocole successeur de SSL.

Impact

Ces systèmes d'interception qui se multiplient souffrent malheureusement de beaucoup de problèmes et de malfaçon, ce qui agit malheureusement dans le sens contraire de la sécurité recherchée et finit parfois par exposer davantage l'organisation à des risques précédemment inexistants.

Solution

S'assurer que les produits utilisés par l'organisation pour l'inspection SSL sont à jour et se conforment correctement autant que possible au protocole SSL/TLS, notamment dans le respect de la validation de tous les certificats de la chaîne utilisée.

badssl.com

BadSSL.com est un site offre une série de tests pour valider la conformité des communications sécurisées. Un peu spartiate et avare en explication, il permet toutefois de tester la validité des certificats en empêchant, par exemple, la connexion aux sites dont le protocole de cryptage est trop faible. Pour rappel, dans le pire des cas, une connexion SSL/TLS peut être établie sans aucun cryptage des communications SSL/TLS qu'est-ce que c'est ?.

Plus de détail sur les risques de l'inspection SSL

Commentaires et explications en français basées en partie sur l'article (anglais): "The Risks of SSL Inspection"

Il y a deux choses pour lesquelles SSL et TLS (qu'est-ce que c'est ?) sont utiles sur le web:

Contexte

Etablissement et l'utilisation de communications HTTP sécurisées. Protocole utilisé: HTTPS.

Certificats SSL

Les certificats SSL sont des "papiers" d'identité d'un serveur. Un certificat permet de vérifier l'identité d'un serveur. Un certificat est produit par une autorité de certification: la CA (Certificate Authority). Un certificat permet de signer et/ou chiffrer asymétriquement un élément numérique, une clé privée et une clé publique lui correspondent.

Le certificats racines et intermédiaire

La CA possède aussi son certificat propre, c'est un certificat racine. Un certificat racine garanti l'identité d'une CA. La CA signe tous les certificats qu'elle produit avec son certificat racine.

Risque sur la clé privée

Si la clé privée d'un certificat racine d'une CA est volée, les conséquences sont catastrophiques. Le malfrat a toute liberté de se comporter comme la CA et de produire des certificats en son nom qui ne pourront alors pas être distingués des (licites) certificats produits par la CA par un navigateur. En d'autres termes, il serait alors possible au voleur de produire un certificat authentifiant un site malveillant comme le site d'une banque connue par exemple.

Certificats intermédiaires

Afin de protégér la clé privée de son certificat racine, un CA produit des certificats intermédiaires qui sont ceux qui produisent les certificats SSL pour les sites qu'elle authentifie. Elle diffuse ainsi le risque en multipliant ses clés privées et n'expose pas la clé privée de son certificat racine.

Chaîne des certificats

A l'achat d'un certificat SSL, le client reçoit généralement son certificat, plus le certificat intermédiaire de la CA qui a servi à le produire. Les deux certificats sont alors installés sur le serveur hébergeant le site du client, et celui-ci va distribuer les deux certificats lors de l'établissement de la communication SSL. L'ensemble des certificats produits, du certificat racine au certificat SSL du client, en passant par le(s) certificat(s) intermédiaire(s) est appelé la chaîne des certificats.

Certificats de confiance

Les navigateurs Internet connaissent par défaut un ensemble de certificats racine auxquels ils font confiance. les navigateurs stockent les certificats auxquels ils font confiance, dans un conteneur de certificats sur la machine locale. Les certificats non racine, intermédiaires et SSL client, délivrés au navigateur et validés lors de l'établissement de la connexion sécurisée avec le serveur, sont placés dans le conteneur de certificats.

Sur Windows par exemple, Chrome utilise le conteneur de certificats du système, alors que Firefox, utilise un conteneur de certificats qui lui est propre.

Inspection SSL

L'inspection SSL est une attaque de type MITM - "Man In The Middle". Difficile à réaliser, car l'attaquant doit dérouter le trafic du client sur lui, se faire passer pour le serveur demandé par le navigateur, et présenter un certificat valide. Lorsque l'attaque réussit, l'attaquant peut (entre autres) espionner le trafic sécurisé entre le navigateur et le serveur cible, simplement en le relayant.

Pour ce qui est de présenter un certificat valide, il "suffit" à l'attaquant de réussir à placer dans le conteneur de certificats de confiance, son propre certificat racine. C'est possible, par exemple avec l'installation d'un programme malveillant sur le système de l'utilisateur, qui va insérer le certificat racine falsifié dans le conteneur de certificats du système.

Sécurisation par interception SSL

Pour intercepter le trafic SSL, il faut donc relativement lourdement intervenir. Une raison discutablement valide de le faire est d'inspecter le trafic réseau décrypté de la communication SSL, afin d'éviter la fuite d'information ou de détecter un virus ou un programme malveillant qui passerait par ce canal.

C'est que fait un antivirus, mais également les systèmes de sécurité comme les boîters parefeu ou les serveurs proxy par exemple. Donc aujourd'hui, le seul moyen qu'ont les système de sécurité d'inspecter le trafic SSL, est de tricher et de pratiquer l'interception SSL.

Ces système deviennent ainsi eux-mêmes un point d'attaque privilégié, car celui qui peut en prendre contrôle peut ainsi également et à moindre frais, inspecter le trafic SSL.

Le billet du CERT commenté ici (l'alerte TA17-057A fournit un lien sur le billet) recense 7 erreurs communes que font les fournisseurs de sécurité dans leur implémentation de l'interception SSL et les risques que cela représente.

Il y présente également un liste de 58 logiciels potentiellement affectés, dont entre autres les bien connus:

- ZyXel firewall
- Fortinet Fortigate
- SonicWALL
- Baracuda
- Citrix
- ESET
- Kaspersky
- Juniper
- McAfee
- Sophos
- Squid
- Trend Micro
- Zscaler

Problème supplémentaire

Plus récemment, on s'aperçoit que l'utilisation de ces systèmes de protection présente un problème supplémentaire très ennuyeux. Les système n'arrivent pas à suivre l'évolution des protocoles SSL/TLS. Ainsi, lorsqu'une vulnérabilité dans les protocoles de sécurité est trouvée, TLS est par exemple mis-à-jour et les sites Internet les plus à la page se mettent à jour pour appliquer le niveau de sécurité maximum. Par contre, le système de sécurité qui utilise l'interception SSL ne supporte peut-être pas encore la version corrigée du protocole et il en résulte soit l'impossibilité de communiquer avec le site dans le meilleur des cas, soit, pire, le système "downgrade" ou abaisse le niveau de sécurité de la communication en forçant l'utilisation du protocole de sécurité dans sa version vulnérable.