Discussion :

[greenkev]

Bonjour à tous ,

Dans le cadre d'un projet que je dois effectuer avec 3 autres personnes, j'ai une question à vous poser concernant le blocage du protocole HTTPS avec Squid/SquidGuard.

En effet, nous avons créé une machine Linux sous la distribution Debian version 7.0.5 (Squeeze) au sein d'un lycée.

Nous avons réussi à répondre au cahier des charges du client sauf un point qui nous pose problème : bloquer le protocole HTTPS de certains sites comme Facebook, Youtube, Youp***, etc grâce au proxy Squid+SquidGuard.

Nous avons longuement cherché comment faire mais sans aucun résultat.

Un de mes collègues qui s'est occupé de cette partie a essayé d'utiliser SSLBump mais a finit par voir que c'était illégal de l'utiliser, est-ce que vous me confirmez cela ?

Sinon il a proposé ces solutions :

Faire une règle iptables qui interdit le protocole https en intégralité --> le souci est que l'on veut interdire le protocole https pour certains sites et non tous les sites

Faire plusieurs règles iptables qui interdisent les sites par leurs noms de domaine --> mon collègue pense que le couplage nom de domaine et iptables ne fonctionnera pas

Créer un serveur DNS menteur (exemple : donner l'adresse 127.0.0.1 à facebook.com).

Est-ce qu'une de ces solutions vous paraissent bonnes à réaliser ?

Ou bien avez-vous d'autres idées pour le faire en bonne et due forme ?

En vous remerciant par avance.

greenkev

[Flodelarab]

Bonjour,

Sur le site SquidGuard.org, on peut lire SquidGuard is a URL redirector used to use blacklists; Et vous dites que vous n'arrivez pas à faire une liste noire? Faudrait ptêt essayer de comprendre la base de la base de votre outil ...
Au boulot!

Vouloir affecter l'adresse miroir 127.0.0.1 pour autre chose qu'un miroir me parait être une très mauvaise idée.

Le lycée veut certainement un blocage. Que ce soit http, https, FTP ou j'en passe. N'est-ce pas?

[greenkev]

Pour répondre à votre question, le lycée veut un blocage des sites en liste noire en http,https. Notre client nous a pas parlé de FTP mais maintenant que vous l'avez dit pourquoi pas.

On a réussi à faire les listes noires ce n'est pas le souci.

Notre souci actuel est de bloquer le protocole https de ces listes noires en gros il faut que l'on mette des règles.

Et justement, même en cherchant sur le net, nous n'avons pas trouvé les règles à appliquer pour ces listes noires.

[Invité]

Hello,

Un de mes collègues qui s'est occupé de cette partie a essayé d'utiliser SSLBump mais a finit par voir que c'était illégal de l'utiliser, est-ce que vous me confirmez cela ?

http://wiki.squid-cache.org/Features/SslBump

WARNING: HTTPS was designed to give users an expectation of privacy and security. Decrypting HTTPS tunnels without user consent or knowledge may violate ethical norms and may be illegal in your jurisdiction.

[Flodelarab]

Non mais faut pas tout confondre. Ils ne veulent pas décrypter les communications ssl. Ils veulent juste bloquer les requête https sur le port 443. Ce que fait n'importe quel outil de filtrage type firewall.

Mais je ne comprends toujours pas comment vous pouvez bloquer un site (http://site.com) et pas son équivalent ssl (https://site.com)
Dans les deux cas, l'URL est suffisante.

Qu'avez-vous écrit?
Quel a été le résultat?
Quels messages d'erreurs?

[becket]

Le niveau ip : transmis en clair ( évidemment je voudrais dire ) est lisible par n'importe quel routeur / proxy ...
Au niveau protocole : le nom de domaine du site est encapsulé dans le data et n'est pas lisible, ni par un routeur, ni par un proxy ... à priori ( sauf utilisation de Sslbump et compagnie )

[Flodelarab]

Je ne comprends pas la nuance que tu apportes.

le nom de domaine du site (...) n'est pas lisible

Comment https pourrait empêcher la correspondance entre IP et nom de domaine fournit par le DNS ?
Et si on n'a pas l'IP, comment le paquet arrive-t-il à destination ?

[becket]

C'est simple. Si www.DevellopeuseCoquine.com et www.trucmuche.com tourne sur la même adresse ip

Requete vers www.trucmuche.be Packet http => IP SRC | IP DEST | DATA ( get www.truchmuche.be )
Requete vers wwww.devellopeuseCoquine.com Packet https => IP SRC | IP DEST | DATA ( DATA CRYPTE )

[Flodelarab]

... Mais en quoi ça change sa liste noire d'URL ?...

On se moque des bidouilles des serveurs.

[becket]

Un proxy web ne bloque pas généralement une adresse ip mais un site ( le non d'une machine, un domaine, un sous-domaine ). A partir du moment ou il ne sait pas lire l'adresse ( le nom, le domaine, ... ) puisque le protocole inclus dans la requête ce nom. Le filtrage de ce protocole devient beaucoup plus difficile que l'équivalent non crypte.

Donc avant de venir nous gratifier de tes remarques assassines

Et vous dites que vous n'arrivez pas à faire une liste noire? Faudrait ptêt essayer de comprendre la base de la base de votre outil ...
Au boulot!

Non mais faut pas tout confondre. Ils ne veulent pas décrypter les communications ssl. Ils veulent juste bloquer les requête https sur le port 443.

Je te suggère de connaitre le sujet.

[Flodelarab]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 logdir /usr/local/squidGuard/log
     dbhome /usr/local/squidGuard/db
 
     src privileged {
	 ip	10.0.0.1 10.0.0.73 10.0.0.233	# ONE OF single clients
	 ip	10.0.0.10-10.0.0.20		# OR WITHIN range 10.0.0.10 - 10.0.0.20
	 ip	10.0.1.32/27			# OR WITHIN range 10.0.1.32 - 10.0.1.63
	 ip	10.0.2.0/255.255.255.0		# OR WITHIN range 10.0.2.0  - 10.0.2.255
						# AND
	 domain foo.bar				# MATCH foo.bar. OR *.foo.bar.
     }
 
     acl {
	 privileged {
	     pass all
	 }
 
	 default {
	     pass none
	     redirect http://info.foo.bar/cgi/blocked?clientaddr=%a&clientname=%n&clientuser=%i&clientgroup=%s&url=%u  
	 }
     }

[becket]

C'est une exemple du site de squidguard : http://www.squidguard.org/Doc/examples.html qui montre uniquement que squidguard est capable de prendre une décision ( autoriser l'accès ou non ) sur base du reverse DNS du client.

Puisque tu sembles persuadé qu'il est aussi simple de filtrer l'http que l'https, je ne vais pas essayer de te convaincre que ce n'est pas le cas. Par contre, je te répondrais avec plaisir si tu as une question directe.