Blog du grouik

tail - f /var/log/squid/access.log

Je suis relativement jeune (25 ans). Pour moi, en 2009 la question ne se pose pas, mais pour les informaticiens moins jeunes (de 5 ans), elle a du se poser.

Doit-on filtrer dans un proxy d'entreprise les flux cryptés (https, ssl ssh etc...)?

Les flux passent en clair sur internet, et sont facilement "écoutables" par un tiers (enfin je ne sais pas le faire moi). Dans les protocoles cryptés, c'est le corps des paquets qu'on crypte.

A l'origine le protocole https ne servait qu'aux moments où on devait rentrer un mot de passe: un numéro de carte bleue ou ce genre de chose pour lesquelles ça peut être gênant que l'information passe en clair. De façon générale, la mise d'un site public entier en https n'a aucun sens, il suffit d'aller sur le site pour avoir les informations.

Comme tout administrateur réseau, je dois:

• Sécuriser mon réseau, donc interdire l'accès aux sites qui pourraient être dangereux (acte intentionnel ou malencontreux de l'utilisateur qui clique sur un lien contenu dans un mail par exemple)
• Protéger les mineurs. C'est paradoxal, je travaille en gériatrie, mais il peut y avoir un stagiaire mineur, et en tirant la loi dans tous les sens: Laisser des flux contenant de la pornographie circuler dans nos infrastructures (les cables ethernet et les fibres) équivaut à sa diffusion, et c'est de tête 7 ans de prison et 40 000 € d'amende de le rendre accessible à un mineur. Je filtre donc ce qui est porno.
• Pouvoir décharger la responsabilité de mon établissement sur la personne qui a commis une infraction via la connection internet. (propos racistes incitation à la haines toussa toussa) laissés sur un forum de discussion par exemple. J'archive donc pendant un an tous les logs, des activités sur internet (enfin là je les ai effacés lors de la réinstallation du serveur). et donc aussi les logs du serveur DHCP conjointement (pour pouvoir savoir à quelle machine correspondait telle IP à tel moment) ^[1]

Je dois donc au moins filtrer et enregistrer les traces des flux (pas leur contenu). Le https ne serait que le temps de rentrer une donnée sensible (numéro de carte bancaire), je laisserai les portes grandes ouvertes pour les flux de ce genre: du forwarding direct sans passer par squid. ^[2]

La fonction de cache mise en cache est activée (ben oui, notre connexion supporterait mal la charge sinon) Des sites entiers sont en https alors que rien ne le justifie. Pour les raisons cités ci dessus, je souhaite pouvoir si nécessaire en blacklister, et enregistrer les traces de ces connexions, et comme j'ai eu la flegme de paramétrer que ça ne soit pas en cache contrairement à l'HTTP. ben... le contenu est sauvegardé (pas longtemps, juste une semaine). Ce n'est pas dramatique, vous me direz c'est crypté.... Mais comment croyez vous qu'elles sont passés les clés de cryptage? par internet. Boaf, de toutes façon, j'aurai plus vite fait de faire quelques requettes SQL dans la base de donnée du logiciel de paie si je veux vos numéros de compte en banque.

Rien de bien grave, mais ça m'ennerve de savoir que j'ai mis un truc en place qu'on peut facilement transformer en oeuil de big brother, ou réutiliser de manière malintentionnée.

La sécurité doit être proportionnelle au risque. Du moins c'est ce qui aurait du être appliqué. Les excès de zèle ont engendré les situations suivantes: Un filtrage par le contenu dans certaines écoles... Nos tetes blondes ont encapsulés leurs requetes dans des connexion https (c'est crypté, donc on ne peut pas filtrer) ou via du ssh. La pratique s'est répandue, il existe maintenant des systèmes qui ouvrent les certificats et déchiffrent les clés à la volée pour filtrer quand même. Bref, c'est la sécurité qui a permis d'en contourner une, et c'est donc sous prétexte de sécurité qu'on va casser cette dernière.... oO