Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 

De la Théorie à la pratique











Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

Eric Leblond, EdenWall Technologies : vers la fin d’HTTP !

novembre 2010 par Eric Leblond, Fondateur et Directeur Technique d’EdenWall Technologies

Le monde de la sécurité a frémi récemment à cause d’un plugin pour le navigateur Firefox appelé Firesheep. Cet add-on permet de voler l’identité des personnes qui utilisent Facebook, Twitter, ... et qui sont sur le même réseau que vous. L’impact psychologique du plugin est très fort car il rend triviale l’utilisation d’une recette bien connue : le vol de cookies.

Pour en comprendre le principe, prenons le cas d’un site comme Facebook et rejouons une session utilisateur depuis le début : l’utilisateur ouvre la page dans son navigateur. Une page en HTTPS (ce qui lui assure la confidentialité) lui permet de rentrer son login/mot de passe pour s’authentifier sur le site. De manière à ne pas répéter l’authentification à chaque page, le site envoie à l’utilisateur un cookie d’identification que le navigateur présente lors de toutes les requêtes ultérieures. Le site détermine ainsi l’identité de l’utilisateur pour le reste des échanges se font alors ensuite en HTTP.

L’attaque réalisée par Firesheep est très simple : en espionnant le réseau, elle récupère le cookie qui transite en clair (puisque sur HTTP) et le transmet à Firefox. La recette du cookie est peut-être secrète, mais nul besoin de la connaître pour dupliquer un cookie informatique. L’utilisateur du plugin peut alors se faire passer pour l’utilisateur de son choix.

La solution de protection la plus simple est de passer en permanence par le protocole encrypté HTTPS. Le cookie est alors transmis de manière crypté jusqu’au serveur et l’interception n’est plus possible. Il est probable qu’à l’instar de Google, bon nombre de sites vont proposer, voire forcer l’utilisation du protocole HTTPS pour garantir la confidentialité des échanges entre l’utilisateur et le site. Des sites comme Facebook ou Microsoft ont d’ors et déjà annoncé qu’ils allaient réagir et offrir leurs services en HTTPS.

Ce passage à HTTPS a plusieurs conséquences. D’une part les fournisseurs de contenus vont devoir adapter leur architecture au cryptage qui nécessite plus de ressources que les transferts en clair. D’autre part, le responsable de la sécurité va perdre en visibilité sur les trafics au sein de son réseau. En effet, jusqu’à présent l’analyse du trafic par des moteurs d’inspection protocolaire permettait de comprendre la nature des flux qui transitaient sur le réseau. Les flux HTTPS sont quant à eux très difficiles à classifier. La visibilité sur l’activité en est donc fortement altérée.

Des solutions de contournement existent déjà. Il s’agit notamment de l’interception OpenSSL. Cependant, bon nombre d’enjeux, légaux et sécuritaires sont à considérer dans l’utilisation des techniques d’interception. Du point de vue légal, l’argument est simple : « si c’est crypté, c’est justement pour que la confidentialité soit assurée. Donc, ai-je le droit de décrypter ces flux ? ».

D’un point de vue sécurité, la problématique vient de la technique utilisée : pour pouvoir intercepter les flux cryptés, il faut en fait déployer une autorité de certification sur l’ensemble des postes de travail. L’équipement de sécurité intercepte alors les flux et se fait passer pour le site distant en générant des vrais-faux certificats pour chaque site consulté. L’équipement relaie alors les demandes de l’utilisateur et les émet vers le site distant. L’équipement a donc la possibilité d’intercepter l’ensemble des trafics cryptés sortant de la société. Il devient donc un point central critique et il faut lui accorder une confiance absolue... ce qui n’est pas vraiment souhaitable.

Si l’on rejette l’idée de l’interception des flux cryptés, il ne reste plus qu’à admettre cette perte de visibilité et de contrôle sur le réseau. Une alternative existe cependant pour conserver un niveau de contrôle et de visibilité avancé sur les flux sans pour autant avoir à les déchiffrer : replacer l’individu au cœur des processus métiers.

En apportant la notion d’identité de l’utilisateur dès la demande de connexion au réseau, directement au sein de la politique de filtrage des flux, l’entreprise contrôle de façon précise et granulaire les actions des individus en fonction de leur rôle dans l’organisation. Il en résulte un gain concret en matière de protection des accès aux ressources et en matière de visibilité sur les actions initiées par les individus. Un contrôle des connexions basé sur des données immédiatement compréhensibles, telles que l’identité, améliore significativement la lisibilité des politiques de filtrage déployée. L’autorité en charge du réseau dispose alors d’éléments de réponse fiables en matière de contrôle des flux ce qui n’est pas négligeable lorsque l’on aborde la problématique de la preuve informatique dans le cadres d’affaires portées devant la justice. L’utilisateur sait pour sa part qu’il est protégé par la cryptographie, mais pas anonyme pour autant...




Voir les articles précédents

    

Voir les articles suivants