Les protocoles HTTP/HTTPS et les ports

Une adresse IP désigne une machine, mais une machine héberge souvent plusieurs services : un site web, un serveur de messagerie, un accès à distance. Comment savoir à quelle « porte » frapper ? C'est le rôle des ports. Et pour discuter avec un serveur web, on parle un langage commun : HTTP. Cette leçon rassemble ces deux notions, indispensables à tout futur testeur de sécurité.

Dans les leçons précédentes, nous avons vu comment un paquet atteint la bonne machine (IP) et comment un nom devient une adresse (DNS). Il reste à acheminer les données jusqu'au bon programme sur cette machine.

Les ports : les numéros d'appartement

Si l'adresse IP est l'adresse d'un immeuble, le port est le numéro de l'appartement. C'est un nombre de 0 à 65 535 qui identifie un service précis. Un port est toujours associé à un protocole de transport : le port TCP 80 et le port UDP 80 sont deux choses différentes.

Quelques ports courants à connaître par cœur, car vous les croiserez sans cesse :

Les ports de 0 à 1023 sont dits « bien connus » ; les ports élevés servent le plus souvent côté client. Quand votre navigateur contacte un site, il utilise un port source éphémère choisi au hasard (par exemple 51 724) et vise le port 443 du serveur. La paire « adresse + port » de chaque côté, avec le protocole, identifie une conversation unique.

Un port peut être ouvert (un programme écoute et répond), fermé (la machine répond qu'il n'y a rien) ou filtré (un pare-feu ne répond pas). Cette distinction sera essentielle quand vous découvrirez les scans de ports dans un autre cours, toujours dans un cadre autorisé.

La poignée de main TCP

Avant d'échanger des données, TCP établit la connexion en trois temps, la célèbre poignée de main à trois temps :

1. Le client envoie un message SYN : « Je voudrais ouvrir une connexion. »
2. Le serveur répond SYN-ACK : « D'accord, je suis prêt. »
3. Le client confirme par ACK : « Parfait, commençons. »

Vous retrouverez ces trois paquets dans une capture Wireshark, au prochain chapitre. Retenez-les : ils permettent de comprendre ce qu'un outil de découverte réseau observe quand il constate qu'un port est ouvert.

HTTP : un dialogue en deux temps

HTTP (HyperText Transfer Protocol) fonctionne sur le principe « requête → réponse ». Le client (votre navigateur) envoie une requête ; le serveur renvoie une réponse. Rien de plus. Voici une requête minimale, avec un nom de domaine d'exemple :

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: curl/8
Accept: text/html

Elle se lit ainsi : une méthode (GET), un chemin (/index.html), une version, puis des en-têtes qui apportent du contexte (Host précise le site visé, car un même serveur peut en héberger plusieurs). La réponse ressemble à ceci :

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1256
Set-Cookie: session=abc123; HttpOnly; Secure

<html> ... </html>

On y trouve un code de statut (200), des en-têtes et le corps de la réponse (ici, la page).

Méthodes et codes à connaître

• GET : lire une ressource ; POST : envoyer des données (un formulaire) ; PUT et DELETE : modifier ou supprimer ; HEAD : obtenir seulement les en-têtes.
• 2xx : succès (200 OK). 3xx : redirection (301, 302). 4xx : erreur du client (400, 401 non authentifié, 403 interdit, 404 introuvable). 5xx : erreur du serveur (500, 503).

Ces codes sont une mine d'informations : un 403 indique que la ressource existe mais que vous n'y avez pas droit, un 404 qu'elle n'existe pas. Un testeur de sécurité apprend à les lire avec attention. Pour approfondir le protocole, la documentation de référence de Mozilla (developer.mozilla.org) est excellente.

Anatomie d'une URL

Une adresse web se décompose elle aussi en morceaux, qu'il faut savoir lire (notamment pour repérer les liens frauduleux) :

https://www.example.com:443/boutique/panier?produit=42&qte=2#resume

• https : le schéma, c'est-à-dire le protocole utilisé ;
• www.example.com : l'hôte, résolu par le DNS ;
• 443 : le port, qu'on omet quand c'est la valeur par défaut du protocole ;
• /boutique/panier : le chemin de la ressource demandée ;
• ?produit=42&qte=2 : les paramètres de la requête, que le serveur lit et utilise ;
• #resume : un fragment, traité uniquement par le navigateur et jamais envoyé au serveur.

Les paramètres sont l'un des points d'entrée favoris des attaques web : tout ce que l'utilisateur peut modifier est une donnée non fiable que le serveur doit vérifier. Gardez cette idée en tête pour le cours de pentest web.

HTTPS : HTTP dans un tunnel chiffré

En HTTP simple, tout circule en clair : toute personne située sur le trajet peut lire les mots de passe et le contenu des pages. HTTPS n'est pas un autre langage : c'est HTTP enveloppé dans une couche de chiffrement, TLS. Ce chiffrement apporte trois garanties : la confidentialité (personne ne lit les échanges), l'intégrité (personne ne les modifie en route) et l'authenticité (vous parlez bien au vrai serveur, grâce au certificat). Nous détaillerons tout cela au chapitre 6.

Deux nuances importantes. D'abord, HTTPS protège le transport : il ne dit rien de la sécurité du site lui-même, et un site frauduleux peut parfaitement posséder un cadenas. Ensuite, HTTPS cache le contenu, mais pas le fait que vous contactez tel serveur à tel moment.

Cookies et sessions

HTTP est « sans mémoire » : chaque requête est indépendante. Pour vous reconnaître d'une page à l'autre, le serveur vous remet un cookie (par l'en-tête Set-Cookie) que votre navigateur renvoie ensuite à chaque requête. Les attributs Secure (envoi uniquement en HTTPS) et HttpOnly (inaccessible au code JavaScript) rendent ce cookie plus difficile à voler. Ce sujet sera approfondi dans le cours de pentest web.

À vous de jouer

Voici un exercice 100 % local, sans toucher au réseau d'autrui. Vous allez créer votre propre serveur web minimal et l'interroger. Il vous faut Python 3, présent sur la plupart des systèmes (ou le laboratoire que vous monterez plus tard).

# Terminal 1 : lancer un mini serveur web local sur le port 8000
mkdir site-test && cd site-test
echo "Bonjour depuis mon labo" > index.html
python3 -m http.server 8000

# Terminal 2 : l'interroger
curl -i http://127.0.0.1:8000/index.html
curl -I http://127.0.0.1:8000/inexistant.html

Dans votre carnet, notez : le code de statut de chaque réponse, les en-têtes reçus (notamment Server et Content-Type) et ce qui change quand le fichier n'existe pas. Dans le premier terminal, observez la ligne de journal qui s'affiche pour chaque requête. Puis arrêtez le serveur avec Ctrl+C.

Nous savons désormais parler à un serveur. Mais entre vous et lui, un long chemin traverse des équipements variés. Dernière leçon du chapitre : comment les paquets sont-ils aiguillés, et par quoi ?