HTTP & HTTPS

HTTP (protocole de transfert de document hypertext) est le protocole d’échange de données du web.

1. Architecture du web

C’est un modèle client/serveur. Chaque ressource est localisée sur un serveur. Un client récupère la ressource en se connectant au serveur, et en lui soumettant une requête HTTP. Le serveur répond à la requête en renvoyant la ressource au client. Au cours de cet échange, des méta-données sont également échangées.

Comme les ressources sont hypertextes et/ou multimédia, il arrive souvent que plusieurs ressources soient nécessaires pour que le client obtienne le document finalisé. Par exemple, visualiser une page web nécessite de récupérer non seulement son contenu textuel (un fichier HTML), mais aussi les feuilles de style fixant son apparence, les images incluses dans la page web, etc. Une requête doit être soumise pour chaque ressource, et ces requêtes peuvent être soumises au sein d’une même connexion :

Table 1. exemple de connexion HTTP
	client	serveur
début de connexion
demande pour une page web	requête 1 →
récupération de la page web		← réponse 1
demande pour la feuille de style	requête 2 →
récupération de la feuille de style		← réponse 2
demande pour une image	requête 3 →
récupération de l’image		← réponse 3
fin de connexion

La connexion se ferme à la demande du client, ou bien à l’initiative du serveur si le client est trop lent (timeout), incohérent ou si le nombre maximum de requêtes autorisées est dépassé.

HTTP est un protocole texte (le dialogue est une suite de lignes textuelles), sans état (stateless), ce qui signifie que les requêtes sont indépendantes les unes des autres, sans lien entre elles, et ne partagent aucune donnée, aucun historique.

Une requête donne lieu à un transfert de données entre le client et le serveur : par exemple, une ressource transférée du serveur au client, ou bien des données transférées du client au serveur. Une fois le transfert terminé, la connexion est fermée. Donc lorsque l’internaute lit la page sur son navigateur, il est en mode déconnecté (par conséquent, le serveur n’a aucun moyen de savoir si l’internaute va réellement lire la page, ni combien de temps il va passer à lire).

2. URL

L’URL référence une ressource sur le web. Le format général est :

protocole://user:password@machine:port/path#label?param1&param2

Le port par défaut est 80. Exemples :

http://www.myserver.fr (1)
http://www.myserver.fr/Reseau/index.html (2)
http://www.myserver.fr:8080 (3)
http://www.myserver.fr/Reseau/web.htm#cache (4)
http://www.myserver.fr/cgi-bin/prog.cgi?X=supracond (5)
https://anonymous@ftp.myserver.fr (6)

1	un site
2	une page
3	un site sur un port particulier
4	une marque dans une page
5	requête sur une API avec passage de paramètres
6	requête HTTPS, donc trafic chiffré et serveur authentifié

3. Requête HTTP

Une requête se compose :

d’une ligne de commande (requise)
de plusieurs ligne de méta-données (les en-têtes ou header, requis)
d’une ligne vide (requise), marquant le fin du header
de lignes de données (le body, requis, optionnel ou sans objet suivant la commande)

Exemple :

exemple de requête HTTP sans body

GET /index-static.html HTTP/1.1 (1)
Host: www.angers.fr (2)
                    (3)

1	méthode GET + URL + version HTTP (1 seule ligne)
2	en-tête (plusieurs lignes possibles)
3	marque de fin d’en-tête

exemple de requête avec un body

POST /path/script.php HTTP/1.1  (1)
From: frog@jmarshall.com        (2)
Referer: http://math.univ-angers.fr
User-Agent: HTTPTool/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 32
                                (3)
home=Cosby                      (4)
favorite=flies

1	méthode POST + URL + version HTTP (1 seule ligne)
2	début header
3	fin header
4	début body

Les méthodes HTTP sont GET POST HEAD OPTIONS PUT et DELETE.

4. Réponse HTTP

La réponse se compose :

d’une ligne de status
de plusieurs ligne de méta-données (header)
d’une ligne vide
de lignes de données (le body)

Exemple :

exemple de réponse

HTTP/1.1 200         (1)
Date: Sun, 18 Aug 2019 09:07:03 GMT (2)
Server: Apache/2.4.29 (Ubuntu)
X-Cocoon-Version: 2.1.13-dev
Accept-Ranges: bytes
Last-Modified: Sun, 18 Aug 2019 08:00:31 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 63914
Vary: Accept-Encoding
Cache-Control: max-age=1
Expires: Sun, 18 Aug 2019 09:07:03 GMT
Content-Language: fr
                                        (3)
<!DOCTYPE html>                         (4)
<html>
  <head>
    ...
  </head>
  <body>
    ...
  </body>
</html>

1	status
2	début header
3	fin header
4	début body

5. Codes de retour

1xx - information
100	continue
102	processing
2xx - succès
200	OK
3xx - redirection
301	moved permanently
307	temporary redirect
308	permanent redirect
4xx - erreur coté client
403	forbidden
404	not found
5xx - erreur coté serveur
500	internal server error

6. Cookies

Les cookies sont des méta-données déposées par les sites web sur les postes de travail des internautes. Créer à l’origine pour faciliter la navigation (enregistrer les préférences de l’utilisateur, la langue utilisée), ou améliorer le service proposé (en réalisant des statistiques d’utilisation), leur utilisation souvent détournée aujourd’hui pose problème.

6.1. Vie privée

Dans le monde marchand, l’envie est grande de pouvoir pister l’internaute. Or HTTP étant un protocole sans état, où rien n’est conservé entre deux connexions, comment garder un historique ? Associer des méta-données à chaque adresse IP n’est pas très pertinent : si l’ordinateur de l’internaute est un portable, il change souvent d’IP. Sans compter que derrière une IP peut se trouver toute une université😄.

Les coockies permettent d’y arriver : le site dépose des méta-données sur le disque dur du client (généralement à son insu), dans le but de les récupérer et les faire vivre à chaque visite. A la première visite, un cookie contenant un identifiant est déposé, ce qui permet de reconnaître l’internaute lors de ses prochaines visites, et à partir de là, construire un profil de son comportement passé, pour par exemple d’identifier ses centres d’intérêt (les cookies peuvent servir par exemple à mémoriser les publicités sur lesquelles il a cliqué) afin de lui proposer des publicités toujours plus ciblées.

6.2. Fonctionnement

Un cookie est une paire (clé, valeur) déposée subrepticement par le serveur sur le client. Cette information, persistante sur le client, est alors fournie dans l’autre sens (tout aussi subrepticement) par le client à chaque fois qu’il se connecte à ce serveur.

Dans le détail, le serveur dépose le cookie via l’en-tête Set-Cookie dans sa réponse. Le client renvoie le cookie au serveur via l’en-tête Cookie, lors de ses prochaines requêtes.

Cela ne fonctionne que parce que le navigateur est complice.

Etape 1: Le client requête normalement une page sur le serveur :

GET /index-static.html HTTP/1.1
Host: www.angers.fr

Etape 2: Le serveur répond en insérant un cookie dans l’en-tête :

HTTP/1.1 200
Date: Sun, 18 Aug 2019 07:07:03 GMT
Server: Apache/2.4.29 (Ubuntu)
Set-Cookie: ident=AZERTY1234         (1)
Set-Cookie: propriete=client matinal (1)
...
Content-Language: fr

<!DOCTYPE html>
<html>
  <head>
    ...

1	positionnement d’un cockie, le navigateur va stocker cette information sur le disque du client, en l’associant à ce site

Etape 3: Lors des prochaines requêtes du client vers ce même site, le navigateur transmet tous les cookies associés à ce site :

GET /index-static.html HTTP/1.1
Host: www.angers.fr
Cookie: ident=AZERTY1234         (1)
Cookie: propriete=client matinal (1)
...
Content-Language: fr

1	renvoi du cookie au serveur

Etape 4: Grace aux cookies fournis en retour, le site sait donc à qui il a à faire, et peut reconstituer son profil. Le site peut mettre à jour ces cookies, et les renvoyer au client qui les conservera à nouveau jusqu’à la prochaine connexion.

6.3. Cookie tiers

Remarque préalable

Cliquer sur un lien depuis son navigateur peut solliciter d’autres serveurs que celui présent dans l’URL. Par exemple, avec :

http://un_site.fr/une_page.html

...
<img src="http://un_autre_site.fr/une_image.jpg">
...

un clic sur http://un_site.fr/une_page.html va envoyer aussi une requête vers le site un_autre_site.fr.

C’est la même chose pour les cookies.

Un cookie est dit tiers (third-party) s’il est déposé sur un autre site que celui sollicité par l’internaute (par exemple, un opérateur publicitaire, ayant des partenariats avec tout un réseau de sites web). Ce site partenaire a donc accès aux cookies que lui envoient tous ses sites sous contrat, ce qui lui permet de pister l’internaute dans sa navigation de site en site (et en déduire son comportement, ses habitudes, etc.). Ses informations peuvent ensuite être monnayer auprès de ses sites clients (qui eux sont incapables techniquement de les acquérir par eux-mêmes), et au-delà, auprès d’autres opérateurs publicitaires souhaitant étendre leur couverture.

7. Client HTTP

Les navigateurs web sont les clients HTTP classiques. Mais des commandes Unix permettent aussi de soumettre manuellement des requêtes HTTP : wget, curl, etc. Enfin il existe des modules Python (comme requests) pour créer son propre client.

7.1. Le cache des navigateurs web

Un cache est une mémoire tampon destinée à réduire le traffic inutile. C’est une copie locale à durée limitée des ressources acquises.

Par exemple, si une icône apparait 10 fois dans une page web, le navigateur ne va pas faire 10 GET pour récupérer l’image correspondante. De même, si un site utilise un même bandeau sur chacune de ses pages, alors l’image correspondante sera récupérée une seule fois auprès du serveur, et repêchée dans le cache les fois suivantes.

Dans certaines situations, ce mécanisme peut complexifier la compréhension des choses, car pour chaque ressource acquise, on ne sait jamais s’il s’agit de la version originale disponible sur le serveur à l’instant présent, ou d’une version provenant du cache local.

L’utilisation de commandes de type wget ou curl permet de passer outre ce mécanisme.

7.2. wget

wget est un véritable couteau suisse, permettant de récupérer une page, une page et ses composantes (images, css, etc.), un site complet, un ensemble de sites auto-référencés, etc.

envoi d’une requête GET

$ wget http://math.univ-angers.fr

→ création d’un fichier contenant le body de la réponse

récupération d’une page et de tout ce qu’elle inclut

$ wget -p https://math.univ-angers.fr

→ création d’une arborecence de fichiers

sauvegarde des headers

$ wget --save-headers http://math.univ-angers.fr

choix de la destination (fichier ou écran)

$ wget -O - http://math.univ-angers.fr (1)

1	`-O -` provoque l’affichage du body à l’écran (pas de création de fichier)

7.3. Le module `requests`

Le module Python requests dispose de fonctions (get, post, etc.) implémentant chaque méthode HTTP.

exemple

response = requests.get('http://math.univ-angers.fr')

Ces fonctions renvoient un objet réponse composé d’attributs status_code, headers, content-type, encoding et text.

exemple

import requests

r = requests.get('http://math.univ-angers.fr')
print(f"status_code: {r.status_code}, headers: {r.headers}")
print(f"content-type: {r.headers['content-type']}")
print(f"encoding: {r.encoding}")
print(f"text: {r.text}")

8. Proxy

C’est le cas par exemple d’une université souhaitant garder trace des connexions des étudiants. Dans cette architecture, les connexions HTTP sortantes des clients internes passent toutes par un point de centralisation. Les objectifs visés peuvent être :

le contrôles (journalisation des accès)
le filtrage (censure de sites)
les performances (cache)
le respect de l’anonymat de l’extérieur

Exemple de logiciel proxy : apache, squid, nginx.

9. Reverse proxy

C’est le cas par exemple d’une entreprise souhaitant canalisé le flux HTTP entrant depuis l’extérieur. Dans cette architecture, un point d’entrée obligatoire (appelé reverse proxy ou front-end) focalise toutes les requêtes entrantes, qui les redispatche en interne sur des back-ends. Les objectifs visés peuvent être :

le garant des contrôles (sécurisation centralisée)
la flexibilité (organisation interne invisible de l’extérieur)
la performance (répartition de charge)

Exemple de logiciel reverse proxy : apache, squid, varnish

10. Le protocole HTTPS

D’un point de vue sécurité, HTTP a 2 faiblesses :

les données échangées passent en clair sur le réseau, donc peuvent être écoutées, voire modifiées (man in the middle),
rien ne garantit que le serveur qui répond est le bon serveur (phishing).

Le protocole HTTPS pallie à ces 2 défaut en :

chiffrant les échanges
authentifiant le serveur accédé.

Techniquement, HTTPS est l’empilement de 2 protocoles : TLS (protocole de sécurisation) et HTTP.

L’authentification repose sur un certificat, déposé sur le serveur, et vérifié par le client à la connexion. Le certificat est signé par une autorité de confiance. Il a une durée de validité limitée. Il est la preuve que l’autorité a validé, à une date donnée, ce serveur comme étant bien celui qui doit répondre à l’URL en question.

En suppposant qu’il n’y ait pas de brebis galeuse chez les autorités de confiance, il est donc impossible qu’un faux serveur présentant un certificat valide se fasse passer pour un autre.

exemple de vérification de l’authenticité d’un serveur avec requests

response = requests.get('https://math.univ-angers.fr', verify=True)