Lorsque vous vous connectez depuis votre travail à un site WEB sécurisé en HTTPS, comme par exemple un Webmail personnel ou le site de consultation de vos comptes bancaires, pouvez-vous dire jusqu'à quel point vous êtes certains que vos échanges sont confidentiels ?
1. introduction
De nos jours, la plupart des communications entre un serveur WEB et un navigateur sont sécurisées au moyen des protocoles SSL v3 ou TLS (connexion en HTTPS). Ces protocoles fonctionnent suivant un mode client/serveur et permettent l'établissement de tunnels sécurisés. Les services de sécurité fournis par SSL/TLS sont les suivants :
- l'authentification du serveur,
- l'authentification optionnelle du client,
- la confidentialité des données échangées,
- l'intégrité des données échangées.
L'authentification des parties repose sur l'utilisation de certificats numériques au format X.509. La confiance en ces certificats est garantie par une ou plusieurs autorités de certification, qui peuvent être de nature commerciale (GlobalSign, Thawte, VeriSign...) ou privée. L'authentification du client est par exemple utilisée lors de la déclaration d'impôt en ligne sur le site du gouvernement.
Si l'autorité ayant signé le certificat d'un serveur n'est pas reconnue comme autorité de confiance par le client, un avertissement de sécurité prévient normalement l'utilisateur que l'identité du serveur distant n'a pas pu être vérifiée. Si l'utilisateur passe outre cet avertissement, le tunnel SSL/TLS pourra tout de même être établi.
Enfin, rappelons que les protocoles SSL/TLS sont également utilisés pour établir des liaisons de type VPN, permettant la connexion d'une machine à un réseau privé distant.
2. le danger pour les entreprises
Une fois la connexion établie entre la machine d'un employé et un serveur distant, les données qui transitent dans un tunnel SSL/TLS ne peuvent être ni analysées, ni filtrées par l'entreprise.
Il peut bien sûr s'agir d'une connexion à caractère professionnel, mais cette connexion peut également permettre :
- la divulgation d'informations confidentielles vers l'extérieure de l'entreprise (voir chez des concurrents),
- le téléchargement (involontaire ou non) de logiciels malveillants de type virus ou vers sur le réseau interne de l'entreprise,
- une connexion VPN reliant, via la machine de l'employé, le réseau interne hautement sensible de l'entreprise avec un réseau externe potentiellement très dangereux.
Dans les trois cas, tous les moyens mis en place par l'entreprise pour filtrer les échanges externes (pare-feux, relais, anti-virus...) sont contournés par l'utilisation du tunnel sécurisé.
3. les solutions disponibles
Des appliances commerciales de type relai Internet (BlueCoat, IronPort...) proposent aujourd'hui aux entreprises des fonctionnalités «d'analyse intelligente du trafic SSL/TLS». Concrètement, cela se traduit par l'impersonification du client par rapport au serveur, et par l'impersonification du serveur par rapport au client. Deux tunnels sécurisés sont donc établis avec l'appliance, l'un à destination du serveur, l'autre à destination de la machine cliente. Tous les flux transitent ainsi en clair par l'appliance, qui peut alors analyser et filtrer les échanges.
Pour pouvoir impersonifier le serveur auprès du client, un certificat SSL auto-signé est généré à la volée et renvoyé au client. L'utilisateur reçoit alors un avertissement de sécurité, puisque le certificat est auto-signé et non reconnu comme autorité de confiance. Cependant, rares sont les utilisateurs qui lisent (et comprennent) les avertissements de ce type, et le tunnel finit par être établi en toute confiance.
Si une infrastructure de gestion des clés (IGC, ou PKI en anglais) a été déployée en interne, les certificats générés à la volée peuvent alors être signés par l'autorité de certification de l'entreprise, par défaut approuvée sur toutes les machines, ce qui aura pour effet de supprimer les avertissements de sécurité précédents. L'interception des flux «sécurisés» sera alors totalement transparente pour les utilisateurs.
Attention, la solution fournie par ces appliances n'est possible que lorsqu'il n'y a pas d'authentification de la part du client. En effet, la clé privée associée au certificat du client n'étant présente que sur la machine de l'utilisateur, l'authentification de l'appliance en tant que client échouera forcément auprès du serveur WEB.
Ainsi, on ne pourra pas intercepter et analyser une connexion VPN SSL, mais on pourra cependant plus facilement identifier de telles connexions, et donc les interdire.
4. le danger pour les utilisateurs
Au même titre que la messagerie ou les données personnelles, le principal danger pour les utilisateurs réside dans l'abus de pouvoir des administrateurs ou de la direction. Cependant, si un utilisateur peut avoir conscience que ses données personnelles stockées sur un serveur de l'entreprise peuvent être lues, en revanche des données distantes accessibles uniquement en HTTPS devraient être maintenues confidentielles par rapport à l'entreprise.
Dans le cas d'une appliance analysant le trafic SSL/TLS et intégré à l'IGC interne, l'utilisateur lambda n'aura aucun moyen de s'apercevoir que ses échanges ne sont plus confidentiels. Ainsi, si en théorie l'appliance n'est pas configurée pour journaliser les informations qui transitent par elle, rien ne peut empêcher leur écoute et leur enregistrement par des administrateurs peu scrupuleux...
Le seul moyen de contrôle par un utilisateur est de systématiquement vérifier les certificats des serveurs sur lesquels il se connecte. Cette tâche n'est bien entendu pas à la portée de l'utilisateur lambda.
5. Conclusion
Pour éviter le contournement des plates-formes de sécurité Internet et afin de réduire les risques liés à l'utilisation des tunnels SSL/TLS, il est préférable de contrôler les échanges en coupant les tunnels au moyen d'une appliance spécialisée.
Cependant, pour prévenir tout litige ultérieur avec les utilisateurs, la mise-en-place de ces équipements doit être contrôlés de la façon suivante :
- Responsabilisation des administrateurs :
Il est toujours bon de rappeler aux administrateurs ce qu'ils peuvent faire, et ce qu'ils n'ont pas le droit de faire, au nom du bon sens et au nom des législations en vigueur (loi Informatique et liberté, loi Godfrain...).
- Communication aux utilisateurs :
La charte signée par les utilisateurs concernant l'utilisation des ressources Internet doit être mise-à-jour et préciser la mise en place d'équipement de sécurité provoquant une rupture des tunnels SSL, ceci pour permettre l'analyse et le filtrage des flux échangés avec l'extérieur de l'entreprise.
Article écrit par Alexandre Lauga
Edit from the Orange Business team: Hervé left the Orange Group since he wrote his last posts.