Quand je tape une URL : DNS, ARP, NAT, TLS et HTTP

Questions pour vérifier la compréhension

Transcription de l’animation

1. Le point de départ

Alice tape https://www.exemple.fr. Le navigateur connaît un nom, mais le réseau n’achemine que des adresses IP. Il cherche d’abord si l’adresse est déjà connue : dans son propre cache, dans celui du système, dans le fichier hosts. Rien : il faut interroger le DNS (Domain Name System), l’annuaire d’Internet.

2. ARP : trouver la passerelle

Pour envoyer sa question DNS, puis pour joindre le serveur, le PC doit sortir du réseau local par sa passerelle par défaut : la box, 192.168.1.1. Pour lui envoyer une trame, il lui faut son adresse MAC. Il pose la question à tout le réseau local : c’est une requête ARP, en diffusion. Seule la box est concernée : elle répond directement au PC. Le PC note la correspondance dans sa table ARP. Si elle y figurait déjà, cette étape aurait été sautée.

3. Résolution DNS

Le PC interroge un résolveur DNS, souvent celui du fournisseur d’accès, parfois relayé par la box. Le résolveur commence par un serveur racine. Celui-ci ne connaît pas la réponse, mais sait qui gère les domaines en .fr. Le serveur du domaine de premier niveau .fr renvoie à son tour vers le serveur qui fait autorité pour exemple.fr. Le serveur faisant autorité donne la réponse : www.exemple.fr a l’adresse 203.0.113.80. Le résolveur la transmet au PC et la garde en cache pendant la durée indiquée (TTL) : la prochaine demande sera immédiate.

4. NAT à la sortie de la box

La box a deux adresses : 192.168.1.1 côté maison, 198.51.100.7 côté Internet. Une adresse privée comme 192.168.1.10 ne circule pas sur Internet. En sortie, la box remplace l’adresse et le port source par les siens, et note la correspondance dans sa table NAT. La réponse du serveur revient vers l’adresse publique de la box. Grâce au port noté dans sa table, la box retrouve le PC et réécrit l’adresse de destination.

5. Connexion TCP puis TLS

Le navigateur ouvre une connexion TCP vers 203.0.113.80, port 443 : c’est la poignée de main en trois temps. Puis commence la négociation TLS. ClientHello : le navigateur annonce les versions et les algorithmes qu’il sait utiliser. ServerHello : le serveur choisit, puis envoie son certificat, qui contient sa clé publique et la signature d’une autorité de certification. Le navigateur vérifie le certificat : le nom correspond, il est en cours de validité, et la chaîne de signatures remonte à une autorité de confiance. Les deux côtés calculent une même clé de session, sans jamais la faire circuler sur le réseau. Le canal est chiffré : la suite de l’échange est illisible pour qui intercepterait les paquets.

6. Requête et réponse HTTP

Dans le canal chiffré, le navigateur envoie enfin sa requête HTTP : GET /, avec l’en-tête Host: www.exemple.fr. Le serveur répond 200 OK, avec le code HTML de la page. Le navigateur affiche la page. Le cadenas signale une connexion HTTPS dont le certificat a été validé. Le HTML appelle d’autres ressources (CSS, images, scripts) : autant de nouvelles requêtes, souvent sur la même connexion.

7. Vigilance sécurité

Vigilance : chaque étape repose sur la confiance. Il faut savoir ce qui la protège. Le DNS : DNSSEC permet de vérifier qu’une réponse vient du bon serveur ; DoH et DoT la chiffrent. Le certificat est la preuve d’identité du site. Une alerte de certificat ne s’ignore pas. HSTS : le site demande au navigateur d’utiliser toujours HTTPS, même si l’on tape http://. Sur un réseau partagé, comme un Wi-Fi public, on s’en tient à HTTPS, voire on passe par un VPN.

8. À retenir

En résumé : ARP trouve la passerelle, DNS trouve l’adresse, NAT fait sortir le PC sur Internet, TLS sécurise l’échange. Tout cela se déroule en quelques dizaines de millisecondes, à chaque visite d’un nouveau site.