Couche 7 : l'application — HTTP, DNS, DHCP et le sommet de la pile

Septième et dernier étage. On est parti du câble, on a traversé les adresses MAC, l’IP et le routage, TCP et les ports, et on a constaté que les couches 5 et 6 étaient des fantômes. Nous voilà au sommet.

Et le sommet, c’est là où tout le monde vit. La couche 7, c’est celle que vous voyez : le navigateur qui charge une page, le mail qui part, le nom de domaine qui se résout, la machine qui reçoit son IP au démarrage. C’est la couche des applications — la seule que l’utilisateur touche directement, et de loin la plus riche en protocoles.

Après quatre couches qui transportaient des octets sans en connaître le sens, on arrive enfin là où les octets veulent dire quelque chose. GET /index.html, A aperturezone.fr, DHCPDISCOVER : ce ne sont plus des paquets anonymes, ce sont des phrases.

L’essentiel en 30 secondes

• La couche 7 donne un sens aux octets que les couches basses transportaient à l’aveugle.
• DNS traduit les noms en IP. Sans lui, Internet serait une liste de numéros. « Ce n’est jamais le réseau, c’est toujours le DNS. »
• DHCP distribue les IP automatiquement, en 4 temps : DORA (Discover, Offer, Request, Ack).
• HTTP est sans état : chaque requête est indépendante. Cookies et sessions sont des rustines pour contourner ça.
• HTTPS = HTTP + TLS. Le S n’est pas un protocole, c’est une couche de chiffrement en dessous.
• Le port n’est qu’une convention : 80 pour HTTP, 443 pour HTTPS, 53 pour DNS, 67/68 pour DHCP.
• En diagnostic, on remonte la pile : le câble marche, l’IP est bonne, TCP se connecte… et ça bloque en couche 7. C’est là que se cachent les pannes les plus retorses.

Ce que fait vraiment la couche 7

Petite mise au point qui évite un contresens fréquent : la couche 7 n’est pas l’application elle-même. Firefox n’est pas « la couche 7 ». La couche 7, c’est le protocole que l’application parle pour communiquer sur le réseau — HTTP pour le web, SMTP pour le mail, DNS pour la résolution de noms.

La distinction est utile : votre navigateur est un programme qui, entre autres choses, parle HTTP. HTTP est le protocole de couche 7 ; le navigateur est le logiciel qui l’utilise. De la même façon qu’une lettre suit les règles de la poste (le protocole) sans être la poste elle-même.

Ce que la couche 7 apporte, que les couches basses ignorent : la sémantique. TCP sait livrer un flux d’octets fiable entre deux ports. Il ne sait pas que ces octets forment une requête web, un courriel ou une question DNS. C’est le protocole applicatif qui donne cette structure — qui dit « ces octets-ci sont une commande, ceux-là sont des données, et voici comment les interpréter ».

Passons aux protocoles qui comptent au quotidien. Trois méritent le détail : DNS, DHCP, HTTP.

DNS : l’annuaire d’Internet

Le problème qu’il résout.

Les machines se joignent par adresse IP — 93.184.216.34. Les humains retiennent des noms — aperturezone.fr. Le DNS (Domain Name System) est le pont : il traduit les noms en adresses IP. Sans lui, il faudrait connaître par cœur l’IP de chaque site. C’est l’annuaire téléphonique d’Internet, à ceci près qu’il tient des milliards d’entrées et se met à jour en permanence.

Comment ça marche : la résolution récursive.

Quand vous tapez un nom, votre machine ne connaît pas la réponse. Elle demande à un résolveur (souvent celui de votre FAI, ou un public comme 1.1.1.1), qui mène l’enquête pour elle. Cette enquête suit la hiérarchie du nom, de droite à gauche :

1. Les serveurs racine (les fameux « root servers ») : ils ne connaissent pas aperturezone.fr, mais ils savent qui gère le .fr.
2. Les serveurs TLD (Top Level Domain) du .fr : ils ne connaissent pas non plus l’adresse, mais ils savent quel serveur fait autorité sur aperturezone.fr.
3. Le serveur faisant autorité pour aperturezone.fr : lui a la réponse, et la donne.

Le résolveur remonte la chaîne, obtient l’IP, vous la renvoie, et — crucial — la met en cache. La prochaine requête pour le même nom sera instantanée, jusqu’à expiration du TTL (durée de vie de l’enregistrement, en secondes).

Les types d’enregistrements à connaître.

Un nom de domaine ne pointe pas que vers une IP. Le DNS stocke plusieurs types d’enregistrements, et un TSSR doit reconnaître les principaux :

Le MX est celui qu’on oublie et qui fait rater des mails ; le PTR (résolution inverse) est indispensable pour qu’un serveur mail ne soit pas classé spam ; les TXT portent aujourd’hui toute la sécurité mail (SPF, DKIM, DMARC).

« Ce n’est jamais le réseau, c’est toujours le DNS. »

Cette phrase est une blague d’administrateur, et elle est vraie plus souvent qu’on ne le croit. Un nombre considérable de pannes « réseau » sont en réalité des pannes DNS : un serveur qui ne résout plus, un cache empoisonné, un TTL mal réglé qui fait traîner une migration, un enregistrement oublié. Le symptôme classique, on l’a vu en couche 3 : ping 8.8.8.8 passe (l’IP marche), ping google.com échoue (le nom ne se résout pas). Quatre couches fonctionnent parfaitement, et c’est le septième étage qui bloque.

Les commandes.

dig aperturezone.fr              # la référence, sortie détaillée
dig aperturezone.fr MX           # interroger un type précis
dig +short aperturezone.fr       # juste la réponse, sans le bruit
dig -x 93.184.216.34             # résolution inverse (PTR)
nslookup aperturezone.fr         # l'ancêtre, présent partout (Windows inclus)
host aperturezone.fr             # simple et lisible
resolvectl query aperturezone.fr # systemd, le cache local

dig est l’outil du métier. dig +short répond en une ligne à « ce nom résout-il, et vers quoi ». Et quand un client dit « le site est down », le premier réflexe est dig sur son nom : si la résolution échoue, le site va très bien — c’est le DNS.

DHCP : l’IP automatique

Le problème qu’il résout.

Une machine qui se branche sur le réseau a besoin d’une configuration IP : une adresse, un masque, une passerelle, un serveur DNS. La saisir à la main sur chaque poste est impensable à l’échelle. Le DHCP (Dynamic Host Configuration Protocol) automatise tout : la machine demande, le serveur attribue.

Comment ça marche : DORA.

L’échange se fait en quatre temps, dont l’acronyme est à retenir par cœur — DORA :

1. D — Discover : la machine qui démarre n’a pas d’IP. Elle crie en broadcast sur le réseau : « y a-t-il un serveur DHCP ? » (elle ne peut pas faire autrement — sans IP, elle ne peut viser personne en particulier).
2. O — Offer : le serveur DHCP répond : « voici une IP que je te propose, avec le masque, la passerelle, le DNS ».
3. R — Request : la machine accepte formellement : « je prends celle-là ». (En broadcast aussi, pour informer les autres serveurs DHCP éventuels que leur offre est déclinée.)
4. A — Acknowledge : le serveur confirme : « c’est à toi, pour telle durée ». Cette durée est le bail (lease).

À partir de là, la machine a sa config, pour la durée du bail. Elle tentera de le renouveler avant expiration (à 50 % de la durée, elle redemande directement au serveur qui l’a servie — pas besoin de tout recommencer).

Le lien avec les couches basses.

Le Discover en broadcast, c’est le FF:FF:FF:FF:FF:FF de la couche 2, et l’adresse IP source 0.0.0.0 (« je n’ai pas encore d’adresse ») de la couche 3. DHCP tourne sur UDP, ports 67 (serveur) et 68 (client) — cohérent avec ce qu’on a vu en couche 4 : une transaction courte, sans besoin d’établir une connexion.

Le piège du relais.

Un broadcast ne franchit pas un routeur (on l’a vu en couche 3). Donc si votre serveur DHCP est sur un autre sous-réseau que le client — cas classique en entreprise avec des VLAN — le Discover n’atteint jamais le serveur. La solution est le DHCP relay (ip helper-address sur le routeur ou le switch L3) : il capte le broadcast local et le transmet en unicast au serveur distant. Sans lui, une machine dans un VLAN sans serveur DHCP local reste sans IP — et se rabat sur une adresse APIPA en 169.254.x.x, le symptôme qu’on a appris à reconnaître en couche 3 : « le DHCP n’a pas répondu ».

Les commandes.

# Linux — obtenir / renouveler un bail
sudo dhclient -v eth0            # demander une IP (verbeux)
sudo dhclient -r eth0            # libérer le bail

# Windows
ipconfig /release                # libérer
ipconfig /renew                  # renouveler
ipconfig /all                    # voir le bail, le serveur DHCP, la durée

# Côté serveur (Linux ISC / Kea)
journalctl -u isc-dhcp-server    # les logs d'attribution
cat /var/lib/dhcp/dhcpd.leases   # les baux en cours

ipconfig /all côté client est le réflexe de diagnostic : il montre quel serveur DHCP a répondu et quelle durée de bail. Une machine en 169.254.x.x avec « bail expiré » dans cette sortie, c’est un DHCP injoignable — câble, VLAN, ou relais manquant.

HTTP : le protocole du web

Ce qu’il est.

HTTP (HyperText Transfer Protocol) est le langage du web. Un client (le navigateur) envoie une requête, un serveur renvoie une réponse. C’est un protocole texte, simple à lire, ce qui explique en partie sa domination.

Une requête minimale ressemble à ceci :

GET /index.html HTTP/1.1
Host: aperturezone.fr
User-Agent: Mozilla/5.0
Accept: text/html

Et la réponse :

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 3421

<!DOCTYPE html>...

Les méthodes.

Le premier mot de la requête est la méthode — ce que le client veut faire :

La distinction GET / POST est celle qu’un TSSR croise le plus : GET met ses paramètres dans l’URL (visibles, mis en cache, limités en taille) ; POST les met dans le corps (invisibles dans l’URL, adaptés aux données volumineuses ou sensibles). Un mot de passe passe en POST, jamais en GET.

Les codes de statut.

La réponse commence par un code à trois chiffres, dont le premier donne la famille. Les connaître, c’est diagnostiquer un problème web en une seconde :

La ligne de partage la plus utile : 4xx, c’est la faute du client (mauvaise URL, pas les droits, mal authentifié) ; 5xx, c’est la faute du serveur (plantage, surcharge, backend injoignable). Face à un 502 Bad Gateway, inutile de vérifier l’URL du client — le serveur web n’arrive pas à joindre le service derrière lui. Face à un 404, c’est l’URL qui est en cause, pas le serveur. Un seul chiffre oriente tout le diagnostic.

HTTP est sans état — et pourquoi ça compte.

Point fondamental : HTTP ne garde aucune mémoire d’une requête à l’autre. Chaque requête est traitée comme si c’était la première ; le serveur ne « sait » pas que vous avez chargé la page précédente. C’est ce qu’on appelle stateless.

Ça pose un problème évident : comment un site vous garde-t-il connecté d’une page à l’autre, si chaque requête est amnésique ? La réponse, ce sont les cookies : un petit jeton que le serveur donne au navigateur, et que celui-ci renvoie à chaque requête suivante. Le serveur reconnaît le jeton et retrouve votre session. Les cookies, les tokens, les sessions : tout cela n’existe que pour contourner l’absence de mémoire de HTTP. C’est une rustine géniale sur un protocole volontairement oublieux — volontairement, parce que le sans-état est justement ce qui permet à HTTP de passer à l’échelle de milliards de requêtes.

Les commandes.

curl -I https://aperturezone.fr           # juste les en-têtes (méthode HEAD)
curl -v https://aperturezone.fr           # toute la conversation, TLS compris
curl -L https://aperturezone.fr           # suivre les redirections 3xx
curl -X POST -d "champ=valeur" https://... # envoyer un POST
wget https://aperturezone.fr/fichier      # télécharger

curl -I est le test express : il montre le code de statut et les en-têtes sans télécharger la page. curl -v déroule toute la conversation — la négociation TLS, la requête, la réponse — et c’est l’outil qui départage « le serveur ne répond pas » de « le serveur répond mais avec une erreur ».

HTTPS et TLS : le cadenas

Ce que le S ajoute.

HTTPS, ce n’est pas un protocole différent de HTTP. C’est HTTP + TLS : le même protocole applicatif, mais transporté dans un tunnel chiffré. Le S veut dire Secure, et ce « secure » est entièrement le travail de TLS — cette couche fantôme qu’on a croisée en couches 5-6, qui chiffre sans appartenir vraiment à une couche du modèle.

Concrètement, la pile d’une page web sécurisée, de bas en haut :

HTTP          ← la requête (couche 7)
TLS           ← le chiffrement (la couche fantôme)
TCP           ← le transport fiable (couche 4)
IP            ← l'acheminement (couche 3)

Ce que TLS garantit.

Trois choses, à ne pas confondre :

• La confidentialité — personne sur le trajet ne peut lire le contenu. C’est le chiffrement.
• L’intégrité — personne ne peut modifier les données en transit sans être détecté.
• L’authentification — vous parlez bien au vrai serveur, pas à un imposteur. C’est le rôle du certificat.

Ce dernier point est le plus mal compris. Le cadenas ne dit pas « ce site est honnête ». Il dit « ce site est bien celui que son certificat prétend, et la communication est chiffrée ». Un site de phishing peut avoir un cadenas parfaitement valide — il chiffre juste le vol de vos données. HTTPS protège le transport, pas votre jugement.

Le certificat et la chaîne de confiance.

Le certificat du serveur est signé par une autorité de certification (CA) en qui votre navigateur a confiance. Cette confiance est pré-installée : votre système embarque une liste de CA racine de confiance. Le serveur présente son certificat, le navigateur vérifie qu’il est signé par une CA qu’il connaît, et que le nom du certificat correspond au domaine visité. Si tout colle, cadenas vert. Sinon, l’avertissement rouge — celui qu’il ne faut jamais contourner sans savoir pourquoi.

Les commandes.

openssl s_client -connect aperturezone.fr:443           # voir la négociation TLS
openssl s_client -connect aperturezone.fr:443 | openssl x509 -noout -dates  # dates de validité du certificat
curl -vI https://aperturezone.fr                        # en-têtes + infos TLS

openssl s_client est l’outil pour déboguer un certificat : il montre la chaîne, les dates de validité (un certificat expiré est une cause de panne extrêmement fréquente), et le nom pour lequel il a été émis.

Les autres protocoles de couche 7

Pour compléter le tableau — ceux qu’un TSSR croise sans forcément les manipuler en détail :

Deux remarques de terrain. NTP paraît anecdotique mais une heure fausse casse Kerberos, invalide des certificats et rend des logs incohérents — c’est une panne de couche 7 aux effets dévastateurs. Et SMTP/IMAP/POP3 illustrent une confusion classique : SMTP envoie, IMAP et POP3 reçoivent ; un client mail utilise les deux à la fois, un pour partir, un pour arriver.

La sécurité de la couche 7

C’est la couche la plus exposée, parce que c’est celle qui traite directement les données de l’utilisateur — donc celle où l’attaquant injecte ses données à lui. Les couches basses transportent ; la couche 7 interprète, et tout ce qui interprète peut être trompé.

Les grandes familles d’attaques applicatives :

• Injection SQL — l’attaquant glisse du code SQL dans un champ de formulaire ; si l’application concatène bêtement l’entrée dans sa requête, elle exécute le code de l’attaquant. La parade : les requêtes préparées, jamais de concaténation.
• XSS (Cross-Site Scripting) — l’attaquant injecte du JavaScript dans une page ; il s’exécute dans le navigateur des autres visiteurs. La parade : échapper systématiquement les sorties.
• Détournement de session — voler le cookie de session pour usurper une identité. La parade : cookies Secure et HttpOnly, HTTPS partout.
• DNS spoofing / cache poisoning — empoisonner un cache DNS pour rediriger un nom vers une IP pirate. La parade : DNSSEC, qui signe cryptographiquement les réponses DNS.
• Phishing — l’attaque de couche 7 la plus efficace, parce qu’elle vise l’humain, pas la machine. Aucune parade technique n’est totale ; la formation reste la meilleure défense.

Le point commun de tout ce qui précède rejoint le fil rouge de la série : ces protocoles ont été conçus quand le réseau était un lieu de confiance. HTTP, DNS, SMTP datent d’une époque où l’on ne se méfiait pas. La sécurité a été ajoutée par-dessus — HTTPS sur HTTP, DNSSEC sur DNS, SPF/DKIM sur SMTP. Toujours la même histoire : une base naïve, des rustines de sécurité greffées après coup.

Diagnostiquer en remontant la pile

Voici la vraie récompense d’avoir parcouru les sept couches : une méthode de diagnostic qui les remonte une à une. Quand « ça ne marche pas », on teste étage par étage, du bas vers le haut, et l’endroit où ça casse est le diagnostic.

1. Couche 1 — le câble est-il branché ? La LED du port est-elle allumée ? (ip link montre l’état physique.)
2. Couche 2 — la machine a-t-elle une adresse MAC active, voit-elle son voisinage ? (ip neigh, arping.)
3. Couche 3 — a-t-elle une IP cohérente, joint-elle sa passerelle ? (ip addr, ping <passerelle>.)
4. Couche 4 — le port du service répond-il ? (ss, nc -zv.)
5. Couche 7 — le nom résout-il, le service applicatif répond-il correctement ? (dig, curl -v.)

La séquence de ping de la couche 3 était déjà une version de ceci. La voici complète, du câble à l’application :

ip link show eth0            # 1 — le lien physique est-il up ?
ping <ma passerelle>         # 3 — mon réseau local marche-t-il ?
ping 8.8.8.8                 # 3 — je sors ?
dig google.com              # 7 — le DNS résout-il ?
curl -I https://google.com  # 7 — le service HTTP répond-il ?

L’endroit où la séquence s’arrête désigne la couche fautive. Ça marche jusqu’au ping 8.8.8.8 mais dig échoue → DNS (couche 7). Ça résout mais curl renvoie 502 → service applicatif (couche 7 aussi, mais côté serveur). Ça ne dépasse pas la passerelle → routage (couche 3). Cette méthode, c’est toute la série condensée en cinq lignes.

Les erreurs classiques

• Confondre l’application et le protocole. Firefox n’est pas la couche 7 ; HTTP l’est. Firefox parle HTTP.
• Croire que le cadenas HTTPS garantit un site honnête. Il garantit le chiffrement et l’identité du certificat, pas les intentions du site.
• Oublier le DNS dans un diagnostic. « Ce n’est jamais le réseau » — vérifiez la résolution avant d’accuser le câble.
• Confondre 4xx et 5xx. 4xx = faute du client (URL, droits) ; 5xx = faute du serveur. On ne cherche pas au même endroit.
• Passer un mot de passe en GET. Il finit dans l’URL, les logs, l’historique. Les données sensibles passent en POST.
• Négliger NTP. Une heure fausse casse Kerberos et les certificats — une panne de couche 7 aux effets démesurés.
• Oublier le DHCP relay entre VLAN. Un broadcast ne franchit pas un routeur : sans ip helper-address, pas d’IP dans le VLAN distant.
• Contourner un avertissement de certificat sans réfléchir. C’est exactement le moment où un homme du milieu vous attend.

Ce que je retiens

1. La couche 7 donne un sens aux octets. Les couches basses transportaient à l’aveugle ; ici, les données deviennent des requêtes, des noms, des baux — des phrases.
2. DNS est l’annuaire, et le suspect n°1. Avant d’accuser le réseau, dig le nom. La moitié des pannes « réseau » sont du DNS.
3. DHCP, c’est DORA : Discover, Offer, Request, Ack. Et le broadcast ne franchit pas un routeur — d’où le relais entre VLAN.
4. HTTP est sans état. Cookies et sessions ne sont que des rustines pour lui donner une mémoire qu’il n’a pas, par conception.
5. HTTPS = HTTP + TLS. Le S est une couche de chiffrement en dessous, pas un protocole à part. Le cadenas protège le transport, pas votre jugement.
6. Les codes HTTP orientent tout : 4xx côté client, 5xx côté serveur. Un chiffre, un diagnostic.
7. La couche 7 est la plus exposée, parce qu’elle interprète les données de l’utilisateur. Injection, XSS, spoofing : une base naïve, des rustines de sécurité par-dessus. Toujours la même histoire.
8. Le diagnostic remonte la pile. Du câble à l’application, cinq tests, et l’endroit où ça casse est la réponse.

Et voilà. Sept couches, du signal électrique dans un fil de cuivre jusqu’à la requête HTTP qui charge cette page. On est parti d’une tension qui varie sur une paire torsadée, et on est arrivé à GET /osi/couche7/ HTTP/1.1. Entre les deux, sept étages, chacun nettoyant le désordre laissé par celui du dessous, chacun ignorant superbement ce que fait le voisin.

C’est ça, le réseau : pas une chose, mais une pile. Et maintenant, vous la connaissez de bas en haut.

Merci d’avoir suivi la série jusqu’au sommet.