Observe HTTP, HTTPS et la confiance TLS

L’idée reçue

« Le cadenas HTTPS prouve que le site est honnête. »

TLS chiffre la communication et vérifie une identité technique selon une chaîne de confiance. Il ne garantit pas que le contenu ou l’organisation derrière le site est légitime.

01Préparer le laboratoire

sudo apt update
sudo apt install -y curl tcpdump openssl python3
chmod +x module3-services-lab.sh
sudo ./module3-services-lab.sh up
sudo ip -n soria-cli addr add 10.30.0.100/24 dev eth0

02Voir HTTP en clair

Terminal web

Lance un serveur HTTP

sudo ip netns exec soria-web python3 -m http.server 8080 --bind 10.30.0.20

Terminal capture

Affiche la charge utile en ASCII

sudo tcpdump -ni br-soria-svc -A 'tcp port 8080'

Terminal client

Envoie une requête avec un Host explicite

sudo ip netns exec soria-cli curl -v http://10.30.0.20:8080/ -H 'Host: intranet.soria.test'

Dans la capture, tu peux lire GET /, l’en-tête Host et une partie de la réponse. HTTP seul ne protège pas la confidentialité.

03Créer une identité de laboratoire

openssl req -x509 -newkey rsa:2048 -nodes -days 7 -keyout /tmp/soria-lab.key -out /tmp/soria-lab.crt -subj '/CN=intranet.soria.test' -addext 'subjectAltName=DNS:intranet.soria.test'

openssl x509 -in /tmp/soria-lab.crt -noout -subject -issuer -dates -ext subjectAltName

Comprends CN, SAN et auto-signature

Le Subject Alternative Name déclare le nom couvert par le certificat. Le certificat est ici auto-signé : il peut chiffrer une session, mais aucun magasin de confiance public ne reconnaît encore son émetteur.

04Lancer HTTPS

Terminal web

Expose TLS sur 8443

sudo ip netns exec soria-web openssl s_server -accept 8443 -cert /tmp/soria-lab.crt -key /tmp/soria-lab.key -WWW

Terminal client

Observe d’abord l’échec de confiance

sudo ip netns exec soria-cli curl -v --resolve intranet.soria.test:8443:10.30.0.20 https://intranet.soria.test:8443/

L’échec est attendu : le client ne fait pas confiance à l’autorité auto-signée.

05Comparer ignorer et établir la confiance

sudo ip netns exec soria-cli curl -vk --resolve intranet.soria.test:8443:10.30.0.20 https://intranet.soria.test:8443/

sudo ip netns exec soria-cli curl -v --cacert /tmp/soria-lab.crt --resolve intranet.soria.test:8443:10.30.0.20 https://intranet.soria.test:8443/

-k désactive la vérification et ne constitue pas une correction. –cacert fournit explicitement la racine de confiance attendue pour ce laboratoire.

06Inspecter la session TLS

sudo ip netns exec soria-cli openssl s_client -connect 10.30.0.20:8443 -servername intranet.soria.test -showcerts </dev/null

Repère le certificat présenté, le nom du serveur transmis par SNI, la version TLS et la suite cryptographique négociée.

ChiffrementLe contenu devient illisible

Une capture réseau voit les paquets mais pas la requête HTTP en clair.

IdentitéLe certificat couvre un nom

Le SAN doit correspondre au nom demandé par le client.

ConfianceLe client reconnaît l’émetteur

Une chaîne valide relie le certificat à une autorité acceptée.

Panne volontaire

Demande le mauvais nom

utilise –resolve api.soria.test:8443:10.30.0.20 ;
fournis pourtant le même –cacert ;
observe l’erreur de correspondance de nom ;
explique pourquoi le chiffrement peut exister malgré l’échec d’identité ;
reviens au nom intranet.soria.test et valide.

07Nettoyer

sudo ./module3-services-lab.sh down

✓Ce que tu retiens

HTTP expose les données applicatives en clair. HTTPS ajoute TLS. Une validation correcte exige trois éléments distincts : une session chiffrée, un certificat couvrant le nom demandé et une chaîne de confiance acceptée par le client.