#+TITLE : Prise de notes LAB 4I001 ARES
Olivier Fourmaux ([email protected]) 4I001
Même si assez peu d’analyses de traces se font à la main, s’entraîner à interpréter des traces peut être utile.
On reproduit ici une trace, qu’on interprétera. On trouvera dans l’énoncé du lab un patron pour aider l’interprétation.
| 0000 | 00 50 7f 05 7d 40 00 10 a4 86 2d 0b 08 00 45 00 | .P..}@.. ..-…E. |
| 0010 | 02 19 17 98 40 00 40 06 6c 14 0a 21 b6 b2 c0 37 | ....@.@. l..!…7 |
| 0020 | 34 28 84 b3 00 50 b6 94 b0 b8 24 67 89 e9 80 18 | 4(…P.. ..$g.... |
| 0030 | 16 d0 60 e4 00 00 01 01 08 0a 00 6f a7 32 00 00 | ..‘..... …o.2.. |
| 0040 | 00 00 47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 | ..GET / HTTP/1.1 |
| 0050 | 0d 0a 48 6f 73 74 3a 20 77 77 77 2e 78 69 72 63 | ..Host: www.xirc |
| 0060 | 6f 6d 2e 63 6f 6d 0d 0a 55 73 65 72 2d 41 67 65 | om.com.. User-Age |
| 0070 | 6e 74 3a 20 4d 6f 7a 69 6c 6c 61 2f 35 2e 30 20 | nt: Mozi lla/5.0 |
Cette forme de trame est assez fréquente.
La colonne centrale, la plus importante, représente les données elles-mêmes.
Chaque groupe de deux caractères représente un octet, en écriture hexadécimale. Mieux, chaque caractère représente (et peut être immédiatement traduit vers) un demi-octet :
50 : 0101 0000 7f : 0111 1111
En effet, un chiffre en hexadécimal peut coder 16 chiffres, de même que 4 bits peuvent coder 16 chiffres.
La traduction de l’hexadécimal en binaire est donc triviale, c’est pour cela qu’on la verra souvent utilisée pour représenter le binaire.
Dans le cas où l’octet représente un caractère, la traduction de l’hexadécimal vers le caractère ASCII de la table réduite est directement fournie, pas besoin d’exprimer en binaire ou en décimal d’abord.
D’ailleurs, c’est ce que la colonne de droite représente : l’interprétation ASCII réduite (ce qui explique les points : si on considérait l’ASCII étendu, on pourrait interpréter presque tous les octets) de l’octet correspondant. Attention toutefois : ce n’est pas parce que l’octet se trouve correspondre à une entrée de la table ASCII réduite qu’il a été pensé par l’envoyeur comme un caractère. Il pourrait être à interpréter tel quel, comme de l’hexadécimal (adresse MAC), comme du décimal (adresse IPv4), comme du binaire. La correspondance avec un caractère ASCII valable ne pourrait être que fortuite.
Si on part du principe qu’un caractère est codé sur un octet, on peut écrire 256 caractères. La table des 256 caractères codés en ASCII est connue (elle n’est même pas remplie). Il existe en fait deux tables ASCII : la réduite et l’étendue.
La table ASCII réduite représente en fait les 128 premiers chiffres écrivables sur 8 bits (tous les chiffres avec le bit du poids fort à 0).
Le bit du poids fort à 1 permet soit de rajouter 128 chiffres (ASCII étendu) soit de coder le fait qu’on se permet d’écrire un caractère sur plus d’un octet (les différentes variantes d’UTF).
Ici, les protocoles se servent en général de la table ASCII réduite.
On a dans la colonne de gauche l’index du premier octet de la ligne correspondante, écrit en hexadécimal. On a bien 16 octets par ligne.
On se propose d’analyser la trame du début à la fin :
| 0000 | 00 50 7f 05 7d 40 | Adresse MAC de destination | Ethernet |
| 0006 | 00 10 a4 86 2d 0b | Adresse MAC source | Ethernet |
| 000c | 08 00 | Type (ici DoD Internet, soit IPv4) | Ethernet |
|---|---|---|---|
| 000e | 4 | Version du protocole IP | IPv4 |
| 000e | 5 | IP Header Length (en mots de 32 bits) : 20 octets | IPv4 |
| 000f | 00 | Type of service (e.g. 0) | IPv4 |
| 0010 | 02 19 | Longueur totale en octets : ici 0x0219 = 537 octets | IPv4 |
| 0012 | 17 98 | Identification du fragment 0x1798 = 6040 | IPv4 |
| 0014 | 40 00 | F1 + F0 (010 0000000000000) : ne pas frag (pas de frag) | IPv4 |
| 0016 | 40 | Time To live : 0x40 = 64 | IPv4 |
| 0017 | 06 | Protocole : 0x06 signifie TCP | IPv4 |
| 0018 | 6c 14 | Somme de contrôle | IPv4 |
| 001a | 0a 21 b6 b2 | Adresse IP source : 10.33.182.178 | IPv4 |
| 001e | c0 37 34 28 | Adresse IP destination : 192.55.52.40 | IPv4 |
| [Pas d’options, on a bien nos 20 octets] | |||
| 0022 | 84 b3 | Port source : 0x84b3 = 33971 | TCP |
| 0024 | 00 50 | Port destination : 0x0050 = 80 (le port HTTP canonique) | TCP |
| 0026 | b6 94 b0 b8 | Numéro de séquence | TCP |
| 002a | 24 67 89 e9 | Numéro d’acquittement | TCP |
| 002e | 8 | TCP Header Length (en mots de 32 bits) : 32 octets | TCP |
| 002e | 0 | Trois bits 0 réservés, plus un bit nonce (RFC 3540) | TCP |
| 002f | 18 | Flags, codé sur 8 bits. 0x18 = 0b00011000 (ACK, PSH) | TCP |
| 0030 | 16 d0 | Taille de fenêtre. 0x16d0 = 5856 octets (-16, à creuser) | TCP |
| 0032 | 60 e4 | Somme de contrôle | TCP |
| 0034 | 00 00 | Pointeur d’urgence | TCP |
| 0036 | 01 01 08 0a 00 6f a7 32 00 00 00 00 | Options sur 12 octets (32 de THL - 20 déjà passés) | TCP |
| [Les données arrivent maintenant] | |||
| [La couche application arrive ici : en général du texte] | |||
| [Ici, on a du HTTP] |
The Time To Live (TTL) field (8 bits) is to prevent packets from being shuttled around indefinitely on a network. It was originally intended to be lifetime in seconds, but it has come to be implemented as “hop count”. This means that every time a packet crosses a switch or router, the hop count is decremented by one. If it reaches zero, the packet is dropped. Typically if this happens, an ICMPv4 message (“time exceeded”) is returned to the packet sender. This mechanism is how the traceroute command works. Its primary purpose is to prevent looping (packets running around in circles).
Fonctionnement de la somme de contrôle :
Header Checksum The 16-bit IPv4 header checksum field is used for error-checking of the header. When a packet arrives at a router, the router calculates the checksum of the header and compares it to the checksum field. If the values do not match, the router discards the packet. Errors in the data field must be handled by the encapsulated protocol. Both UDP and TCP have checksum fields. When a packet arrives at a router, the router decreases the TTL field. Consequently, the router must calculate a new checksum.
Sequence number (32 bits)
Has a dual role:
- If the SYN flag is set (1), then this is the initial sequence number. The sequence number of the actual first data byte and the acknowledged number in the corresponding ACK are then this sequence number plus 1.
- If the SYN flag is clear (0), then this is the accumulated sequence number of the first data byte of this segment for the current session.
Acknowledgment number (32 bits) If the ACK flag is set then the value of this field is the next sequence number that the sender of the ACK is expecting. This acknowledges receipt of all prior bytes (if any). The first ACK sent by each end acknowledges the other end’s initial sequence number itself, but no data.
The 8 bits of the flags section :
- CWR (1 bit): Congestion Window Reduced (CWR) flag is set by the sending host to indicate that it received a TCP segment with the ECE flag set and had responded in congestion control mechanism (added to header by RFC 3168).
- ECE (1 bit): ECN-Echo has a dual role, depending on the value of the SYN flag. It indicates:
If the SYN flag is set (1), that the TCP peer is ECN capable. If the SYN flag is clear (0), that a packet with Congestion Experienced flag set (ECN=11) in the IP header was received during normal transmission (added to header by RFC 3168). This serves as an indication of network congestion (or impending congestion) to the TCP sender.
- URG (1 bit): indicates that the Urgent pointer field is significant
- ACK (1 bit): indicates that the Acknowledgment field is significant. All packets after the initial SYN packet sent by the client should have this flag set.
- PSH (1 bit): Push function. Asks to push the buffered data to the receiving application.
- RST (1 bit): Reset the connection
- SYN (1 bit): Synchronize sequence numbers. Only the first packet sent from each end should have this flag set. Some other flags and fields change meaning based on this flag, and some are only valid when it is set, and others when it is clear.
- FIN (1 bit): Last packet from sender.
window size (16 bits) the size of the receive window, which specifies the number of window size units (by default, bytes) (beyond the segment identified by the sequence number in the acknowledgment field) that the sender of this segment is currently willing to receive (see flow control and window scaling).
La structure de la trame est visible plus haut.
La couche liaison (ici, de type ethernet) nous donne simplement l’adresse MAC de la source et de la destination, ainsi que le protocole utilisé, ici le protocole internet version 4.
On a ici, dans la terminologie Tanenbaum :
Host-to-network (couche liaison) : ethernet Protocole internet : IPv4 Protocole transport : TCP Protocole application : HTTP
Comment sait-on que le protocole HTTP est utilisé dans la couche applicative, alors même qu’aucune documentation dans le sujet de Lab n’est fournie ? La transcription automatique en ASCII réduit dans la colonne de droite nous donne GET HTTP/1.1
Wireshark est un très bon analyseur de dump, qui vient aussi avec sa version en CLI, tshark.
Il peut être setup comme sonde, moyennant les droits du superutilisateur (fonctionne aussi sans, mais moins de fonctionnalités sont disponibles). On peut aussi s’en servir comme analyseur de dump. Il permet de faire ce qu’on a fait plus haut de manière bien moins fastidieuse :
- le dump est proprement séparé en paquets
- il ne reste que le signal
- les trois colonnes montrées plus haut sont affichées
- Les segments sont analysés et traduits, tous les calculs fastidieux sont faits
- On voit la correspondance entre le segment traduit et sa position dans le dump
Le support de ce lab précise en annexe la structure du réseau local, à laquelle on se réfèrera si besoin.
En gros, chaque poste de la salle 14-15 503 :
- Peut se connecter via un réseau d’administration à trois machines virtuelles installés sur des PC physiques de la salle des machines d’à côté (ces PC en racks sont connectés par un switch, lui-même connecté à un routeur)
- Ces machines virtuelles sont accessibles par l’adresse IP : 10.0.7.N1 et 10.0.7.N2 et 10.0.7.N3, N étant le numéro de la machine physique de la salle. Ces adresses IP sont celles rattachées à l’interface réseau eth0 des machines virtuelles (donc dans le réseau d’administration)
- Ces machines virtuelles disposent d’une autre interface réseau eth1 qui permet d’accéder à un autre LAN qui regroupe les trois VM d’un poste (et uniquement celles-ci) : ce réseau LAN est donc probablement virtuel, il en faut un par poste. Les adresses IP sur ce réseau sont donc de la forme : 10.N.1.N1 et 10.N.1.N2 et 10.N.1.N3. Ce réseau est isolé de l’autre, et c’est sur ce réseau-là que les analyses de trafic se feront.
Il y a trois machines virtuelles : une pour jouer le client, une pour jouer le serveur, et une pour sonder (wireshark devra être plug sur celle-ci).
On se connecte en SSH sur les trois machines, en permettant la transmission des données graphiques du serveur X (flag -X ou -Y pour désactiver les contrôles de sécurité, utilisé en pratique). C’est sur la machine 2 qu’on lance wireshark, et on plug wireshark sur l’interface réseau eth1. Physiquement, ce sont les routeurs CISCO de la salle des machines qui assurent la duplication des données.
Un protocole applicatif est un protocole (soit un ensemble de règles, et une structure obligatoire, qui régissent l’envoi et la réception des paquets) situé au niveau de la couche applicative, soit la couche la plus haute dans le modèle TCP/IP et dans le modèle OSI. La couche applicative correspond à la communication processus à processus en faisant abstraction des couches inférieures.
Firefox : protocole applicatif HTTP, HTTPS, FTP, etc… Emacs : protocole applicatif HTTP, HTTPS (via un client HTTP, HTTPS intégré)
Le modèle client-serveur, les applications en pair à pair (ce qui est une extension du modèle client-serveur).
Les participants sont donc soit des clients, soit des serveurs (soit les deux à la fois).
Si on prend l’exemple de l’application HTTP, on distingue le client et le serveur à la chose suivante : le serveur est un processus démon, qui tourne tout le temps en arrière-plan pour écouter des requêtes, et le client formule les requêtes.
Même chose pour le protocole applicatif SSH, par exemple : le serveur se reconnaît à ce que c’est lui qui exécute les instructions, le client à ce que c’est lui qui les envoie.
On peut penser aux applications de contrôle à distance (style telnet, rlogin, ssh), qui ont :
- Peu de débit demandé (au fond, on ne transmet que du texte dans les deux sens)
- Mais une latence faible (on veut que le prompt soit réactif)
- Grosse sensibilité aux pertes (pas d’erreur, mais des re-demandes de paquets et donc des plus grosses latences)
Aux applications de jeu vidéo en ligne :
- Un peu de débit demandé (on transmet du texte, mais on en transmets beaucoup, et de manière redondante).
- Latence très faible demandée
- Tolérance aux pertes élevées
La meilleure application est la capacité qu’on obtient d’administrer un grand nombre de machines à distance. Les machines peuvent désormais être stockées et entassées dans des endroits spécialisés.
Des informations de contrôle, principalement, des informations du système de fichier distant, ou d’administration.
Comme d’habitude, on se connecte sur les machines virtuelles (serveur, client, traceur).
On se connecte en telnet de la machine 1 à la machine 3.
On peut voir la trace :
| 0000 | 06 aa 03 3b 5c 08 06 aa 01 97 23 b5 08 00 45 10 |
| 0010 | 00 4f 27 cb 40 00 40 06 fb c2 0a 0c 01 79 0a 0c |
| 0020 | 01 7b a2 14 00 17 56 48 c1 90 79 d1 19 60 80 18 |
| 0030 | 00 e5 95 a1 00 00 01 01 08 0a 7a 4f e6 46 68 49 |
| 0040 | 33 a5 ff fd 03 ff fb 18 ff fb 1f ff fb 20 ff fb |
| 0050 | 21 ff fb 22 ff fb 27 ff fd 05 ff fb 23 |
si on se limite à la couche applicative :
| 0042 | ff fd 03 ff fb 18 ff fb 1f ff fb 20 ff fb 21 ff | ........... ..!. |
| 0052 | fb 22 ff fb 27 ff fd 05 ff fb 23 | .”..’.....# |
Telnet Do Suppress Go Ahead Command: Do (253) Subcommand: Suppress Go Ahead Will Terminal Type Command: Will (251) Subcommand: Terminal Type Will Negotiate About Window Size Command: Will (251) Subcommand: Negotiate About Window Size Will Terminal Speed Command: Will (251) Subcommand: Terminal Speed Will Remote Flow Control Command: Will (251) Subcommand: Remote Flow Control Will Linemode Command: Will (251) Subcommand: Linemode Will New Environment Option Command: Will (251) Subcommand: New Environment Option Do Status Command: Do (253) Subcommand: Status Will X Display Location Command: Will (251) Subcommand: X Display Location
[analyse ici]
[analyse ici]
Forme du document en plain-texte, lisible partout, en particulier pour les terminaux 80x24 caractères.
Section sur toutes les fonctions FTP, séparé en deux sections. Une section qui explique les codes numériques, à quoi ils correspondent.
Contraintes sur les serveurs.
Les commandes FTP, les arguments demandés.
On dit que les in
RFC 959, pages 47 et 48.
The following are the FTP commands: USER <SP> <username> <CRLF> PASS <SP> <password> <CRLF> ACCT <SP> <account-information> <CRLF> CWD <SP> <pathname> <CRLF> CDUP <CRLF> SMNT <SP> <pathname> <CRLF> QUIT <CRLF> REIN <CRLF> PORT <SP> <host-port> <CRLF> PASV <CRLF> TYPE <SP> <type-code> <CRLF> STRU <SP> <structure-code> <CRLF> MODE <SP> <mode-code> <CRLF> RETR <SP> <pathname> <CRLF> STOR <SP> <pathname> <CRLF> STOU <CRLF> APPE <SP> <pathname> <CRLF> ALLO <SP> <decimal-integer> [<SP> R <SP> <decimal-integer>] <CRLF> REST <SP> <marker> <CRLF> RNFR <SP> <pathname> <CRLF> RNTO <SP> <pathname> <CRLF> ABOR <CRLF> DELE <SP> <pathname> <CRLF> RMD <SP> <pathname> <CRLF> MKD <SP> <pathname> <CRLF> PWD <CRLF> LIST [<SP> <pathname>] <CRLF> NLST [<SP> <pathname>] <CRLF> SITE <SP> <string> <CRLF> SYST <CRLF> STAT [<SP> <pathname>] <CRLF> HELP [<SP> <string>] <CRLF> NOOP <CRLF>
<username> ::= <string> <password> ::= <string> <account-information> ::= <string> <string> ::= <char> | <char><string> <char> ::= any of the 128 ASCII characters except <CR> and <LF> <marker> ::= <pr-string> <pr-string> ::= <pr-char> | <pr-char><pr-string> <pr-char> ::= printable characters, any ASCII code 33 through 126 <byte-size> ::= <number> <host-port> ::= <host-number>,<port-number> <host-number> ::= <number>,<number>,<number>,<number> <port-number> ::= <number>,<number> <number> ::= any decimal integer 1 through 255 <form-code> ::= N | T | C <type-code> ::= A [<sp> <form-code>]
E [<sp> <form-code>] I L <sp> <byte-size> <structure-code> ::= F | R | P <mode-code> ::= S | B | C <pathname> ::= <string> <decimal-integer> ::= any decimal integer
[analyse ici]
Par la définition d’un client et d’un serveur, c’est le client qui initie la connexion.
On ne l’observe dans la capture qu’à condition de ne pas avoir filtré (ftp || ftp-data). Sinon, on croit voir le serveur qui initie la connexion, ce qui n’est pas possible.
En vérité, le client initie la connexion par une requête TCP vide vers le port où le serveur ftp écoute (par défaut 21, mais ce n’est pas obligatoire) (vide au sens où il n’y a rien après la couche TCP de la requête). (l’option NOP de l’en-tête est activée)
Le serveur renvoie une réponse qui est aussi vide après la couche TCP : les flags SYN (demande de ACK) et ACK sont activés.
Le client répond par un ACK : tout va bien.
Le serveur initie la première requête TCP non-vide, qui est une réponse au dernier ACK. La couche applicative suit le protocole FTP, bien entendu, et donne une réponse 220 (prêt)
Le client ACK.
Le serveur demande un login.
C’est la commande USER du protocole FTP qui identifie l’utilisateur. Dans notre exemple, elle a un unique argument qui est le nom d’utilisateur qu’on peut lire, parce qu’il est envoyé en clair.
Le serveur ACK.
Et il envoie la réponse 331 : besoin du mot de passe.
Le client ACK.
La commande qui identifie l’utilisateur est la commande FTP PASS. Le mot de passe apparaît bien en clair sur le réseau, en argument de la commande PASS.
Le serveur répond par le code 230 (user logged in, proceed) si tout se passe bien, sinon :
530 (Incorrect login), et le serveur redemande le login et le mot de passe.
La commande client qui suit l’authentification est SYST, elle sert au client à connaître le système du serveur. La réponse est UNIX. On ne comprend pas bien pourquoi le client aurait besoin d’en connaître.
La commande PORT est vitale. Le protocole FTP est un protocole hors-bande, ce qui signifie que le contrôle et les données ne transitent pas par le même port.
Le client dit au serveur sur quel port il tient à recevoir des données. On peut le voir dans les arguments de la commande :
10,13,1,131,141,197.
Les deux derniers nombres (141, 197) doivent être convertis pour en faire le port.
141 est écrit en trois caractères ASCII : donc trois octets 31 34 31 on déparse la virgule. 2c 197 est écrit en trois caractères ASCII : donc trois octets 31 39 37
141 doit en fait être interprété comme un nombre écrit sur un octet (alors qu’il est écrit sur trois, mais passons). 197 aussi.
Ce qui nous donne un nombre écrit sur deux octets (sur lesquels il est bien possible d’écrire les nombres de 0 à 65535).
Elle est émise à ce point de l’échange parce que le serveur doit savoir où envoyer les données avant de pouvoir les envoyer. Si la question était : “pourquoi est-elle émise seulement maintenant ?”, parce qu’on en avait pas besoin avant.
La requête LIST, comme toutes les requêtes qui demandent effectivement des données (LIST demande des données, pour les gens qui n’étaient pas sûrs. EVERYTHING IS A FILE), suscite deux réponse de la part du serveur.
La première réponse est une réponse de contrôle (genre oui/non/peut-être) envoyé sur le port de contrôle du client. Le deuxième réponse consiste en les données effectives.
CWD sert à changer le répertoire courant (elle ne renvoie pas de données, donc une seule connexion).
Les transferts de fichier ont lieu dès qu’on les demande, après que la réponse 150 de contrôle a été envoyée.
On a un timeout (900 secondes) qui se manifeste par l’envoi par le serveur d’un message de timeout, qui est ACKé par le client. La connexion est fermée côté serveur.
Quand la commande FTP QUIT est envoyée par le client, le serveur répond par 221 (Goodbye).
Le client ACK et, vu que la communication FTP est terminée, il envoie un message TCP vide portant le flag FIN pour initier la fin de la communication TCP. Le serveur répond avec aussi un message TCP vide portant les flags FIN et ACK.
Le client répond avec un dernier ACK, et c’en est fini de cette communication TCP.
A quoi correspondent les données échangées sur la connexion de transfert de données ?
Aux données demandées, sans encodage : tout est transmis tel quel, en paquets de 1448 octets. Donc wireshark pourra lire le texte si on a du texte et si on a du binaire on comprendra rien.
Sur le port demandé lors de la connexion PORT envoyé au préalable par le client.
Les messages sur la connexion de données sont envoyés juste après les messages sur la connexion de contrôle.
Le fonctionnement des protocoles.
scp est un ensemble de commandes assimilables à la famille des commandes UNIX rcp, mais encapsulé dans une connexion SSH.
sftp est en fait le même protocole que FTP, mais conçu pour être facilement encapsulable dans du SSH.
A priori non. Tout ce que j’arrive à reconnaître, ce sont les trames de données, par leur taille. On ne sait même pas sur quel port les
La transmission cryptée plutôt que la transmission en clair est la principale différence fonctionnelle.
Une différence au niveau de l’implémentation, c’est qu’il n’est pas sûr que sftp ouvre des connexions distinctes par fichier : a priori, toutes les communications passent par le même port.
TFTP est basé sur le protocole transport UDP. Il est extrêmement simple, il n’y a que 5 messages :
- RRQ (opcode 1) requête de lecture
- WRQ (opcode 2) requête d’écriture
- DATA (opcode 3) données numérotées
- ACK (opcode 4) acquittement
- ERREUR (opcode 5) message d’erreur
les messages DATA sont de 512 octets (sauf le dernier bien sûr)
Les messages DATA sont numérotés, et immédiatement acquittés.
On n’a pas les permissions suffisantes pour réaliser un transfert de fichier fonctionnel.
Le dossier sur lequel tftpd n’est pas accessible en écriture.
Beaucoup plus simple, basé sur UDP/IP, pas de synchronisation, pas de timeout. Contrôle in-band.
On a un fichier index.html et deux objets appelés img1.jpg et img2.jpg (logés sur le même serveur).
Trois requêtes GET donc, et on n’a la page qu’à la fin du tranfert des trois objets :
| Client | Serveur | ||
| GET /index.html | -> | ||
| >- | 200 OK | ||
| <- | |||
| -< | |||
| Je dois charger img1 et img2 ! | |||
| GET /img1.jpg | -> | ||
| >- | 200 OK | ||
| <- | |||
| -< | |||
| GET /img2.jpg | -> | ||
| >- | 200 OK | ||
| <- | |||
| Page chargée ! | -< |
Les principales optimisations introduites par HTTP/1.1 :
- La possibilité d’avoir des connexions persistantes : on peut inclure plusieurs couples de requête puis réponse dans une connexion HTTP.
- Le caching des ressources est grandement amélioré : avant HTTP/1.1 le cache était spécifique à une ressource. Les ressources, si elles sont les mêmes, peuvent être taguées pour que le lien entre elles puissent être fait.
| Client | Serveur | ||
| GET / | -> | ||
| >- | 200 OK | ||
| <- | |||
| -< | |||
| Eventuellement plusieurs fois, si plusieurs objets | |||
| Page chargée ! |
On imagine les gains en cas de plein de petits objets avec des gros en-têtes.
Le cache est en général une excellente manière de réduire la latence des entrées/sorties (et un accès réseau est un genre d’entrée/sortie) : c’est basé sur l’idée que certaines ressources sont demandées fréquemment, sans être fréquemment modifiées. Dans ce cas, garder la ressource en question dans un matériel quelconque dont le temps d’accès est plusieurs ordre de grandeur en deçà de l’accès à la “vraie” ressource fait sens. Avant d’utiliser la ressource cachée, on prend bien soin de vérifier qu’elle n’a pas été modifiée dans sa “vraie” version. En général, la taille du cache est plusieurs ordres de grandeur plus petite que la taille des toutes les ressources qu’on requiert.
On observe le mécanisme de récupération typique du HTTP 1.1 : on a bien une seule connexion HTTP, qui permet bien de récupérer index.html et l’image : le message TCP vide avec le flag FIN n’est envoyé qu’après que toute la page a été récupérée.
Si on avait un serveur sous HTTP 1.0, on verrait plusieurs débuts de connexion TCP (avec le handshake triple) et plusieurs fins (le message TCP vide avec le flag FIN) (deux exactement).
Ceux-là exactement :
Hypertext Transfer Protocol GET / HTTP/1.1\r\n Host: 10.13.1.133\r\n User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0\r\n Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n Accept-Language: en-US,en;q=0.5\r\n Accept-Encoding: gzip, deflate\r\n Connection: keep-alive\r\n \r\n
Dans cette requête de GET, le client (ici Mozilla) dit qui il est (Mozilla), sous quel serveur graphique, système d’exploitation et jeu d’instructions processeur il fonctionne) : a priori tout ça c’est son problème, le serveur n’a pas à s’en soucier.
Ensuite le client dit les types de fichier qu’il veut bien télécharger (en type MIME) Il dit aussi l’encodage qu’il accepte l’encodage gzip
Et la localisation souhaitée.
Le serveur peut décider de ne tenir aucun compte de ces informations.
L’encodage gzip, par exemple, qu’on peut voir dans l’en-tête de la réponse.
Hypertext Transfer Protocol HTTP/1.1 200 OK\r\n Date: Fri, 04 Oct 2019 19:50:44 GMT\r\n Server: Apache/2.4.25 (Debian)\r\n Last-Modified: Mon, 08 Jul 2019 17:20:00 GMT\r\n ETag: “29cd-58d2ea76f3cdd-gzip”\r\n Accept-Ranges: bytes\r\n Vary: Accept-Encoding\r\n Content-Encoding: gzip\r\n <---- ICI Content-Length: 3041\r\n Keep-Alive: timeout=5, max=100\r\n Connection: Keep-Alive\r\n Content-Type: text/html\r\n \r\n
Content-encoded entity body (gzip): 3041 bytes -> 10701 bytes File Data: 10701 bytes
Oui, wireshark le fait
Bob accède à sa messagerie par le web : Il se connecte sur un site web, à une application web hébergée sur un serveur quelconque, via le protocole applicatif HTTP.
C’est cette machine à qui Bob transmet ses instructions (écrire le message, avoir envoyé ses identifiants et son mot de passe.) qui va contacter le serveur SMTP (qui peut être hébergé sur la même machine, ou non).
Le client SFTP contacte le serveur SFTP à l’aide des commandes SMTP usuelles : HELO, MAIL <son identifiant>, RCPT <l’adresse d’Alice>.
Le récepteur est validé, le mail est envoyé par le serveur SMTP.
Il est stocké sur le serveur du fournisseur mail de Alice.
Alice rapatrie ses messages sur sa machine locale : implique soit le protocole POP3, IMAP.
On imagine que c’est IMAP :
La machine locale d’Alice demande la synchronisation de la version de la boîte mail distante avec la sienne propre, via le protocole IMAP4.
Les messages échangés par les serveurs de courrier électroniques consistent juste en du texte :
From: Olivier Fourmaux <[email protected]> Date: Wed, 20 Feb 2002 01:21:01 +0100 To: Toto <[email protected]> Subject: Document no 3.02 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=”/9DWx/yDrRhgMJTb” Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i
–/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit
Voici le document secret que vous m’avez demandé…
–/9DWx/yDrRhgMJTb Content-Type: application/pdf Content-Disposition: attachment; filename=”sujet-exam-RES.pdf” Content-Transfer-Encoding: base64 JVBERi0xLjIKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nO1dy7YdtRGd3684Mx6L07T63ZkBdghgXvYlJFlMHNsYm+sHhkCS…
On peut bien sûr transférer autre chose que du texte, comme ici un document PDF, qui sera transféré octet par octet.
Les choses qui constituent les métadonnées pour le client font bien partie du message en vrai. Le client parse ce fichier texte et remplit les champs de méta-données pour son utilisateur.
Base64 consiste en la possibilité de coder des caractères écrivables sur 8 bits sur un set de caractères d’encodage de 6 bits : 3 vrais caractères sont codés sur 4 faux. De cette manière, on peut utiliser le protocole SMTP, POP et IMAP, qui requièrent absolument du NVT (ASCII réduit à 7 bits), tout en écrivant des caractères codables sur 8 bits. Ca ne dispense pas d’avoir un grand nombre de charset pour écrire tous les langages du monde.
On se sert d’un outil en ligne :
C’est pas facmle !
D’après la liste des en-têtes MIME fournies par Olivier Fourmaux, ça devrait ressembler à peu près à ça.
From: Olivier Fourmaux <[email protected]> Date: Wed, 20 Feb 2002 01:21:01 +0100 To: Toto <[email protected]> Subject: Document no 3.02 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=”/9DWx/yDrRhgMJTb” Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i
–/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit
Voici le document secret que vous m’avez demandé…
–/9DWx/yDrRhgMJTb Content-Type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit
// HTML OUAIS !
–/9DWx/yDrRhgMJTb Content-Type: image/png; Content-Disposition: attachment; filename=”monimage.png”” Content-Transfer-Encoding: base64 gibberishgibberish......
–/9DWx/yDrRhgMJTb Content-Type: audio/mpeg; Content-Disposition: attachment; filename=”monson.mp3”” Content-Transfer-Encoding: base64 (…se_balade_en_ville_avec_un_brelic)boobapoetemoderne......
//Ici le WAD pour DOOM, on n’a pas
cherchétrouvé le mime type pour ce fichier.
Commandes observées su protocole SMTP :
(aparté : on croit voir le serveur initier la connexion, c’est faux : il y a une query TCP vide avant)
Client : EHLO client.etu13.plateforme.lan (sert à se présenter et à demander les options)
Serveur : Response: 250-mail.etu13.plateforme.lan\r\n Response: 250-PIPELINING\r\n Response: 250-SIZE 10240000\r\n Response: 250-VRFY\r\n Response: 250-ETRN\r\n Response: 250-STARTTLS\r\n Response: 250-ENHANCEDSTATUSCODES\r\n Response: 250-8BITMIME\r\n Response: 250 DSN\r\n (Voilà les options supportées par le serveur SMTP.)
Client : MAIL FROM:<[email protected]>\r\n (sert à donner l’expéditeur du message)
Serveur : Response: 250 2.1.0 Ok\r\n (tout s’est bien passé)
Client : RCPT TO:<[email protected]>\r\n (sert à donner le destinataire du message)
Serveur : Response: 250 2.1.0 Ok\r\n (tout s’est bien passé)
Client : DATA (vide : manière de prévenir qu’on va envoyer le message)
Serveur Response: 354 End data with <CR><LF>.<CR><LF>\r\n (Commence à envoyer le message, Fini avec la séquence donnée)
Client : DATA Message-ID: <[email protected]>
puis, en Internet Message Format :
Message-ID: <[email protected]> Subject: Test de hongrois From: etudiant sur la VM 3 <[email protected]>, 1 item Item: etudiant sur la VM 3 <[email protected]>\r\n To: [email protected], 1 item Date: Fri, 11 Oct 2019 20:06:39 +0200 Content-Type: text/plain; charset=”UTF-8” X-Mailer: Evolution 3.22.6-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Line-based text data: text/plain \303\266sz\303\266n\303\266m\r\n
(aparté : L’encodage est en UTF-8 échappé, on avait écrit : öszömön (mercè !))
Serveur : Response: 250 2.0.0 Ok: queued as 0BF681C03F9\r\n (Bien reçu, mis en queue, je l’envoie dès que je peux)
Client : QUIT\r\n (Pour terminer la communication)
Serveur : Response: 221 2.0.0 Bye\r\n (OK, bonne soirée)
Quelles sont les contraintes imposées à la forme du courrier ?
On ne peut envoyer que des caractères ASCII NVT. Les caractères UTF8 doivent être échappés (truc par défaut en 2019, on a l’air d’avoir laissé tombé les trucs du genre de Base64)
En revanche, ça a l’air d’être tout : Le message peut être peuplé de champs qui permettront aux clients de rendre des “fausses” méta-données (dans le sens où elles font bel et bien partie des données.) Le champ sujet ou date, par exemple, est complètement facultatif : et modifiable directement par l’utilisateur, s’il décide de prendre la main sur son client.
A aucun moment il n’a été demandé de mot de passe : il est possible de demander un mot de passe haché avec ESMTP.
Il suffit de suivre la séquence de commandes qu’Olivier Fourmaux a montré en cours.
La séquence des opérations se passe plus ou moins de la même manière.
Ca dépend ce que je veux capturer : dans notre cas, on veut du trafic SMTP.
Connexion via HTTP non disponible.
Les commandes successivement produites sont :
CAPA USER <login> PASS <password> LIST UIDL QUIT
(on a l’air d’avoir une erreur à USER, regarder les trames modèles)
Supports de Lab :
Timur insiste sur l’importance des chronogrammes.
[On incluera une photo]