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 : 2 cookies (session=8f3a2b et theme=sombre)
• Login / mot de passe du body : login=bob.martin / motdepasse=Pr1ntemps2025 (Ils transitent totalement en clair !)
• Decodage de l'Authorization Basic : Ym9i correspond à bob et OjEyMzQ= correspond à :1234. L'identifiant complet est donc bob:1234.
• Le base64 est-il du chiffrement ? : Non, c'est un simple encodage. Il n'y a pas de clé secrète, n'importe qui peut le décoder avec la table publique. Cela n'offre aucune sécurité.
• A quoi sert base64 alors ? : Il sert à transformer des données arbitraires (pouvant contenir des octets non imprimables ou des caractères spéciaux comme : ou des retours à la ligne) en caractères ASCII standard et inoffensifs pour ne pas casser la structure des en-têtes HTTP.

Exercice 2 - La pile reseau

• TLS se place entre : HTTP (Application) et TCP (Transport). On l'appelle souvent une couche de présentation/session.
• HTTP : port 80 / HTTPS : port 443
• Transport de HTTP/1.1, HTTP/2, HTTP/3 : TCP pour HTTP/1.1 et HTTP/2. UDP (via QUIC) pour HTTP/3.
• Ce qu'un attaquant voit quand meme en HTTPS : b) l'adresse IP du serveur, c) le nom de domaine demandé (en clair dans le Server Name Indication / SNI) et d) la taille et le rythme des paquets.

Exercice 3 - Le handshake TLS

• Ordre des messages (TLS 1.2) : B (ClientHello), H (ServerHello), F (Certificate), D (ServerHelloDone), C (ClientKeyExchange), G (ChangeCipherSpec Client), E (Finished Client), I (ChangeCipherSpec Serveur), A (Finished Serveur).
• Nombre de round-trips : 2 RTT (Allers-retours) avant de pouvoir envoyer la première requête HTTP chiffrée.
• Message qui transporte le certificat : Le message Certificate. Il permet au client de vérifier l'identité du serveur (signature de l'autorité de certification, date de validité, correspondance du domaine).
• TLS 1.3 : nombre de round-trips : 1 RTT / deux elements supprimes : Les échanges de clés statiques RSA (tout passe en éphémère) et les algorithmes de chiffrement obsolètes/faibles (RC4, DES, etc.).
• Decomposition de TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 :
  • ECDHE : L'algorithme d'échange de clés (Elliptic Curve Diffie-Hellman Ephemeral).
  • RSA : L'algorithme d'authentification (utilisé par le serveur pour signer l'échange).
  • AES_128_GCM : L'algorithme de chiffrement symétrique garantissant la confidentialité des données.
  • SHA256 : La fonction de hachage utilisée pour l'intégrité (MAC) ou la dérivation de clés (PRF).

Exercice 4 - Echange RSA vs DH ephemere : PFS

• Q1 a quoi sert sk en scenario A / scenario B :
  • En A, sk sert à déchiffrer le pre-master secret (PMS) généré et envoyé par le client.
  • En B, sk sert à signer les paramètres publics Diffie-Hellman du serveur pour prouver son identité.
• Q2 Mallory peut-elle dechiffrer le passe en A / en B :
  • En A : Oui. Mallory déchiffre l'ancien échange de clé avec sk, retrouve le PMS, recrée la clé AES de session et lit le trafic passé.
  • En B : Non. Le PMS a été généré via la résolution de g^(ab), or a et b ont été détruits et le logarithme discret est impossible à casser. Connaître sk n'aide pas.
• Q3 lequel assure la PFS : Le scénario B (l'échange éphémère).
• Q4 pourquoi « forward » : Car on protège le secret de la session vers le "futur". Une compromission future de la clé long-terme n'affecte pas les sessions passées.
• Q5 TLS 1.3 rend obligatoire : La Perfect Forward Secrecy (PFS) en forçant l'utilisation exclusive d'échanges de clés éphémères comme (EC)DHE.
• Q6 sessions futures en A / en B (MITM ?) : Dans les deux cas, avec sk, Mallory peut usurper l'identité du serveur (attaque Man-In-The-Middle actif) pour les nouvelles sessions, car elle peut soit déchiffrer l'échange (A) soit le signer frauduleusement (B).

Exercice 5 - Le cadenas

• a : Protégé. Le trafic HTTPS chiffre le mot de passe ; l'attaquant sur le WiFi ne voit qu'un flux d'octets illisible.
• b : Non protégé. Le cadenas valide que la connexion au faux site paypa1 est sécurisée, mais le site en lui-même est malveillant. Le cadenas ne garantit pas la bienveillance du propriétaire.
• c : Non protégé. HTTPS sécurise uniquement les données en transit sur le réseau, pas leur stockage au repos sur le serveur.
• d : Protégé. Le protocole garantit l'intégrité (via le MAC). Si la page est altérée en route, la vérification cryptographique échouera et le navigateur coupera la connexion.
• e : Protégé. Le navigateur va lever une alerte de sécurité rouge vif car le certificat auto-signé n'est reconnu par aucune autorité de certification (CA) de confiance (la chaîne de confiance est rompue).

Exercices sur PC

(Note: Ces réponses reflètent le comportement attendu des outils nc, curl et Wireshark sur ces manipulations classiques)

Exercice 6 - nc : crafter sa requete HTTP a la main

• Ligne de statut renvoyee (Q1) : HTTP/1.1 200 OK
• En-tetes principaux de la reponse : Server, Date, Content-Type, Content-Length.
• Q3 POST 17 octets - champ form recu : Le serveur renvoie généralement le payload transmis (ex: "login": "bob").
• Q4 sans Host - code de statut / pourquoi : 400 Bad Request. En HTTP/1.1, l'en-tête Host est strictement obligatoire pour permettre l'hébergement mutualisé (plusieurs sites sur la même IP).
• Q5 User-Agent falsifiable - a, b, c : Oui, c'est un simple champ de texte défini par le client. Il est trivial de le modifier avec netcat (ou curl) pour se faire passer pour un navigateur différent, un mobile, ou un bot.

Exercice 7 - curl : premieres requetes HTTP

• En-tetes ajoutes automatiquement par curl : Host, User-Agent (ex: curl/7.81.0), et Accept: */*.
• Version HTTP utilisee : HTTP/2 ou HTTP/1.1 (selon la version de curl, affiché dans la réponse).
• Parametres de requete : ou apparaissent-ils ? Dans l'URL, à la suite du chemin de la ressource, après un point d'interrogation ? (ex: /get?param=value).

Exercice 8 - Les methodes HTTP

• Q1 POST : ou apparait login=bob / Content-Type ajoute : Dans le "body" de la requête. L'en-tête Content-Type: application/x-www-form-urlencoded est ajouté.
• Q2 PUT JSON : champ du JSON ou apparait le body : Dans le champ "json" ou "data" renvoyé par httpbin.
• Q3 DELETE : a-t-elle besoin d'un body ? Non, la méthode DELETE supprime la ressource identifiée par l'URL directement.
• Q4 A quoi sert HEAD en pratique ? À obtenir uniquement les en-têtes de réponse (utile pour vérifier la taille Content-Length d'un gros fichier ou sa date de modification avant de le télécharger complètement).
• Q5 Code de statut pour DELETE sur /get : 405 Method Not Allowed (la route /get n'autorise pas la méthode DELETE).

Exercice 9 - curl -v : handshake TLS

• Version TLS negociee : TLSv1.3 (ou TLSv1.2 en fonction de l'environnement).
• Cipher suite : Ex: TLS_AES_256_GCM_SHA384 ou similaire.
• Nombre de messages OUT / IN : On peut voir le ClientHello (OUT), puis le ServerHello (IN), etc.
• Issuer du certificat serveur : Let's Encrypt (R3).
• Differences observees en forcant TLS 1.2 : Un handshake plus long à cause des RTT supplémentaires et une cipher suite qui inclura explicitement l'échange de clé (ex: ECDHE-RSA-AES...).
• Pourquoi le format de cipher suite TLS 1.3 est plus court : En TLS 1.3, l'algorithme d'échange de clé (toujours (EC)DHE) et la signature (qui dépend du certificat) ne sont plus précisés dans le nom, réduisant la cipher suite au duo de chiffrement symétrique et de hash (ex: AES_128_GCM_SHA256).

Exercice 10 - Capture HTTP

• Login trouve dans la capture : oui
• Methode utilisee dans Wireshark : Clic droit sur le paquet HTTP -> Follow -> TCP Stream (ou HTTP Stream).
• Autres elements sensibles visibles : Tout transite en clair, on peut voir les cookies de session (Cookie:), la méthode, le navigateur de la victime (User-Agent) et potentiellement les données de la page consultée.

Exercice 11 - Capture HTTPS

• Login trouve dans la capture HTTPS : non - pourquoi ? Car les données applicatives (Application Data) sont chiffrées avec la clé AES de session négociée par TLS.
• Etapes du handshake TLS identifiees : On peut identifier distinctement Client Hello, Server Hello, Certificate, Client Key Exchange, et Change Cipher Spec.
• Version de TLS utilisee : Probablement TLSv1.2 ou TLSv1.3 (vérifiable dans les détails du paquet Client Hello -> Transport Layer Security).