Firewall NextGen et interception SSL

co-écrit par Erwan

Les firewalls dit “next generation” proposent un mécanisme de sécurité dont l’utilisation augmente, mais qui pose un certain nombre de questions de sécurité.

Pour rappel, ces firewalls permettent d’intercepter et filtrer la navigation web, y compris en HTTPS: lors d’une demande d’accès à une ressource protégée en SSL (comme par exemple une page web en https), le firewall va générer à la volée un certificat en tout point identique au certificat originel via une autorité de certificat embarquée et propriétaire. Cette autorité ayant été préalablement trustée sur les postes utilisateurs, la connexion SSL s’établit sans avertissement de sécurité et le firewall est en mesure de déchiffrer, inspecter puis rechiffrer le trafic à destination du site web final.

La solution semble idéale sur le papier: transparence pour l’utilisateur, exhaustivité du filtrage et des contrôles sur la navigation Web.

Mais la situation n’est pas si simple…

La fin du  « petit cadenas vert dans la barre d’adresse »?

« Le petit cadenas vert  dans la barre d’adresse » est présenté comme le b.a.-ba des formations à la sécurité, et c’est une notion à laquelle les utilisateurs les moins technophiles se raccrochent. Mais l’arrivée de l’interception SSL remet en cause ce dogme, le cadenas n’étant plus synonyme d’anonymat absolu. Néanmoins, les entreprises sont tenues d’informer les utilisateurs que leur trafic internet y compris HTTPS peut être analysé automatiquement.

A partir de là, le message pour l’utilisateur est brouillé: « Comment peuvent-ils analyser alors que le cadenas est vert? » ou bien encore « comment savoir si ma navigation Web est interceptée ou non? ». Et c’est là que le bât blesse, car il est difficile d’identifier si un trafic est intercepté ou non. En apparence, il n’y aura aucun problème ou avertissement de sécurité. Le certificat aura exactement les mêmes caractéristiques que le vrai (dates, etc.). Seule l’autorité qui a émis le certificat sera différente: elle sera au nom du fournisseur de la solution comme par exemple Palo Alto. Même le nom paraîtra légitime et seul un consultant sécurité aguerri fera la différence.

La problématique des autorités trustées, du magasin de certificat et l’absence de contrôle lié

Nous l’avons vu prévu précédemment, le nœud du problème repose sur le magasin de certificats et les autorités de confiance qui y sont ajoutées, permettant ainsi une navigation apparemment sécurisée. Un pirate ayant la possibilité d’importer une chaîne de certification pirate aura beaucoup de latitude dans les attaques ultérieures.

Trending

Le recommerce

L’accès en écriture au magasin est certes bloqué pour un utilisateur Lambda, mais il est très rare que les équipes SSI réalisent des contrôles sur les autorités trustées. S’il est techniquement relativement simple d’extraire les autorités et d’en identifier les légitimes, le traitement du reste est plus complexe et doit se faire manuellement. En effet, pour chaque autorité problématique, il faudra procéder à une recherche sur la légitimité et la réputation du service, vérifier qu’il ne s’agit pas d’une autorité pirate soigneusement préparée et avec une présentation crédible.

Et maintenant, que faire?

La problématique de l’interception soulève des réponses plus larges que prévues. Comme exposée, une attention particulière devra être portée au magasin de certificats pour éviter d’éventuelles APT. Mais en parallèle des travaux avec les équipes juridiques (afin de vérifier la bonne légalité de l’interception et des informations manipulées) ainsi qu’un travail de communication adéquat auprès des utilisateurs sont nécessaires.