J'arrive un peu après le troll la bataille, mais je vais quand même rajouter mon commentaire:
C'est en effet un proxy MITM... Mais rien avoir avec une attaque... (ca je sais le faire ;)
Vis à vis de l'utilisateur, il y a tromperie, car il pense que son flux SSL ne peut pas être déchiffré, or c'est le cas ici. Je pense que c'est le genre de chose qui devrait être clairement affiché dans la charte informatique de la société, celle que l'employé signe en disant qu'il s'engage à ne pas faire mauvaise usage du système informatique. Mais par contre, il y a fort à parier qu'une telle charte soit dénoncée devant un tribunal.
Que l'admin système (ou son équipe IT), détourne ou non l'usage "sécurité" de ce proxy est un autre débat : Grand groupe ou petite société, ce sont au final toujours des être humains qui ont entre les mains des données sensibles. Et parfois, elles les utilisent à mauvais escient.
pour le fait que ce soit installé dans chaque navigateur: étonnant il y avait 200000 utilisateurs!
Alors là, aucun soucis. Exemple de techniques de déployment :
- installation de ce CA à distance, en "poussant" un patch sécurité
- utilisation de WMI pour modifier automatiquement la configuration des postes clients
- modification de la configuration, en utilisant le script de login de la machine
- ou plus simplement encore : Rajout du CA dans l'image disque des machines, en parallèle des xxx applications utilisés par cette entreprise.
Le fait que les users puissent utiliser ton proxy pour se connecter chez eux en SSH ça ce n'est pas secure!
Il faut :
- contrôller les applications installées sur la machine
- limiter les droits d'accès aux machines
- etc...
Le moindre firewall applicatif est capable d'empêcher une application qui ne serait pas dans une "white list" de se connecter à un réseau. Il suffit de définir la liste des ces applis, avec leur somme MD5/autre, afin d'empêcher un client SSH de se connecter
Après un utilisateur peut toujours sortir sa clé USB/live CD pour passer outre l'OS de la société. Dans ce cas-là, un par-feu identifiant, comme http://fr.wikipedia.org/wiki/NuFW bloquera ce live-OS non autorisé
Donc j'aimerais 2 minutes mettre les questions de "pseudos-ethiques" de côté et réfléchir à la solution technique qui pourrait remplacer un outil commercial par une solution opensource...
Idées en vrac (je précise que je ne cautionne pas ce qui est fait ici):
- pour le détournement de la requête au CA (Verisign, ou autre), il faut changer la configuration du DNS (bind9 ou autre)
- pour simuler automatiquement le CA, je ne vois pas trop. J'imagine que cela peut se faire avec un serveur Apache, plus des scripts de génération de certificat à la volée. Ou du moins : Génération d'un certificat lors de la première demande, et sauvegarde de celui-ci sur le serveur. Aux prochaines demandes, on ira piocher dans la "base de certificats" déjà généré
- pour la phase déchiffrement / chiffrement, il faut là probablement encore passer par un serveur web, qui se chargera de cela. Mais c'est du boulot...
[^] # Re: Bizarre, bizarre
Posté par Olivier (site web personnel) . En réponse au message Solution pour filtrer du contenu HTTPS. Évalué à 8.
C'est en effet un proxy MITM... Mais rien avoir avec une attaque... (ca je sais le faire ;)
Vis à vis de l'utilisateur, il y a tromperie, car il pense que son flux SSL ne peut pas être déchiffré, or c'est le cas ici. Je pense que c'est le genre de chose qui devrait être clairement affiché dans la charte informatique de la société, celle que l'employé signe en disant qu'il s'engage à ne pas faire mauvaise usage du système informatique. Mais par contre, il y a fort à parier qu'une telle charte soit dénoncée devant un tribunal.
Que l'admin système (ou son équipe IT), détourne ou non l'usage "sécurité" de ce proxy est un autre débat : Grand groupe ou petite société, ce sont au final toujours des être humains qui ont entre les mains des données sensibles. Et parfois, elles les utilisent à mauvais escient.
2 exemples récemment dans l'actualité informatique :
- un employé de facebook a utilisé ses droits d'accès privilégiés pour connaître l'identité d'un client : http://www.infos-du-net.com/actualite/17513-vie-privee.html
- des employés de SFR auraient exploités illégalement des codes de desimlockage : http://www.generation-nt.com/fraude-reseau-codes-desimlockag(...)
pour le fait que ce soit installé dans chaque navigateur: étonnant il y avait 200000 utilisateurs!
Alors là, aucun soucis. Exemple de techniques de déployment :
- installation de ce CA à distance, en "poussant" un patch sécurité
- utilisation de WMI pour modifier automatiquement la configuration des postes clients
- modification de la configuration, en utilisant le script de login de la machine
- ou plus simplement encore : Rajout du CA dans l'image disque des machines, en parallèle des xxx applications utilisés par cette entreprise.
Le fait que les users puissent utiliser ton proxy pour se connecter chez eux en SSH ça ce n'est pas secure!
Il faut :
- contrôller les applications installées sur la machine
- limiter les droits d'accès aux machines
- etc...
Le moindre firewall applicatif est capable d'empêcher une application qui ne serait pas dans une "white list" de se connecter à un réseau. Il suffit de définir la liste des ces applis, avec leur somme MD5/autre, afin d'empêcher un client SSH de se connecter
Après un utilisateur peut toujours sortir sa clé USB/live CD pour passer outre l'OS de la société. Dans ce cas-là, un par-feu identifiant, comme http://fr.wikipedia.org/wiki/NuFW bloquera ce live-OS non autorisé
Donc j'aimerais 2 minutes mettre les questions de "pseudos-ethiques" de côté et réfléchir à la solution technique qui pourrait remplacer un outil commercial par une solution opensource...
Idées en vrac (je précise que je ne cautionne pas ce qui est fait ici):
- pour le détournement de la requête au CA (Verisign, ou autre), il faut changer la configuration du DNS (bind9 ou autre)
- pour simuler automatiquement le CA, je ne vois pas trop. J'imagine que cela peut se faire avec un serveur Apache, plus des scripts de génération de certificat à la volée. Ou du moins : Génération d'un certificat lors de la première demande, et sauvegarde de celui-ci sur le serveur. Aux prochaines demandes, on ira piocher dans la "base de certificats" déjà généré
- pour la phase déchiffrement / chiffrement, il faut là probablement encore passer par un serveur web, qui se chargera de cela. Mais c'est du boulot...