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
<nathan.anthonypil...@gmail.com> 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/
