Je ne suis pas sur que SSLBump soit forcément illégal. Ce mécanisme de "man in the middle" est d'ailleurs assez couramment utilisé en entreprise pour permettre d'utiliser les filtres "standard" (filtrage du contenu, antivirus, ...) sur les flux HTTPS (avec, éventuellement, des listes blanches de sites pour lesquels il n'y a pas de déchiffrement SSL, comme les sites des banques ou des institutions gouvernementales).
[notez que je ne porte pas de jugement sur cette pratique]
Il y a cependant des contraintes, techniques et administratives :
- il faut (faudrait ?) informer les utilisateurs que le flux HTTPS est déchiffré au niveau du proxy, en fournissant l'éventuelle liste blanches des services non impactés ;
- il y a peut-être une déclaration à faire auprès de la CNIL, en fonction des informations qui sont conservées, voire exploitées ;
- le proxy génère un certificat signé par son AC pour les sites visités et c'est ce certificat qui est visible côté client. Il faut donc distribuer le certificat de l'AC sur tous les postes utilisateurs (et tous les navigateurs) pour éviter les alertes de sécurité ;
- il n'y a plus moyen, au niveau du poste client, d'accepter un certificat serveur non validé par le navigateur (certificat auto-signé ou signé par une AC non reconnue) : le certificat réel du serveur n'est vu qu'au niveau du proxy. Donc soit le proxy accepte tous les certificats (→faille de sécurité), soit il rejette tous les certificats qu'il ne peut pas valider (dans ce cas, il ne faut pas oublier d'ajouter l'AC CACERT pour que les lycéens puissent mouler sur linuxfr.org !) [il semblerait que ce problème soit en partie résolu/contourné à partir de la version 3.3 de squid]
Mais bon, je suis aussi intéressé si quelqu'un a une autre méthode à proposer.
# SSLBump
Posté par JJD . En réponse au message Bloquer certains sites en https avec Squid/SquidGuard. Évalué à 4.
Salut,
Je ne suis pas sur que SSLBump soit forcément illégal. Ce mécanisme de "man in the middle" est d'ailleurs assez couramment utilisé en entreprise pour permettre d'utiliser les filtres "standard" (filtrage du contenu, antivirus, ...) sur les flux HTTPS (avec, éventuellement, des listes blanches de sites pour lesquels il n'y a pas de déchiffrement SSL, comme les sites des banques ou des institutions gouvernementales).
[notez que je ne porte pas de jugement sur cette pratique]
Il y a cependant des contraintes, techniques et administratives :
- il faut (faudrait ?) informer les utilisateurs que le flux HTTPS est déchiffré au niveau du proxy, en fournissant l'éventuelle liste blanches des services non impactés ;
- il y a peut-être une déclaration à faire auprès de la CNIL, en fonction des informations qui sont conservées, voire exploitées ;
- le proxy génère un certificat signé par son AC pour les sites visités et c'est ce certificat qui est visible côté client. Il faut donc distribuer le certificat de l'AC sur tous les postes utilisateurs (et tous les navigateurs) pour éviter les alertes de sécurité ;
- il n'y a plus moyen, au niveau du poste client, d'accepter un certificat serveur non validé par le navigateur (certificat auto-signé ou signé par une AC non reconnue) : le certificat réel du serveur n'est vu qu'au niveau du proxy. Donc soit le proxy accepte tous les certificats (→faille de sécurité), soit il rejette tous les certificats qu'il ne peut pas valider (dans ce cas, il ne faut pas oublier d'ajouter l'AC CACERT pour que les lycéens puissent mouler sur linuxfr.org !) [il semblerait que ce problème soit en partie résolu/contourné à partir de la version 3.3 de squid]
Mais bon, je suis aussi intéressé si quelqu'un a une autre méthode à proposer.