Introduction
Lantern Room organise de petits ateliers de lanternes en papier. Son application de réservation utilise HTTPS : une capture ordinaire montre donc du trafic chiffré, sans les détails des réservations. Vous êtes autorisé à analyser ce service de formation contrôlé et ses visiteurs synthétiques. Commencez par une référence normale, puis effectuez et capturez votre propre nouvelle visite.
Vous produirez une véritable capture PCAPNG et son journal de clés TLS séparé, qu'un autre analyste autorisé pourra rouvrir. Vous devez connaître la navigation et les filtres d'affichage élémentaires de Wireshark, la saisie de commandes simples et les chemins. Aucune programmation ni administration de certificats n'est nécessaire. Utilisez Desktop, notamment Terminal Emulator et les fenêtres Wireshark. Ce laboratoire indépendant prépare ses propres fichiers et son service local ; la durée est une estimation de l'auteur incluant lecture et erreurs courantes.
Rendre La Référence Normale Lisible
Vous allez déchiffrer une réservation normale et découvrir les champs qui établissent son résultat.
Commencez dans Desktop. Ouvrez Applications → Terminal Emulator en bas à gauche. Exécutez cette commande complète ; le terminal reste occupé jusqu'à la fermeture de Wireshark.
wireshark -C Booking /home/labex/project/booking/input/casebook.pcapng
-C Booking sélectionne le profil de configuration Booking, préparé et initialement vide. Un profil conserve les réglages de cette fenêtre d'analyse. Agrandissez Wireshark avec le bouton de maximisation de sa barre de titre. La capture d'entrée et input/casebook.keys sont des originaux en lecture seule ; enregistrez votre travail dans output/.
HTTPS est HTTP transporté dans TLS, le protocole qui chiffre la conversation applicative. TCP transporte ces enregistrements TLS entre les extrémités. Cette capture utilise TLS 1.3 et HTTP/1.1. Le service local est 127.0.0.1:18443 ; l'identité de test locale de Hazel est 127.0.0.21. Ces adresses partagent un conteneur de formation et ne représentent pas des machines physiques distinctes.
Dans la barre de filtre d'affichage, saisissez http et appuyez sur Enter. Aucune ligne HTTP n'est déchiffrée au départ. Videz la barre pour voir la négociation TLS et les Application Data chiffrées. La négociation établit la session, tandis qu'Application Data transporte les messages de réservation. La capture seule ne fournit pas leur texte en clair.
Un journal de clés TLS contient des secrets enregistrés volontairement par un client autorisé pour des sessions précises. Ce n'est ni une liste de mots de passe ni le certificat du serveur. Un certificat serveur ou une clé privée RSA ne remplace pas ces secrets de session TLS 1.3. En situation réelle, traitez captures et journaux de clés comme des données sensibles et ne les partagez que dans le périmètre autorisé. Ici, identités, réservations et secrets appartiennent tous à l'exercice local.
Ouvrez Edit → Preferences. Développez Protocols, cliquez dans la liste des protocoles et saisissez tls pour atteindre TLS. Dans (Pre)-Master-Secret log filename, entrez le chemin absolu suivant. Laissez cochées Reassemble TLS records spanning multiple TCP segments et Reassemble TLS Application Data spanning multiple TLS records, puis cliquez sur OK.
/home/labex/project/booking/input/casebook.keys
Appliquez à nouveau le filtre http. Une requête POST et une réponse HTTP doivent apparaître. Si la liste reste vide, effacez le filtre, vérifiez l'orthographe du nom de fichier et revenez aux préférences TLS. Un journal incorrect ou sans rapport explique des Application Data non déchiffrées ; cela ne prouve pas l'absence de requête.
Sélectionnez la requête POST. HTTP fonctionne par requête et réponse : POST envoie des données et /api/bookings est l'URI désignant la ressource de réservation. Faites un clic droit sur la requête et choisissez Follow → TLS Stream. Follow TLS Stream montre les octets applicatifs déchiffrés ; Follow TCP Stream montre encore les octets de transport chiffrés. Lisez la requête et la réponse, en faisant défiler au besoin. Ne déduisez pas l'expéditeur de la couleur du texte : lisez la ligne de requête et la ligne de statut de réponse.
Le corps de requête est en JSON, un ensemble de valeurs nommées entre accolades. Lisez visitor, attempt, workshop et slot. La réponse répète ces valeurs et ajoute accepted, reason et confirmation. La réservation normale de Hazel présente accepted: true, reason: "confirmed" et une confirmation appartenant à hazel-01. En JSON, true est un booléen ; les guillemets entourent du texte et null signifie qu'aucune valeur n'est présente.
HTTP/1.1 200 OK signifie que le serveur a traité cette requête HTTP. Le résultat applicatif de la réservation se déduit toujours des champs JSON. Cette distinction compte pour le laboratoire suivant. Le grand espace vide après le JSON est un remplissage pédagogique volontaire : il répartit la réponse réelle sur plusieurs segments TLS/TCP, sans représenter une autre réservation.
Lisez l'attempt répété et les champs accepted, reason et confirmation de la réponse. Le statut HTTP seul ne suffit pas.
Fermez Follow avec Close. Wireshark laisse un filtre tcp.stream eq ... montrant toute la connexion TCP choisie, négociation et segments compris. Un filtre d'affichage change seulement la vue. Fermez la fenêtre principale pour enregistrer le réglage du profil et libérer le terminal. La référence est correctement configurée lorsque Booking déchiffre sa requête et sa réponse complètes.
Capturer Et Rouvrir Votre Propre Visite
Vous allez capturer une nouvelle visite autorisée et rouvrir indépendamment ses paquets réellement enregistrés.
Commencez dans Desktop, à l'invite de Terminal Emulator revenue après la fermeture de la référence. Le journal de clés de référence ne déverrouille pas une autre session TLS. Capturez une nouvelle visite et conservez ses propres secrets à côté de la capture.
Exécutez le lanceur de capture préparé :
python3 /opt/labex/booking/capture.py
Il lance la véritable interface de capture en direct de Wireshark dans le profil distinct BookingLive. La source fixe capture uniquement le trafic TCP de bouclage sur le port du cours 18443, avec des limites de 15 minutes et 4 MB. Elle utilise un tube, canal d'octets en direct vers Wireshark, et non une relecture. Elle ne confère aucun privilège général de capture et ne change pas vos paramètres de connexion. Gardez ce terminal et Wireshark ouverts. Attendez Live packet feed ready dans le terminal et la fenêtre de capture active avant d'envoyer du trafic.
Ouvrez un deuxième Terminal Emulator via Applications → Terminal Emulator. Le panneau inférieur permet de passer entre les deux terminaux et Wireshark. Dans le nouveau terminal, lancez le client autorisé :
python3 /opt/labex/booking/booking.py client
Le client préparé vérifie le certificat et le nom d'hôte du service local, envoie une véritable requête de réservation et écrit les secrets de cette nouvelle session dans /home/labex/project/booking/output/live.keys. Il annonce la fin de la visite sans afficher la réponse. Son nouvel attempt change à chaque exécution. Le client your-visit utilise 127.0.0.26.
Revenez dans Wireshark par le panneau inférieur. Attendez que les paquets soient réellement visibles, y compris le dernier paquet terminant la connexion TCP, avant de cliquer sur le carré rouge Stop. La fin du client ne signifie pas que l'interface a déjà reçu tous les paquets. Vous devez voir la négociation, le trafic applicatif chiffré et le paquet FIN ou RST de fermeture. FIN ferme un sens TCP ; RST termine immédiatement la connexion. Le RST de fermeture de ce client contrôlé n'est pas le résultat de réservation de l'application.
Choisissez File → Save As, ou Ctrl+S pour la capture non enregistrée, conservez le format pcapng et enregistrez :
/home/labex/project/booking/output/live.pcapng
Enregistrez la capture réelle, ni le texte de la liste ni une image. Gardez le journal séparé ; n'utilisez pas Inject TLS Secrets. Fermez la fenêtre principale de capture après l'enregistrement. Dans le premier terminal, le lanceur doit finir avec native dumpcap status: 0 et rendre l'invite. Fermer la fenêtre ferme aussi la source du cours ; reconnecter un terminal ne réinitialise pas le service de réservation.
Dans l'un des terminaux, ouvrez le fichier enregistré avec le profil de révision initialement vide :
wireshark -C BookingReview /home/labex/project/booking/output/live.pcapng
Appliquez http : la liste est à nouveau vide au départ. Dans Edit → Preferences → Protocols → TLS, essayez d'abord input/casebook.keys avec le chemin absolu complet de l'étape 1. Appliquez avec OK. Il ne déchiffre toujours pas cette nouvelle session. Remplacez maintenant ce réglage par le journal correspondant à la nouvelle visite :
/home/labex/project/booking/output/live.keys
Cliquez sur OK et appliquez http. Un POST et sa réponse doivent apparaître. Faites un clic droit sur le POST et choisissez Follow → TLS Stream. Lisez votre nouvel attempt, vérifiez que la réponse le répète et contrôlez accepted, reason et sa propre confirmation. Le résultat valide est une réservation paper-lantern confirmée pour sat-14. Fermez Follow et la fenêtre principale. Vous avez rouvert indépendamment la capture enregistrée réelle, sans emprunter les secrets de la référence.
La requête et la réponse montrent le même nouvel attempt. Votre valeur générée différera de cet exemple ; c'est la correspondance qui compte.
Si vous avez arrêté trop tôt, préservez l'essai incomplet avant de recommencer. Exécutez les deux commandes suivantes dans un terminal uniquement si les deux anciens fichiers existent. mv renomme chaque fichier. Ces chemins n'ont pas d'espaces : les guillemets sont inutiles. Aucune commande ne change les entrées ni le service.
mv /home/labex/project/booking/output/live.pcapng /home/labex/project/booking/output/live-previous.pcapng
mv /home/labex/project/booking/output/live.keys /home/labex/project/booking/output/live-previous.keys
Reprenez ensuite la séquence lanceur → client dans le deuxième terminal → paquets finaux visibles → Stop → Save → Close → réouverture. Si un fichier live-previous existe déjà, choisissez d'abord un autre nom de sauvegarde inutilisé. Le client refuse volontairement d'écraser live.keys pour éviter qu'une capture perde ses secrets correspondants. Un mauvais chemin d'enregistrement se corrige via File → Save As sans nouvelle visite. Pour un filtre mal saisi, effacez-le et ressaisissez http ; ne réinitialisez pas l'environnement.
Résumé
Vous avez déchiffré une référence autorisée avec Wireshark, capturé une véritable nouvelle visite HTTPS et rouvert le PCAPNG enregistré avec le journal de clés propre à cette visite. Les mauvais secrets de référence n'ont pas déverrouillé la nouvelle session. Votre résultat réutilisable est output/live.pcapng accompagné de output/live.keys.
Vous avez aussi distingué le statut HTTP du résultat de réservation et lu l'attempt répété par sa réponse. Le laboratoire suivant applique cette distinction à une réservation refusée et à sa nouvelle tentative sur une connexion persistante.
