TD4 - HTTP, HTTPS, TLS & certificats¶
Duree : 2h | Par groupe
Prerequis : CM4 - HTTP, HTTPS, TLS Rendu : depot Forgejo Outils : papier-crayon, Wireshark, OpenSSL, navigateur web
Objectifs¶
- Lire et decortiquer une requete HTTP brute, et comprendre pourquoi tout y circule en clair
- Situer TLS dans la pile reseau et connaitre les ports
- Reconstituer un handshake TLS et lire une cipher suite
- Comprendre la chaine de confiance des certificats X.509
- Savoir ce que le cadenas garantit... et ce qu'il ne garantit pas
- Parler HTTP en ligne de commande avec
curl(GET, POST, PUT, DELETE...) et crafter une requete a la main avecnc(netcat) - Observer le handshake TLS en direct via
curl -v - Capturer du trafic HTTP puis HTTPS avec Wireshark et constater la difference
- Generer un certificat auto-signe avec OpenSSL et inspecter une vraie chaine de certificats
Exercices sur papier¶
A la main
Les exercices 1 a 5 se font sans ordinateur. La table base64 necessaire est en annexe.
Exercice 1 - Anatomie d'une requete HTTP¶
Quand tu remplis un formulaire de login sur un site en http://, ton navigateur envoie ceci sur le reseau, tel quel, en clair :
POST /connexion HTTP/1.1
Host: intranet.isen.fr
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:120.0)
Accept: text/html,application/xhtml+xml
Cookie: session=8f3a2b; theme=sombre
Authorization: Basic Ym9iOjEyMzQ=
Content-Type: application/x-www-form-urlencoded
Content-Length: 41
login=bob.martin&motdepasse=Pr1ntemps2025
Question 1 - La ligne de requete
Donner la methode, le chemin demande et la version HTTP (premiere ligne).
Question 2 - Les en-tetes
a) Quelle est la valeur de l'en-tete Host ?
b) Combien de cookies le navigateur renvoie-t-il, et lesquels ?
Question 3 - Le corps de la requete
La derniere ligne est le body du POST. Quels sont le login et le mot de passe envoyes ? Que remarque-t-on sur leur protection ?
Question 4 - Decoder l'en-tete Authorization
L'en-tete Authorization: Basic contient identifiant:mot_de_passe encode en base64. Le base64 regroupe les bits par paquets de 6 et les traduit avec la table en annexe.
Exemple resolu - decoder Ym9i :
| caractere | Y |
m |
9 |
i |
|---|---|---|---|---|
| index base64 | 24 | 38 | 61 | 34 |
| 6 bits | 011000 |
100110 |
111101 |
100010 |
On recolle les 24 bits et on les recoupe en octets de 8 :
01100010 01101111 01100010 = 0x62 0x6F 0x62 = b o b.
→ Ym9i se decode en bob.
A vous : decoder le reste, OjEyMzQ= (le = est du remplissage, on l'ignore). En deduire l'identifiant complet transmis dans l'en-tete Authorization.
Question 5 - Conclusion
Le base64 est-il du chiffrement ? Que faut-il pour le « casser » ? Qu'est-ce que cela dit de la securite de HTTP ?
Question 6 - A quoi sert base64 ?
Si ce n'est pas du chiffrement, a quoi sert base64 alors ? Pourquoi encoder bob:1234 en Ym9iOjEyMzQ= plutot que de l'envoyer tel quel ? (Indice : pense aux caracteres qu'un en-tete HTTP peut contenir - lettres, chiffres, ponctuation ASCII - et a ceux qu'il ne peut pas transporter sans casser le format : retours a la ligne, octets non imprimables, caracteres reserves...)
Exercice 2 - La pile reseau : ou se place TLS¶
Question 1 - Placer TLS
Voici la pile reseau pour une page web classique. Recopier le schema et placer TLS au bon endroit (HTTPS = HTTP over TLS) :
+-------------------+
| HTTP | <- la page web
+-------------------+
| ? | <- a placer
+-------------------+
| TCP |
+-------------------+
| IP |
+-------------------+
Question 2 - Ports et confidentialite
Completer le tableau :
| Protocole | Port standard | Donnees sur le reseau |
|---|---|---|
| HTTP | ? | en clair / chiffrees ? |
| HTTPS | ? | en clair / chiffrees ? |
Question 3 - Confidentialite des requetes DNS (DoT, DoH)
Avant meme d'ouvrir une connexion TLS vers intranet.isen.fr, ton navigateur doit traduire ce nom en adresse IP : il envoie une requete DNS. Historiquement, cette requete part en clair sur le port 53, meme quand le site final est en HTTPS. Resultat : un attaquant sur le reseau (ou ton FAI) sait quels sites tu visites avant que TLS demarre.
Deux protocoles modernes chiffrent les requetes DNS :
- DoT (DNS over TLS) : la requete DNS est encapsulee dans une session TLS dediee.
- DoH (DNS over HTTPS) : la requete DNS est envoyee comme une requete HTTPS normale.
a) Completer le tableau :
| Protocole | Port standard | Donnees sur le reseau |
|---|---|---|
| DNS (classique) | ? | en clair / chiffrees ? |
| DoT | ? | en clair / chiffrees ? |
| DoH | ? | en clair / chiffrees ? |
b) Pourquoi DoH est-il plus difficile a bloquer ou a filtrer pour un FAI ou un admin reseau que DoT ? (Indice : compare leurs ports, et demande-toi ce qu'il faudrait bloquer pour empecher chacun sans casser le reste du trafic web.)
c) Meme avec DoT ou DoH plus HTTPS, le nom du site visite peut encore fuiter en clair au tout debut du handshake TLS. A quel endroit ? (Tu confirmeras a la question 5.)
Question 4 - L'evolution de HTTP
Completer la colonne « Transport » :
| Version | Annee | Transport | Grande nouveaute |
|---|---|---|---|
| HTTP/1.1 | 1997 | ? | Keep-alive, pipelining |
| HTTP/2 | 2015 | ? | Binaire, multiplexage |
| HTTP/3 | 2022 | ? | Plus de TCP, 0-RTT, resistant aux pertes |
Question 5 - Ce que voit quand meme un attaquant
Un attaquant sur le reseau (WiFi public) capture ton trafic HTTPS. Il ne peut pas lire le contenu des pages. Mais parmi les elements suivants, lesquels reste-t-il capable d'observer ?
- a) ton mot de passe
- b) l'adresse IP du serveur que tu contactes
- c) le nom de domaine demande (indice : champ SNI du
ClientHello, envoye avant le chiffrement) - d) la taille et le rythme des paquets echanges
- e) le contenu de la page renvoyee
Exercice 3 - Le handshake TLS¶
Question 1 - Remettre le handshake dans l'ordre (TLS 1.2)
Voici les 9 messages d'un handshake TLS 1.2, dans le desordre. Les remettre dans l'ordre chronologique en notant les lettres.
| Lettre | Message | Emetteur |
|---|---|---|
| A | Finished |
Serveur |
| B | ClientHello |
Client |
| C | ClientKeyExchange |
Client |
| D | ServerHelloDone |
Serveur |
| E | Finished |
Client |
| F | Certificate |
Serveur |
| G | ChangeCipherSpec |
Client |
| H | ServerHello |
Serveur |
| I | ChangeCipherSpec |
Serveur |
Question 2 - Round-trips
Combien d'allers-retours (round-trips) le client doit-il attendre avant de pouvoir envoyer sa premiere requete HTTP chiffree ?
Question 3 - Le certificat
Quel message transporte le certificat du serveur ? A quoi sert-il dans le handshake (que verifie le client grace a lui) ?
Question 4 - TLS 1.3
En TLS 1.3, le ServerHello transporte deja le key_share, le Certificate et le Finished du serveur.
a) Combien de round-trips faut-il alors avant d'envoyer des donnees ?
b) Citer deux elements supprimes en TLS 1.3 par rapport a TLS 1.2 (indice : CM4 - algorithmes faibles, echange de cle RSA statique...).
Question 5 - Lire une cipher suite
Pendant le handshake, client et serveur se mettent d'accord sur une cipher suite. En voici une, courante en TLS 1.2 :
Associer chaque morceau a son role, et au CM correspondant :
| Morceau | Role ? | Vu au CM ? |
|---|---|---|
ECDHE |
? | ? |
RSA |
? | ? |
AES_128_GCM |
? | ? |
SHA256 |
? | ? |
Exercice 4 - Echange RSA vs DH ephemere : Perfect Forward Secrecy¶
Deux clients TLS 1.2 se connectent au meme serveur, qui possede une cle privee RSA et un certificat. Selon la cipher suite negociee, l'echange de cle de session est radicalement different.
Scenario A - TLS_RSA_WITH_AES_128_CBC_SHA (echange de cle RSA dit « statique »)
ClientHello,ServerHello.- Le serveur envoie son
Certificate(qui contient sa cle publique RSApk). - Le client tire un secret aleatoire PMS (pre-master secret).
- Le client envoie
ClientKeyExchange = E_pk(PMS): il chiffre le PMS avec la cle publique RSA du serveur. - Le serveur dechiffre avec sa cle privee
sket recupere le PMS. - Les deux derivent une cle de session AES a partir du PMS et chiffrent l'echange HTTP.
Scenario B - TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (DH ephemere + signature RSA)
ClientHello,ServerHello.- Le serveur envoie son
Certificate(memepkque precedemment). - Le serveur tire une paire DH ephemere
(a, A = g^a mod p), envoieAdansServerKeyExchangeet signe ces parametres avec sa cle privee RSAsk. - Le client tire
(b, B = g^b mod p), envoieBdansClientKeyExchange. - Les deux calculent
PMS = g^(a*b) mod p(Diffie-Hellman, vu en TD3). - Cle de session AES derivee du PMS.
aetbsont detruits apres la session.
Question 1 - A quoi sert la cle privee RSA du serveur ?
Dans chaque scenario, la cle privee sk du serveur est utilisee. Mais elle ne sert pas a la meme chose. Pour quoi exactement ?
a) Scenario A : sk sert a ___
b) Scenario B : sk sert a ___
Question 2 - Mallory l'enregistreuse
Mallory ecoute passivement le reseau et stocke sur un disque tout le trafic HTTPS chiffre du site pendant un an. Elle n'a pas la cle. Un an plus tard, un employe vereux du site lui vend la cle privee RSA du serveur. Le certificat n'a pas ete change.
a) Scenario A : Mallory peut-elle dechiffrer le trafic enregistre il y a un an ? Decrire la chaine d'etapes (qu'extrait-elle des captures, que fait-elle avec sk, comment retrouve-t-elle la cle de session) ?
b) Scenario B : meme question. Mallory voit A = g^a et B = g^b dans les captures, mais ne connait ni a ni b. La cle sk lui sert-elle a quelque chose ici ? (Indice : le logarithme discret est-il facile a calculer ?)
Question 3 - Definir la Perfect Forward Secrecy
PFS (Perfect Forward Secrecy) : la compromission de la cle privee a long terme du serveur ne permet pas de dechiffrer les sessions chiffrees dans le passe.
Lequel des deux scenarios assure la PFS ? Pourquoi l'autre ne l'assure-t-il pas ?
Question 4 - Pourquoi « forward » ?
On protege le passe (les sessions deja capturees) mais le terme est « forward secrecy ». Du point de vue du secret de session (PMS = g^ab en scenario B), peut-il etre retrouve plus tard a partir d'une cle compromise ? On dit « forward » parce que le secret de session ne se propage pas vers le futur : meme en attendant 10 ans avant de compromettre sk, le PMS de la session d'hier reste hors d'atteinte.
Question 5 - TLS 1.3
TLS 1.3 a supprime l'echange de cle RSA statique. Il ne reste que DH ephemere (ECDHE en pratique). Quelle propriete cela rend-il obligatoire pour toute connexion TLS 1.3 ?
Question 6 - Et les sessions futures ?
Apres la compromission, le serveur continue d'utiliser la meme cle privee.
a) Scenario A : que peut faire Mallory sur les prochaines sessions ?
b) Scenario B : la PFS protege-t-elle aussi les sessions futures ? Que peut faire Mallory de plus grave avec sk, meme sans dechiffrer le trafic ? (Indice : signer = se faire passer pour le serveur, MITM actif possible.)
A retenir : la PFS protege le passe, pas le futur. Quand une cle long terme tombe, il faut revoquer et changer la cle au plus vite. Sans PFS, en revanche, des annees de trafic enregistre s'effondrent d'un coup le jour ou la cle fuit - scenario peu hypothetique a l'heure des collectes massives.
Exercice 5 - Le cadenas : ce qu'il garantit (et pas)¶
Pour chaque scenario, indiquer si le cadenas HTTPS te protege ou non, et en une phrase pourquoi.
| # | Scenario | Le cadenas protege ? |
|---|---|---|
| a | Un attaquant sur le WiFi public capture ton trafic et veut lire ton mot de passe. | ? |
| b | Tu te connectes a https://paypa1.com (faux site, le l est un 1), cadenas vert affiche. |
? |
| c | Le site est legitime mais stocke ton mot de passe en clair dans sa base de donnees, qui se fait voler. | ? |
| d | Un attaquant tente de modifier la page renvoyee par le serveur pendant son transit. | ? |
| e | Une attaque DNS te redirige vers un faux serveur qui presente un certificat auto-signe. | ? |
Anecdote : en 2018, 49 % des sites de phishing utilisaient deja HTTPS. Le cadenas n'a jamais voulu dire « site de confiance ».
Exercices sur PC¶
Setup
Les exercices 6 a 9 (nc, curl) ciblent deux services heberges par le prof :
safe.isen-cyber.ovh: echo HTTP/HTTPS (httpbin) avec un certificat valide (Let's Encrypt). Sert pour les requetes en clair (port 80) et le handshake TLS observable (port 443).unsafe.isen-cyber.ovh: meme contenu mais expose avec un certificat auto-signe -> ton navigateur affichera « Votre connexion n'est pas privee ».
Les exercices 10 et 11 (Wireshark) ciblent la page de login safe.isen-cyber.ovh/login, accessible en HTTP (port 80) et en HTTPS (port 443). Identifiants de demo : alice / motdepasse123. Si le reseau est defaillant, des captures pcap de backup sont fournies dans captures/backup_http.pcapng et captures/backup_https.pcapng.
Exercice 6 - nc : crafter sa requete HTTP a la main¶
Fichier : nc_requests.sh.
nc (netcat) ouvre une connexion TCP brute. Avec lui, plus de magie : on ecrit la requete HTTP et on lit la reponse octet par octet. La meilleure facon de constater que HTTP, c'est juste du texte sur du TCP.
Q1 - Ton premier GET a la main
printf 'GET / HTTP/1.1\r\nHost: safe.isen-cyber.ovh\r\nConnection: close\r\n\r\n' | nc safe.isen-cyber.ovh 80
Trois choses essentielles :
\r\n: HTTP exige des fins de ligne CRLF (retour chariot + saut de ligne), pas seulement\n.Host: safe.isen-cyber.ovh: obligatoire en HTTP/1.1 - un meme serveur peut heberger plusieurs sites sur la meme IP (virtual hosts).Connection: close: sans ca, le serveur garde la connexion ouverte (keep-alive) etncsemble bloquer.
A noter dans le README :
- la ligne de statut (
HTTP/1.1 200 OK) - les en-tetes principaux (
Content-Type,Content-Length,Server) - les premiers caracteres du body HTML
Q2 - Mode interactif
Tape la requete a la main et termine par une ligne vide :
Selon le terminal, ca peut envoyer \n au lieu de \r\n ; safe.isen-cyber.ovh tolere les deux, mais certains serveurs sont stricts.
Q3 - Crafter un POST
Pour un POST il faut un body et declarer sa taille exacte avec Content-Length. Si la taille est fausse, le serveur attend (timeout) ou rejette.
# 1. Verifier la taille exacte du body (en octets)
echo -n 'login=bob&id=1234' | wc -c
# -> 17
# 2. Envoyer le POST a safe.isen-cyber.ovh (qui echo en JSON ce qu'il recoit)
printf 'POST /post HTTP/1.1\r\nHost: safe.isen-cyber.ovh\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length: 17\r\nConnection: close\r\n\r\nlogin=bob&id=1234' | nc safe.isen-cyber.ovh 80
Verifier que le champ form du JSON renvoye contient bien {"id": "1234", "login": "bob"}.
Q4 - Oublier l'en-tete Host
Quel code de statut le serveur renvoie-t-il ? Pourquoi Host est-il obligatoire en HTTP/1.1 mais ne l'etait pas en HTTP/1.0 ?
Q5 - Reflexion : que vaut un User-Agent ?
printf 'GET /headers HTTP/1.1\r\nHost: safe.isen-cyber.ovh\r\nUser-Agent: Chrome-de-papi-1995\r\nConnection: close\r\n\r\n' | nc safe.isen-cyber.ovh 80
httpbin renvoie ton User-Agent bidon sans broncher. En deduire :
- a) quelle confiance accorder aux statistiques de navigateur publiees par les sites web ?
- b) ce que vaut une protection anti-bot basee uniquement sur le
User-Agent? - c) comment les sites identifient-ils vraiment leurs visiteurs ? (indice : les cookies vus a l'exercice 1)
Pourquoi c'est important
Si tu peux ecrire HTTP a la main avec nc, alors n'importe qui peut le faire - y compris un script malveillant. Tout ce que ton navigateur envoie est falsifiable. La seule protection sur le contenu vient de TLS + certificat ; sur l'identite de l'utilisateur, d'un secret partage (mot de passe, cookie de session, token) - qui a tout interet a voyager en HTTPS.
Exercice 7 - curl : premieres requetes HTTP¶
Fichier : curl_cmds.sh (Partie A).
Apres avoir construit HTTP a la main avec nc, place a l'outil de tous les jours : curl est la ligne de commande standard pour parler HTTP. Bien plus confortable que nc (TCP, CRLF, Content-Length geres automatiquement), il reste tres expressif pour tester une API, debugger un site, ou voir ce qui circule sur le reseau.
Q1 - Le GET le plus simple
curl recupere la page et l'affiche. Mais ce qu'on veut voir, c'est la requete envoyee et la reponse recue, en details.
Q2 - Mode verbeux : -v
Trois prefixes dans la sortie :
*: information de connexion (DNS, TCP, TLS...)>: ligne envoyee (la requete HTTP)<: ligne recue (la reponse HTTP)
A noter dans le README :
- la ligne de requete (premiere ligne
>) - les en-tetes ajoutes automatiquement par curl
- la ligne de statut (premiere ligne
<) - la version HTTP utilisee
Comparer avec ce que tu as ecrit a la main a l'exercice 6 : retrouves-tu les memes en-tetes (Host, User-Agent, Accept...) ?
Q3 - Echo de la requete avec safe.isen-cyber.ovh
safe.isen-cyber.ovh est un endpoint public qui renvoie en JSON ce qu'il a recu : tres pratique pour voir exactement ce qu'on envoie.
# Renvoie l'integralite de la requete recue
curl http://safe.isen-cyber.ovh/get
# Affiche uniquement les en-tetes recus par le serveur
curl http://safe.isen-cyber.ovh/headers
# Ajouter un en-tete custom
curl -H "Accept: application/json" -H "X-Etudiant: groupe-A" http://safe.isen-cyber.ovh/headers
Quels en-tetes curl envoie-t-il par defaut, sans qu'on les demande ?
Q4 - Parametres de requete (query string)
Ou retrouve-t-on nom=alice et ville=toulon dans la reponse JSON ? Font-ils partie de l'URL ou du body ? (Indice : regarder le champ args du JSON.)
Options utiles
-s (silent) supprime la barre de progression ; -i affiche les en-tetes recus ; -o fichier ecrit la reponse dans un fichier.
Exercice 8 - Les methodes HTTP¶
Fichier : curl_cmds.sh (Partie B).
HTTP definit plusieurs methodes (ou verbes), chacune avec une semantique propre :
| Methode | Role | Idempotente ? | Safe ? |
|---|---|---|---|
GET |
Lire une ressource | Oui | Oui |
HEAD |
Comme GET, en-tetes seuls | Oui | Oui |
POST |
Creer / soumettre / declencher | Non | Non |
PUT |
Remplacer entierement | Oui | Non |
PATCH |
Modifier partiellement | Non | Non |
DELETE |
Supprimer | Oui | Non |
OPTIONS |
Demander les capacites | Oui | Oui |
- Safe : ne modifie rien cote serveur (lecture seule).
- Idempotente : appeler N fois = appeler 1 fois (meme effet final).
safe.isen-cyber.ovh offre un endpoint par methode, qui echo en JSON ce qu'il a recu.
Q1 - POST : envoyer un formulaire
Dans la reponse JSON : ou apparait login=bob ? Quel Content-Type curl a-t-il ajoute automatiquement ?
Q2 - PUT avec un body JSON
curl -X PUT \
-H "Content-Type: application/json" \
-d '{"titre":"nouveau"}' \
http://safe.isen-cyber.ovh/put
Le body apparait-il dans le meme champ JSON qu'a la Q1 ? (Indice : regarder form vs data/json.)
Q3 - DELETE
Y a-t-il un body envoye ? La methode DELETE en a-t-elle besoin ?
Q4 - HEAD : que les en-tetes
A quoi peut servir HEAD en pratique ? (Indice : verifier qu'un fichier existe / connaitre sa taille sans le telecharger.)
Q5 - Methode refusee : code 405
Quel code de statut le serveur renvoie-t-il ? Pourquoi ?
Exercice 9 - curl -v : observer le handshake TLS¶
Fichier : curl_cmds.sh (Partie C).
Ici on retrouve concretement ce qu'on a reordonne sur papier a l'exercice 3.
Q1 - Handshake en direct
Les lignes * decrivent ce qui se passe avant que HTTP commence. On y trouve les messages du handshake TLS, par exemple :
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
A noter dans le README :
- la version de TLS negociee
- la cipher suite finale
- le nombre de messages OUT et IN
- l'
Issuerdu certificat serveur (visible plus bas dans la sortie)
Q2 - OUT et IN
OUT = ce que toi envoies. IN = ce que le serveur envoie. Comparer avec ton classement papier de l'exercice 3 : retrouves-tu les memes echanges ?
Q3 - Forcer TLS 1.2
Comparer avec la trace TLS 1.3 :
- Plus ou moins de messages echanges ?
- La cipher suite change-t-elle ? A quoi ressemble-t-elle maintenant (
TLS_ECDHE_RSA_WITH_AES_..._GCM_SHA...) ? - Le message
Certificateest-il toujours visible en clair, ou est-il chiffre ?
Q4 - Format de cipher suite TLS 1.3
Le format TLS 1.3 (TLS_AES_256_GCM_SHA384) est plus court que TLS 1.2 : il ne mentionne plus l'echange de cle ni l'authentification. Pourquoi ? (Indice : en TLS 1.3, l'echange de cle est toujours DH ephemere, negocie via une extension separee ; l'authentification est toujours assuree par la signature du certificat.)
Plus loin
Wireshark (exercices 10 et 11) montre les memes messages au niveau paquet reseau, et permet en plus de filtrer, exporter et reconstituer des sessions completes.
Exercice 10 - Capture HTTP avec Wireshark¶
- Lancer Wireshark sur l'interface reseau de la VM.
- Appliquer le filtre d'affichage :
http - Ouvrir le navigateur, aller sur
http://safe.isen-cyber.ovh/login - Saisir les identifiants (
alice/motdepasse123) et valider. - Stopper la capture, l'enregistrer dans
captures/http_login.pcapng. - Reperer la requete
POST /login→ clic droit → Follow → HTTP Stream.
README
- Retrouve le nom d'utilisateur et le mot de passe dans la capture. Comment les as-tu trouves ?
- Sur quel type de reseau cette interception est-elle particulierement facile ?
- Quels autres elements sensibles vois-tu passer (cookies, en-tetes...) ?
Exercice 11 - Capture HTTPS avec Wireshark¶
Meme manipulation que l'exercice 10, mais en HTTPS cette fois.
- Nouvelle capture Wireshark, filtre :
tls - Aller sur
https://safe.isen-cyber.ovh/login(certificat valide Let's Encrypt : aucun avertissement, contrairement aunsafe.isen-cyber.ovh). - Refaire le login avec les memes identifiants (
alice/motdepasse123). - Stopper, enregistrer dans
captures/https_login.pcapng. - Inspecter la capture : deplier les paquets du handshake.
README
- Retrouves-tu le nom d'utilisateur et le mot de passe ? Pourquoi ?
- Identifie dans la capture les etapes du handshake TLS :
ClientHello,ServerHello,Certificate... (les memes qu'a l'exercice 3). - Quelle version de TLS est utilisee (visible dans le
ClientHello/ServerHello) ?
Fichiers du projet¶
Telecharger le scaffolding (td4-template.zip)
td4/
├── README.md # a remplir
├── nc_requests.sh # scaffolding netcat (exercice 6)
├── curl_cmds.sh # scaffolding curl (Parties A, B, C)
└── captures/
├── http_login.pcapng # capture HTTP a deposer (exercice 10)
├── https_login.pcapng # capture HTTPS a deposer (exercice 11)
├── backup_http.pcapng # backup fourni (si capture live impossible)
└── backup_https.pcapng # backup fourni (si capture live impossible)
README a rendre¶
Le scaffolding contient un README.md pre-rempli a completer. Voici sa structure :
# TD4 - HTTP, HTTPS, TLS & certificats
## Exercices sur papier
### Exercice 1 - Anatomie d'une requete HTTP
- Methode / chemin / version : ___
- Valeur de Host : ___
- Cookies envoyes : ___
- Login / mot de passe du body : ___
- Decodage de l'Authorization Basic : ___
- Le base64 est-il du chiffrement ? ___
- A quoi sert base64 alors ? ___
### Exercice 2 - La pile reseau
- TLS se place entre ___ et ___
- HTTP : port ___ / HTTPS : port ___
- DNS : port ___ / DoT : port ___ / DoH : port ___ (en clair / chiffre ?)
- Pourquoi DoH plus dur a bloquer que DoT / ou fuit encore le nom du site : ___
- Transport de HTTP/1.1, HTTP/2, HTTP/3 : ___
- Ce qu'un attaquant voit quand meme en HTTPS : ___
### Exercice 3 - Le handshake TLS
- Ordre des messages (TLS 1.2) : ___
- Nombre de round-trips : ___
- Message qui transporte le certificat : ___
- TLS 1.3 : nombre de round-trips ___ / deux elements supprimes : ___
- Decomposition de TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 : ___
### Exercice 4 - Echange RSA vs DH ephemere : PFS
- Q1 a quoi sert sk en scenario A / scenario B : ___
- Q2 Mallory peut-elle dechiffrer le passe en A / en B : ___
- Q3 lequel assure la PFS : ___
- Q4 pourquoi « forward » : ___
- Q5 TLS 1.3 rend obligatoire : ___
- Q6 sessions futures en A / en B (MITM ?) : ___
### Exercice 5 - Le cadenas
- Scenarios a / b / c / d / e (protege ou non + pourquoi) : ___
## Exercices sur PC
### Exercice 6 - nc : crafter sa requete HTTP a la main
- Ligne de statut renvoyee (Q1) : ___
- En-tetes principaux de la reponse : ___
- Q3 POST 17 octets - champ `form` recu : ___
- Q4 sans Host - code de statut / pourquoi : ___
- Q5 User-Agent falsifiable - a, b, c : ___
### Exercice 7 - curl : premieres requetes HTTP
- En-tetes ajoutes automatiquement par curl : ___
- Version HTTP utilisee : ___
- Parametres de requete : ou apparaissent-ils ? ___
### Exercice 8 - Les methodes HTTP
- Q1 POST : ou apparait login=bob / Content-Type ajoute : ___
- Q2 PUT JSON : champ du JSON ou apparait le body : ___
- Q3 DELETE : a-t-elle besoin d'un body ? ___
- Q4 A quoi sert HEAD en pratique ? ___
- Q5 Code de statut pour DELETE sur /get : ___
### Exercice 9 - curl -v : handshake TLS
- Version TLS negociee : ___
- Cipher suite : ___
- Nombre de messages OUT / IN : ___
- Issuer du certificat serveur : ___
- Differences observees en forcant TLS 1.2 : ___
- Pourquoi le format de cipher suite TLS 1.3 est plus court : ___
### Exercice 10 - Capture HTTP
- Login trouve dans la capture : oui / non
- Methode utilisee dans Wireshark : ___
- Autres elements sensibles visibles : ___
### Exercice 11 - Capture HTTPS
- Login trouve dans la capture HTTPS : oui / non - pourquoi ? ___
- Etapes du handshake TLS identifiees : ___
- Version de TLS utilisee : ___
## Difficultes rencontrees
(libre)
Annexe - Table base64¶
Chaque caractere code 6 bits. Index → caractere :
| Idx | Car | Idx | Car | Idx | Car | Idx | Car |
|---|---|---|---|---|---|---|---|
| 0 | A | 16 | Q | 32 | g | 48 | w |
| 1 | B | 17 | R | 33 | h | 49 | x |
| 2 | C | 18 | S | 34 | i | 50 | y |
| 3 | D | 19 | T | 35 | j | 51 | z |
| 4 | E | 20 | U | 36 | k | 52 | 0 |
| 5 | F | 21 | V | 37 | l | 53 | 1 |
| 6 | G | 22 | W | 38 | m | 54 | 2 |
| 7 | H | 23 | X | 39 | n | 55 | 3 |
| 8 | I | 24 | Y | 40 | o | 56 | 4 |
| 9 | J | 25 | Z | 41 | p | 57 | 5 |
| 10 | K | 26 | a | 42 | q | 58 | 6 |
| 11 | L | 27 | b | 43 | r | 59 | 7 |
| 12 | M | 28 | c | 44 | s | 60 | 8 |
| 13 | N | 29 | d | 45 | t | 61 | 9 |
| 14 | O | 30 | e | 46 | u | 62 | + |
| 15 | P | 31 | f | 47 | v | 63 | / |
Le caractere = ne code rien : c'est du remplissage pour completer le dernier groupe.
Annexe - Filtres Wireshark utiles¶
| Filtre | Effet |
|---|---|
http |
N'afficher que le trafic HTTP |
http.request |
Uniquement les requetes HTTP |
tls |
N'afficher que le trafic TLS |
tls.handshake |
Uniquement les messages du handshake TLS |
ip.addr == <IP> |
Trafic vers/depuis une IP donnee |
tcp.port == 80 |
Trafic sur le port 80 |
Pour reconstituer un echange complet : clic droit sur un paquet → Follow → HTTP Stream (ou TCP Stream).