Dans notre précédent article sur Squid, nous avons décrit en détail la configuration d’un serveur proxy cache HTTP. Dans l’état actuel des choses, le serveur ne gère pas du tout les connexions HTTPS. Étant donné que l’écrasante majorité des sites web populaires utilisent un protocole sécurisé, nous n’avons fait qu’une partie du travail. Cet article sera donc consacré à la gestion des requêtes HTTPS.
Introduction
Depuis la version 3.5, Squid offre une fonctionnalité qui s’appelle le SSL-Bump. Notre démarche consistera à créer un certificat racine que l’on exportera vers les navigateurs web du réseau. Lorsque ceux-ci se connecteront sur un site HTTPS, ce trafic sera dévié vers un deuxième port de Squid, et le serveur générera un certificat dynamique.
La documentation officielle est malheureusement quelque peu laconique et pas toujours très claire, mais on arrive à faire fonctionner le tout avec une bonne dose d’obstination et d’expérimentation.
Implications éthiques
Strictement parlant, l’analyse des flux HTTPS telle que nous la pratiquons ici n’est rien d’autre qu’une attaque MIDM (Man In The Middle). La documentation de Squid contient d’ailleurs la mise en garde suivante.
On the ethical side; consider some unknown other person reading all your private communications. What would you be happy with them doing? Be considerate of others.
L’Agence nationale de la sécurité des systèmes d’information offre une page d’informations sur l’analyse des flux HTTPS. La problématique à laquelle nous sommes confrontés est résumée dans le passage suivant.
L’analyse d’un contenu (web par exemple) sécurisé à l’aide de TLS, peut toutefois se justifier afin de s’assurer que les données provenant d’un réseau non maîtrisé (Internet par exemple) ne représentent pas une menace pour le système d’information interne. Les architectures visant à déchiffrer les flux TLS, pour permettre leur analyse, « tordent » donc le modèle pour lequel ce protocole est conçu.
Avant de mettre en œuvre cette solution dans une entreprise, une école ou une médiathèque, il s’agit donc d’être conscient de ces implications et de prendre les mesures légales nécessaires sous forme d’une clause au contrat et d’une page d’accueil explicative qui détaillent ce qui se passe sous le capot.
Vérifier les options de compilation
Squid doit impérativement être compilé avec les options suivantes :
./configure \
--with-openssl \
--enable-ssl-crtd \
...
Le paquet binaire fourni par Red Hat Enterprise Linux 8 et Rocky Linux 8 est parfaitement utilisable tel quel. La commande squid -v affiche l’ensemble des options de compilation de l’application :
# squid -v | grep -E '(--with-openssl|--enable-ssl-crtd)' > /dev/null && echo OK OK
Configuration du pare-feu
Dans notre première configuration de Squid comme proxy cache transparent HTTP, nous avons redirigé les requêtes HTTP (port 80) vers le port 3128 de Squid. Pour utiliser le HTTPS, ce sera un peu plus compliqué :
- Les requêtes vers le port 80 seront redirigées vers le port 3128.
- Les requêtes vers le port 443 seront redirigées vers le port 3129.
- Squid intercepte à son tour ces requêtes et utilise le port 3130 en interne.
Voici à quoi pourra ressembler concrètement la configuration du pare-feu :
# firewall-cmd --permanent --add-service=squid
# firewall-cmd --permanent \
--add-forward-port=port=80:proto=tcp:toport=3128:toaddr=192.168.3.1
# firewall-cmd --permanent \
--add-forward-port=port=443:proto=tcp:toport=3129:toaddr=192.168.3.1
# firewall-cmd --permanent --add-port=3129/tcp
# firewall-cmd --reload
# firewall-cmd --list-all
internal (active)
target: default
icmp-block-inversion: no
interfaces: enp2s0
sources:
services: dhcp dns squid ssh
ports: 3129/tcp
protocols:
forward: no
masquerade: yes
forward-ports:
port=80:proto=tcp:toport=3128:toaddr=192.168.3.1
port=443:proto=tcp:toport=3129:toaddr=192.168.3.1
source-ports:
icmp-blocks:
rich rules:
Les deux premières règles concernant l’ouverture du port 3128 pour Squid et la redirection des requêtes HTTP vers ce port sont peut-être déjà en vigueur. Quant à l’adresse IP 192.168.3.1, c’est celle de l’interface réseau côté LAN du proxy.
Créer un certificat racine auto-signé
Le certificat racine sera utilisé par Squid pour générer à la volée les certificats dynamiques pour les sites qui passent par le proxy. Notez que par là, nous devenons une autorité de certification pour le réseau local.
Dans un premier temps, on va trouver un endroit approprié pour stocker le certificat. Les permissions seront définies en fonction de l’utilisateur système squid et du groupe système squid correspondant :
# cd /etc/squid/ # mkdir -v ssl_cert mkdir: created directory 'ssl_cert' # chown squid:squid ssl_cert/ # cd ssl_cert/
Ensuite, on va créer le certificat en fournissant les informations nécessaires :
- Notre certificat sera valable pour dix ans (
-days 3650). - La rubrique Common Name devra correspondre au nom d’hôte pleinement qualifié de la machine (
hostname --fqdn). - Le fichier résultant sera nommé
certificat.pem.
Voici à quoi cela peut ressembler :
# openssl req -new -newkey rsa:4096 -sha256 -days 3650 -nodes -x509 \ -extensions v3_ca -keyout certificat.pem -out certificat.pem Generating a RSA private key .......................++++ .........++++ writing new private key to 'certificat.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [XX]:FR State or Province Name (full name) []:Gard Locality Name (eg, city) [Default City]:Montpezat Organization Name (eg, company) [Default Company Ltd]:Microlinux Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) []:squidbox.sandbox.lan Email Address []:info@microlinux.fr
Ensuite, créer un certificat encodé en DER (Distinguished Encoding Rules) que l’on pourra importer dans les navigateurs web des postes clients :
# openssl x509 -in certificat.pem -outform DER -out certificat.der
Au final, on obtient deux fichiers qui ressemblent à ceci :
# ls -lh total 12K -rw-r--r--. 1 root root 1.5K Mar 8 10:08 certificat.der -rw-------. 1 root root 5.3K Mar 8 10:01 certificat.pem
Importer le certificat dans les navigateurs
Le fichier certificat.der devra être distribué aux postes clients, et le certificat devra être installé manuellement dans les navigateurs web.
Pour Mozilla Firefox, ouvrez Paramètres > Vie privée et sécurité > Certificats > Afficher les certificats. Vérifiez que vous êtes bien dans l’onglet Autorités et cliquez sur Importer :
Sélectionnez le fichier certificat.der et cochez les options proposées :
Le certificat apparaît désormais dans la liste des Autorités, sous le nom que l’on a choisi à la rubrique Organization Name:
Certains navigateurs web comme Edge sous Microsoft Windows ou Safari sous macOS vous font sauter à travers des cerceaux en feu pour importer manuellement un certificat local. Une raison de plus pour les éviter.
Ajouter le certificat au client
Dans le réseau de notre lycée local, l’ajout manuel du certificat dans chaque session individuelle de Firefox serait une tâche assez fastidieuse, sans compter qu’il faudrait faire la même chose pour Mozilla Thunderbird. Pour éviter cette corvée, la meilleure solution consiste à importer le certificat en l’ajoutant à la panoplie de CA du système :
# cp -v certificat.der /etc/pki/ca-trust/source/anchors/ 'certificat.der' -> '/etc/pki/ca-trust/source/anchors/certificat.der' # update-ca-trust
Adapter la configuration de Squid
Pour la configuration de Squid, je me suis basé sur l’exemple fourni dans la documentation officielle, en l’adaptant à mes besoins :
# Ports http_port 3130 http_port 3128 intercept https_port 3129 intercept ssl-bump \ cert=/etc/squid/ssl_cert/certificat.pem \ generate-host-certificates=on \ dynamic_cert_mem_cache_size=64MB # SSL certificate generation sslcrtd_program /usr/lib64/squid/security_file_certgen -s /var/spool/squid/ssl_db -M 64MB sslcrtd_children 32 startup=5 idle=1 # SSL-Bump acl step1 at_step SslBump1 ssl_bump peek step1 ssl_bump bump all
J’initialise le cache qui contiendra les certificats créés à la volée :
# runuser -u squid -- /usr/lib64/squid/security_file_certgen \ -c -s /var/spool/squid/ssl_db -M 64MB Initialization SSL db... Done # tree /var/spool/squid/ssl_db/ /var/spool/squid/ssl_db/ ├── certs ├── index.txt └── size 1 directory, 2 files
Il ne reste plus qu’à redémarrer Squid :
# systemctl restart squid
Vérifier le fonctionnement
À présent, l’état du service doit ressembler à quelque chose comme ceci :
# systemctl status squid
● squid.service - Squid caching proxy
Loaded: loaded (/usr/lib/systemd/system/squid.service;
enabled; vendor preset: disabled)
Active: active (running) since Fri 2024-03-08 11:32:47 CET; 31s ago
Docs: man:squid(8)
Process: 2417 ExecStartPre=/usr/libexec/squid/cache_swap.sh
(code=exited, status=0/SUCCESS)
Main PID: 2425 (squid)
Tasks: 8 (limit: 24698)
Memory: 22.5M
CGroup: /system.slice/squid.service
├─2425 /usr/sbin/squid --foreground -f /etc/squid/squid.conf
├─2427 (squid-1) --kid squid-1 --foreground -f /etc/squid/squid.conf
├─2428 (security_file_certgen) -s /var/spool/squid/ssl_db -M 64MB
├─2429 (security_file_certgen) -s /var/spool/squid/ssl_db -M 64MB
├─2430 (security_file_certgen) -s /var/spool/squid/ssl_db -M 64MB
├─2431 (security_file_certgen) -s /var/spool/squid/ssl_db -M 64MB
├─2432 (security_file_certgen) -s /var/spool/squid/ssl_db -M 64MB
└─2433 (logfile-daemon) /var/log/squid/access.log
Pour vérifier le fonctionnement du proxy pour les protocoles HTTP et HTTPS, il suffit de naviguer au hasard sur des sites sécurisés et non sécurisés, en gardant un œil sur le contenu du journal /var/log/squid/access.log :
# tail -f /var/log/squid/access.log ... 192.168.3.2 TCP_MISS/404 3428 GET https://www.journalduhacker.net/favicon.ico ... 192.168.3.2 TCP_MISS/404 3428 GET https://www.journalduhacker.net/apple-touch-icon-144.png ... ... 192.168.3.2 TCP_MISS/200 2679 GET http://www.slackware.com/config/ ... 192.168.3.2 TCP_MISS/200 2768 GET http://www.slackware.com/info/ ...
Désactiver le proxy en cas de blocage
Une fois que le proxy est mis en place pour les protocoles HTTP et HTTPS, il est impossible de le contourner. En cas de problème, c’est bien de savoir comment désactiver le proxy – du moins temporairement – pour ne pas rester bloqué.
Concrètement, il suffit de supprimer la redirection des ports dans le pare-feu :
# firewall-cmd --permanent \ --remove-forward-port=port=80:proto=tcp:toport=3128:toaddr=192.168.3.1 # firewall-cmd --permanent \ --remove-forward-port=port=443:proto=tcp:toport=3129:toaddr=192.168.3.1 # firewall-cmd --reload
Notre prochain article sera consacré à la gestion des sites qui peuvent poser problème.
La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.
0 commentaire