TD4 - HTTP, HTTPS, TLS & certificats

Exercices sur papier

Exercice 1 - Anatomie d'une requete HTTP

• Methode / chemin / version : POST /connexion HTTP/1.1
• Valeur de Host :intranet.isen.fr
• Cookies envoyes :session=8f3a2b; theme=sombre
• Login / mot de passe du body : login=bob.martin&motdepasse=Pr1ntemps2025
• Decodage de l'Authorization Basic (Ym9iOjEyMzQ=) :bob:1234
• Le base64 est-il du chiffrement ? Pourquoi ? non , c'est juste une base différente comme la base 16 ou 8 ect... Il n'y a pas de chiffrement.
• A quoi sert base64 alors ? Pour que la taille des messages ne soient trop grosses.

Exercice 2 - La pile reseau

• TLS se place entre HTTP et TCP
• HTTP : port 80 clair / HTTPS : port 443 chiffrés
• DNS : port 53 clair / DoT : port 853 chiffrés / DoH : port 443 chiffrés (en clair / chiffre ?)
• Pourquoi DoH est plus dur a bloquer que DoT :DoH est situé sur le meme port que le service https , c'est donc plus compliqué à bloquer
• Ou fuit encore le nom du site malgre DoT/DoH : dans le message TLS , au tout début du handshake, le client envoie en clair le nom de domaine qu'il veut rejoindre.
• Transport de HTTP/1.1 : TCP / HTTP/2 : TCP + TLS / HTTP/3 : UDP
• Ce qu'un attaquant voit quand meme en HTTPS (parmi a-e) : l'ip du client, le taille, le rythme des échanges et le nom de domaine que le client souhaite visiter uniquement.

Exercice 3 - Le handshake TLS

• Ordre des 9 messages (TLS 1.2) : B H F D C G E I A
• Nombre de round-trips avant la 1re requete chiffree : il faut 2 allers-retours avant d'envoyer la première requête HTTP chiffrée
• Message qui transporte le certificat / son role : c'est le message certificate (F), Le client s'en sert pour vérifier l'identité du serveur : il contrôle que le certificat est signé par une autorité de certification de confiance, que le nom de domaine correspond, et que le certificat n'est pas expiré.
• TLS 1.3 : nombre de round-trips 1 / deux elements supprimes : L'échange de clé RSA statique, l'usage d'algorithmes de chiffrements dépréciés.
• Decomposition de TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 :
  • ECDHE : Échange de clé , CM3 - Diffie-Hellman
  • RSA : Authentification , CM3 - RSA
  • AES_128_GCM : Chiffrement symétrique CM2 - AES
  • SHA256 : Intégrité / PRF, CM3 - Hachage

Exercice 4 - Echange RSA vs DH ephemere : Perfect Forward Secrecy

• Q1 - a quoi sert sk en scenario A (TLS_RSA) : sert à déchiffrer le PMS envoyé par le client.
• Q1 - a quoi sert sk en scenario B (TLS_DHE_RSA) : sert uniquement à signer les paramètres Diffie-Hellman
• Q2 - Mallory peut-elle dechiffrer le passe en A ? Comment ? :Dans ses captures, Mallory extrait le message ClientKeyExchange qui contient E_pk(PMS),Elle utilise la clé privée sk achetée pour déchiffrer et retrouver le PMS Elle récupère aussi les ClientHello et ServerHello qui contiennent les random échangés,Elle dérive la clé de session AES exactement comme le serveur l'avait fait : clé = PRF Elle déchiffre tout le trafic enregistré depuis un an
• Q2 - Mallory peut-elle dechiffrer le passe en B ? Pourquoi pas ? : Dans ses captures, Mallory voit A = g^a mod p et B = g^b mod p en clair. Pour retrouver le PMS, il lui faudrait calculer g^(ab) mod p, c'est-à-dire résoudre le problème du logarithme discret. Ce problème est calculatoirement infaisable pour des paramètres correctement choisis. La clé sk ne lui sert à rien ici car elle permettrait seulement de vérifier/forger des signatures — mais a et b ont été détruits après la session et ne se retrouvent nulle part dans la capture. → Le trafic passé reste indéchiffrable.
• Q3 - Lequel des deux assure la PFS : c'est le scénario B
• Q4 - Pourquoi parle-t-on de « forward » : le secret de session ne se propage pas dans le futur , ça protège le passé.
• Q5 - TLS 1.3 rend obligatoire : TLS 1.3 rend la Perfect Forward Secrecy obligatoire pour toute connexion.
• Q6 - Sessions futures en A / en B (MITM ?) : A : Mallory peut déchiffrer en temps réel toutes les nouvelles sessions, exactement comme pour le passé. B: La PFS protège le passé mais pas les sessions futures.

Exercice 5 - Le cadenas

• Scenario a : protege / non - pourquoi OUI ; TLS chiffre le trafic de bout en bout : l'attaquant ne voit que des octets chiffrés, impossible de lire le mot de passe en transit
• Scenario b : protege / non - pourquoi NON ; la connexion au mauvais site est chiffrée mais cela reste le mauvais site
• Scenario c : protege / non - pourquoi NON; TLS protège le transit entre le client et le serveur, pas ce que le serveur fait des données une fois reçues
• Scenario d : protege / non - pourquoi OUI ; TLS garantit l'intégrité des données via le MAC
• Scenario e : protege / non - pourquoi OUI ; Le navigateur affiche une alerte car le certificat n'est pas signé par une CA de confiance.

Exercices sur PC

Exercice 6 - nc : crafter sa requete HTTP a la main (nc_requests.sh)

• Q1 - ligne de statut renvoyee : HTTP/1.1 200 OK
• Q1 - en-tetes principaux : Content-Type: text/html; charset=utf-8 / Content-Length: 9593 / Server: Caddy, gunicorn/19.9.0
• Q3 POST 17 octets - champ form recu : {"id": "1234", "login": "bob"}
• Q4 sans Host - code de statut : 400 Bad Request: missing required Host header — en HTTP/1.1, l'en-tete Host est obligatoire car un meme serveur peut heberger plusieurs sites sur la meme IP; sans lui, le serveur ne sait pas quel site servir. En HTTP/1.0 ce probleme n'existait pas (une IP = un seul site).
• Q5 User-Agent falsifiable :
  • a confiance dans les stats de navigateur : aucune — n'importe quel client peut envoyer un User-Agent arbitraire, les statistiques publiees par les sites sont donc peu fiables
  • b valeur d'une protection anti-bot basee sur UA : nulle — un script peut trivialement usurper n'importe quel User-Agent legitime
  • c comment les sites identifient reellement les visiteurs : via les cookies de session, qui contiennent un token secret genere cote serveur et impossible a deviner

Exercice 7 - curl : premieres requetes HTTP (curl_cmds.sh, Partie A)

• Ligne de requete (> GET / HTTP/1.1) recopiee : GET / HTTP/1.1
• En-tetes ajoutes automatiquement par curl : Host: safe.isen-cyber.ovh, User-Agent: curl/8.19.0, Accept: */*
• Ligne de statut (< HTTP/1.1 ...) : HTTP/1.1 200 OK
• Version HTTP utilisee : HTTP/1.1
• Q4 - ou retrouve-t-on nom=alice&ville=toulon (URL / body) : dans l'URL (query string), retrouves dans le champ "args" de la reponse JSON — pas dans "form" ni "data"

Exercice 8 - Les methodes HTTP (curl_cmds.sh, Partie B)

• Q1 POST - ou apparait login=bob, Content-Type ajoute : dans le champ "form" de la reponse JSON ; curl ajoute automatiquement Content-Type: application/x-www-form-urlencoded
• Q2 PUT JSON - champ du JSON ou apparait le body : dans le champ "json" de la reponse ({"titre": "nouveau"})
• Q3 DELETE - body envoye ? besoin d'un body ? : aucun body envoye ; DELETE n'en necessite pas, il identifie la ressource a supprimer uniquement par l'URL
• Q4 - a quoi sert HEAD en pratique ? : verifier qu'une ressource existe, connaitre sa taille (Content-Length) ou sa date de modification (Last-Modified) sans telecharger le corps — utile pour les caches et les crawlers
• Q5 - code de statut pour DELETE /get : 405 Method Not Allowed — le serveur n'accepte que GET sur cette route ; il indique les methodes autorisees dans l'en-tete Allow

Exercice 9 - curl -v : handshake TLS (curl_cmds.sh, Partie C)

• Version TLS negociee : TLSv1.3
• Cipher suite : TLS_AES_128_GCM_SHA256 / x25519
• Nombre de messages OUT / IN observes : OUT: 3 (Client Hello, Change Cipher Spec, Finished) / IN: 6 (Server Hello, Change Cipher Spec, Encrypted Extensions, Certificate, Cert Verify, Finished)
• Issuer du certificat serveur : C=US; O=Let's Encrypt; CN=E8
• En forcant TLS 1.2 - differences observees :
  • Plus de messages : 9 messages au lieu de 7 (2-RTT vs 1-RTT) — on voit apparaitre Server key exchange (12) et Server finished (14) en clair, absents en TLS 1.3
  • Certificate visible en clair : en TLS 1.2 le certificat transite avant l'etablissement du chiffrement, il est donc visible dans le verbeux ; en TLS 1.3 il est chiffre (Encrypted Extensions)
  • Cipher suite plus longue : ECDHE-ECDSA-AES128-GCM-SHA256 au lieu de TLS_AES_128_GCM_SHA256 — TLS 1.2 doit preciser explicitement le mecanisme d'echange de cle (ECDHE) et d'authentification (ECDSA)
• Pourquoi le format de cipher suite TLS 1.3 est plus court : en TLS 1.3 l'echange de cle est toujours ECDHE et l'authentification est separee de la cipher suite — seuls le chiffrement symetrique et le hash restent a specifier (TLS_AES_128_GCM_SHA256), d'ou un nom beaucoup plus court

Exercice 10 - Capture HTTP (captures/http_login.pcapng)

• Login trouve dans la capture : oui
• Methode utilisee dans Wireshark : il suffit de ce balader dans les données récupérées par Wireshark
• Autres elements sensibles visibles : des données du style : port d'entré , informations sur la localisation ect... cela peut aider pour de l'usurpation d'identité.

Exercice 11 - Capture HTTPS (captures/https_login.pcapng)

• Login trouve dans la capture HTTPS : non
• Pourquoi ? cette fois ci la connexion est chiffrée
• Etapes du handshake TLS identifiees : Oui
• Version de TLS utilisee :TLS 1.3

Difficultes rencontrees

(libre)