Bonjour, Il faut voir ici le WAF comme un serveur frontal à une application, il ne s'agit pas d'inspection du trafic de navigation des utilisateurs d'une entreprise (ça pourrait, mais il y a d'autres solutions dédiées à cet usage). En fait, un WAF s'appelait simplement reverse-proxy (filtrant), avant que le marketing passe par là (bon, en théorie, ça devait effectivement fonctionner à l'image d'un firewall L4, mais en pratique, je n'ai jamais vu que le mode de fonctionnement en RP).
Donc oui, le WAF se place en rupture de session TLS. C'est son certificat (au nom de l'application protégée) qui est présenté au client final (s'il n'y a pas d'autre élément interceptant le trafic sur la route). Le 26 janvier 2015 10:03, Nathan Anthonypillai <[email protected]> a écrit : > Salut, > > Déchiffrer du TLS (SSL, c'est tabou, on en viendra tous à bout), c'est > toujours une entreprise risquée. Il n'y a (à ma connaissance) pas d'option > éthiquement acceptable dans ce domaine, à moins d'avoir le consentement > informé de toutes les parties concernées. Attention, l'application web dispose toujours des informations en clair, simplement la session TLS s'arrête sur un nouveau composant de l'infra d'hébergement. On peut remettre une couche TLS entre le WAF/RP et le serveur applicatif final, ceci dit. > > Donc soit le WAF a la clé privée du serveur et peut le >> déchiffrer/rechiffrer à la volée, > > > Ce n'est pertinent que dans les cas où la communication est chiffrée avec > la clé publique du serveur derrière le WAF. > Tu compromets donc le sécurité des communications de TOUTES les machines > contactant le serveur de façon chiffrée. > Dans ce cas autant se faire directement passer pour le serveur destination > interne dès le début (ça sera plus facile au niveau de la gestion des clés). > > >> ou le WAF possède un serveur SSL (celui >> que le client voit) il décrypte les informations et les renvoient au >> travers d'une connexion sécurisée ou non. >> > > Là, le WAF se fait passer (MITM) pour le serveur destination externe (e.g. > mabanqueenligne.com) en présentant une *fausse* clé publique. > *Attention* : si l'entité en charge du certificat X.509 du serveur > destination externe emploie un mécanisme d'audit (i.e. Google + Chrome) > gare aux répercussions, car il va vite se rendre compte qu'une entité non > autorisée se fait passer pour lui. En général, on prend le second choix. Le premier est utilisé quand le WAF reçoit une copie des flux (placé en observation, pas en interception), ce qui peut être utile notamment pour le calibrage des règles de détection au plus juste d'une application. > > >> Sachant que si on opte pour la première solution cela voudrait dire que >> le WAF possède toutes les clées SSL des clients derrières, personnellement >> je suis pas bien fan de l'idée ( votre opinion? ) >> C'est bien comme ça que ça marche, donc oui, le WAF devenant la tête de pont de l'application, c'est bien lui qui présente les certificats. > > Si les utilisateurs finaux sont d'accords, ça peut passer, mais il me > semble qu'il y a tout de même certaines communications qu'on ne doit pas > déchiffrer (à vérifier), à moins d'être habilité de ce pouvoir par le > législateur (no troll intended). > > Cordialement, > Nathan ANTHONYPILLAI > Sur les différents produits que j'ai pu apercevoir de près ou de loin, je pense à : — apache en RP avec mod_security, — DenyAll/rWeb — nginx en RP avec le module Naxsi (https://github.com/nbs-system/naxsi) Ma préférence va vers le dernier pour sa facilité de configuration (un système de scoring à la manière des antispams). Léo --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
