Introduction
Alder indique que la page de réservation de Lantern Room a traité deux tentatives, mais qu'une seule a produit une réservation. Le support dispose d'une capture HTTPS autorisée et de son journal de clés TLS correspondant. Les deux tentatives utilisent le même URI et la même connexion TCP ; un autre visiteur figure aussi dans le fichier.
Vous utiliserez la véritable interface Wireshark pour identifier chaque résultat applicatif et livrer une petite table de preuves ainsi qu'une capture complète lisible indépendamment. Vous devez avoir terminé Read Your Authorized HTTPS Session, ou connaître la configuration des journaux TLS et Follow TLS Stream. La saisie de commandes simples et les chemins sont également nécessaires. Ce laboratoire démarre indépendamment avec ses propres captures contrôlées ; sa durée estimée comprend lecture et erreurs courantes.
Associer Chaque Tentative À Son Résultat Métier
Vous allez relier chaque trame de requête originale à sa propre réponse complète et consigner les deux résultats.
Commencez dans Desktop → Applications → Terminal Emulator. Ouvrez l'entrée préparée dans le profil vide Booking :
wireshark -C Booking /home/labex/project/booking/input/casebook.pcapng
Maximisez Wireshark. Les entrées en lecture seule sont casebook.pcapng et casebook.keys ; tous les livrables vont dans /home/labex/project/booking/output/. Les données sont synthétiques, mais chaque négociation TLS, échange HTTP et segment TCP a été généré par une véritable application locale contrôlée.
Dans Edit → Preferences → Protocols → TLS, définissez (Pre)-Master-Secret log filename sur :
/home/labex/project/booking/input/casebook.keys
Laissez les deux options de réassemblage TLS activées et cliquez sur OK. Le journal permet de déchiffrer ces sessions enregistrées ; ce n'est pas une clé universelle pour toutes les connexions HTTPS.
| Visiteur | Adresse cliente | Périmètre |
|---|---|---|
| alder | 127.0.0.22 | Les deux tentatives paper-lantern à expliquer |
| birch | 127.0.0.23 | Un autre visiteur, à exclure de la livraison |
Appliquez ce filtre d'affichage et appuyez sur Enter :
ip.addr == 127.0.0.22 && http
ip.addr correspond à l'une ou l'autre extrémité. && exige les deux conditions ; la vue contient donc les messages HTTP déchiffrés d'Alder dans les deux sens. Attendez-vous à deux POST et deux réponses 200 OK. Les tentatives partagent l'URI /api/bookings et le flux TCP : aucun des deux n'identifie une transaction à lui seul.
Sélectionnez le premier POST. Dans le panneau central de détails, développez Hypertext Transfer Protocol avec son petit triangle. Lisez [Response in frame: ...] près du bas. Ce champ généré relie la requête à la réponse réellement associée par Wireshark. Dans les détails de cette réponse, [Request in frame: ...] renvoie à la requête. Sélectionnez la réponse liée dans la liste des paquets. La colonne No. donne le numéro de trame original. Le HTTP réassemblé peut apparaître sur le dernier segment : utilisez ces références de trames d'analyse plutôt que de deviner à partir des lignes TCP voisines.
Repérez [Response in frame: 21] dans les détails HTTP développés. Ce lien appartient à la première requête sélectionnée ; la seconde possède une autre réponse.
Faites un clic droit sur la requête et choisissez Follow → TLS Stream. Lisez la requête complète et sa réponse. Le JSON de requête identifie attempt, workshop et slot. La réponse répète ces valeurs. Lisez ensemble accepted, reason et confirmation. Lisez ensuite la deuxième requête et sa réponse plus bas dans le même flux.
La première tentative d'Alder est refusée car la séance est complète : accepted vaut false, reason vaut "session_full" et confirmation vaut null. Le nouvel essai est accepté et possède sa propre confirmation. Les deux statuts HTTP sont 200 OK : le serveur a traité les deux requêtes, mais les résultats métier diffèrent. Une confirmation vue ailleurs dans ce flux ou dans la visite de Birch ne peut pas être attribuée à une tentative refusée.
Fermez Follow avec Close. Son filtre de flux englobe toute la connexion. Revenez au filtre original combinant Alder et HTTP pour noter les quatre trames originales. Utilisez toujours l'entrée originale pour la table : un fichier exporté renumérote les paquets.
Préparez attempts.csv, un index de transmission qu'un autre analyste pourra comparer à la capture. CSV signifie valeurs séparées par des virgules : une ligne d'en-tête nomme les colonnes, puis chaque ligne représente une tentative. Il y a sept colonnes :
| Colonne | Signification |
|---|---|
| attempt | Valeur exacte d'attempt dans la requête |
| request_frame | Trame du POST dans l'entrée originale |
| response_frame | Trame de sa propre réponse liée dans l'entrée originale |
| slot | Séance demandée, répétée par cette réponse |
| accepted | true ou false du JSON de réponse |
| reason | Texte exact du motif de réponse |
| confirmation | Confirmation de cette tentative, ou champ vide pour null |
Passez au terminal par le panneau inférieur, ou ouvrez un autre Terminal Emulator si le premier reste occupé par Wireshark. Lancez l'éditeur préparé :
mousepad /home/labex/project/booking/output/attempts.csv
Saisissez exactement l'en-tête suivant, puis les deux lignes lues dans la capture originale. Ne copiez pas le mot null dans la confirmation : terminez la ligne refusée par une virgule pour laisser le dernier champ vide. Aucune valeur de ces données ne contient de virgule : les champs CSV entre guillemets sont inutiles. L'ordre des lignes et colonnes peut changer si les en-têtes correspondent toujours aux valeurs.
attempt,request_frame,response_frame,slot,accepted,reason,confirmation
Utilisez File → Save, puis fermez l'éditeur. Vérifiez une ligne pour chaque tentative distincte, chacune pointant vers sa propre réponse. En cas de faute, rouvrez le même fichier avec la commande précédente, corrigez et enregistrez. Une faute de saisie n'exige ni nouvelle capture ni réinitialisation de VM. Gardez Wireshark ouvert pour la suite.
Livrer Un Dossier De Preuves Lisible Indépendamment
Vous allez exporter une connexion cible complète et la rouvrir avec le journal de clés livré.
Commencez dans Desktop, Wireshark affichant l'original input/casebook.pcapng. La table indexe la source ; la capture de livraison doit contenir uniquement la connexion TCP complète d'Alder. La négociation TLS et les segments antérieurs sont nécessaires au déchiffrement et au réassemblage applicatif.
Remplacez le filtre par :
ip.addr == 127.0.0.22
Il conserve les deux sens et toutes les couches d'Alder. Sélectionnez un POST déchiffré, faites un clic droit et choisissez Follow → TLS Stream. Confirmez que les deux tentatives appartiennent à Alder, puis fermez avec Close. Laissez le filtre tcp.stream eq ... : il couvre toute la connexion choisie, et non les seules lignes HTTP.
Choisissez File → Export Specified Packets. Sélectionnez le format pcapng, la plage Displayed et All packets au sein de cet ensemble affiché. Enregistrez dans :
/home/labex/project/booking/output/evidence.pcapng
La boîte de dialogue montre Displayed et All packets, soit 38 paquets cibles. L'original contient 65 paquets : choisir Captured inclurait aussi l'autre visiteur.
N'utilisez pas Export Packet Dissections, qui exporte des résumés. N'exportez pas seulement les lignes http : elles peuvent omettre la négociation ou des segments TLS/TCP antérieurs indispensables. N'incorporez pas de secrets via Inject TLS Secrets ; le dossier utilise un journal séparé.
Passez dans un Terminal Emulator et copiez le journal autorisé à côté de la sortie. cp copie le premier chemin vers le second ; il préserve l'entrée originale sans la renommer.
cp /home/labex/project/booking/input/casebook.keys /home/labex/project/booking/output/booking.keys
Cette transmission pédagogique reste dans le même périmètre autorisé. Le journal fourni contient les secrets des sessions synthétiques de la source ; réduire ou masquer ses entrées dépasse l'exercice. La capture doit néanmoins exclure les paquets de Birch. Des journaux correspondants équivalents sont acceptés s'ils déchiffrent indépendamment les deux réponses cibles.
Fermez la fenêtre principale puis rouvrez votre véritable exportation dans BookingReview, initialement vide :
wireshark -C BookingReview /home/labex/project/booking/output/evidence.pcapng
Dans Edit → Preferences → Protocols → TLS, réglez (Pre)-Master-Secret log filename sur le journal de sortie suivant, puis cliquez sur OK :
/home/labex/project/booking/output/booking.keys
Appliquez http, puis suivez un POST avec Follow → TLS Stream. Relisez les deux corps complets de requête et de réponse. L'exportation doit montrer le refus et la confirmation d'Alder avec leurs références de tentative propres, sans visite de Birch. Elle doit fonctionner avec le journal de sortie, sans dépendre silencieusement du chemin de clés d'entrée.
Lisez l'attempt répété à côté de chaque résultat : le refus n'a pas de confirmation et seul le nouvel essai a ALDER-02-CONF. Le titre identifie la sortie evidence.pcapng.
Fermez Follow puis effacez le filtre pour vérifier la présence de la négociation et des autres paquets TCP. Ce fichier a sa propre numérotation ; conservez les références d'attempts.csv vers les trames de l'entrée originale. Fermez la fenêtre principale.
Si la sortie est vide ou un corps manque, rouvrez l'entrée, restaurez le filtre de connexion complète d'Alder et répétez Export Specified Packets avec Displayed → All packets, en remplaçant la sortie incomplète. Si les paquets restent chiffrés, corrigez le chemin du journal de sortie dans TLS. Ce sont des problèmes distincts : un journal manquant empêche le déchiffrement, mais un réglage ne recrée pas des segments absents.
Votre livraison comporte trois fichiers réels : attempts.csv, evidence.pcapng et booking.keys. La capture et les clés doivent étayer la table indépendamment. Une image ou une affirmation de réussite saisie ne remplace pas les véritables preuves réseau.
Résumé
Vous avez distingué deux résultats métier portés par des statuts HTTP identiques, associé chaque requête à sa propre réponse et consigné les références de trames originales dans une table concise. Vous avez exporté toute la connexion TCP cible et rouvert la sortie réelle avec son journal de clés séparé.
Cette livraison de trois fichiers se vérifie sans votre profil Wireshark. Elle établit ce que rapportent ces échanges contrôlés, sans prouver un paiement de production, une mise à jour de stock ni un défaut interne du serveur.
