Sécuriser un serveur web avec https ========================= L'objectif de ce TP est de développer une sécurité concernant l'authentification d'un serveur HTTP (le navigateur client doit être certain de se connecter au "bon" serveur et les données qui transitent doivent être chiffrées). Ce TP s'appuie pour grande partie sur les supports diffusés sous licence GNU http://www.linux-france.org/prj/edu/archinet/systeme/ch24.html HTTP vs HTTPS --------------- Le protocole que l'on utilise pour échanger des données (e.g. des pages web) avec un serveur web est le *protocole HTTP*. Avec HTTP, la *confidentialité n'est pas assurée*. Les informations circulent "en clair" sur le réseau. Il est tout à fait possible pour un pirate d'intercepter vos requêtes (contenant par exemple votre code de carte bleue) et les réponses faites par le serveur, avec un analyseur de paquets comme _wireshark_. De plus HTTP ne met en œuvre *aucun mécanisme d'authentification des parties*. Il n'est donc pas certain que vous communiquiez avec le site que vous croyez consulter. Si l'on souhaite sécuriser l'échange de données *entre un client (un navigateur web) et un serveur*, il faut passer du protocole d'échange de données HTTP à *HTTPS (HTTP over SSL)*. Le protocole HTTPS permet de remédier à ces deux inconvénients : - les échanges sont rendus confidentiels par chiffrement (requête au serveur et réponse du serveur deviennent illisibles pour le pirate) ; - l'authentification du serveur est mis en oeuvre : on est assuré que le serveur auquel on accède est bien celui que l'on croit être. HTTPS offre d'autres possibilités qui ne sont pas abordées ici (par exemple, authentifier la personne qui accède au serveur). HTTPS assure la sécurisation des échanges à l'aide du protocole *Transport Secure Layer (TLS)*. *"Secure Socket Layer" (SSL)* est le nom de son prédécesseur (voir l'historique sur la page wikipedia). Pour sécuriser un serveur web, nous devons doter le serveur web * d'un *certificat* (pièce d'identité du serveur qui contient notamment sa clé publique) * d'une *clé privée correspondante* Une contrainte forte est la nécessité d'*authentifier* (c'est-à-dire *signer*) le certificat. Cette "validation" requiert que l’on génère une demande de signature de certificat, _Certificate Signing Request_ (CSR) en anglais, laquelle sera validée ensuite via (deux options) : * une *Autorité de Certification*. C'est le fond de commerce de certaines compagnies ([www.verisign.com](www.verisign.com)) bien qu'heureusement pour la liberté de l'Internet il existe des solutions gratuites ([www.cacert.org](www.cacert.org), [letsencrypt.org](letsencrypt.org)). Les navigateurs (clients web) sont préconfigurés avec une liste d'autorités de certification de confiance. * vous-même en *auto-signant votre certificat après avoir créé votre propre autorité de certification*. Bien que risqué dans l'environnement de l'Internet, ceci peut s'avérer utile dans un Intranet, où votre organisme peut vérifier facilement les identités des individus et des serveurs (cf. [apache_ssl_intro http://httpd.apache.org/docs/2.4/ssl/ssl_intro.html](http://httpd.apache.org/docs/2.4/ssl/ssl_intro.html)). C'est cette dernière option que nous allons expérimenter ici. Le serveur web écoutera toujours sur le port 80 pour accueillir les requêtes HTTP, mais désormais il écoutera aussi sur le port 443 pour accueillir les requêtes HTTPS (bien sûr tout cela est configurable). Pour simplifier le problème, j'ai parlé jusqu'à présent de sécurisation de "serveur web", il s'agira en pratique de *sécuriser un hôte virtuel* (responsable d'un nom de domaine) pris en charge par le serveur web... Votre travail ----------------------- En distanciel, sous windows/linux - générer un certificat auto-signé SSL/TLS - configurer un serveur web en HTTPS En présentiel, vous travaillerez en binôme et chacun fera à la fois - la configuration du serveur pour permettre à l'autre de jouer le rôle du client - et la configuration du client pour tester le serveur de l'autre. Produire un diagramme de séquence décrivant les différentes opérations réalisées pour mettre en place https et permettre à un client web de se connecter à un serveur https. Ce qui est important c'est 1) d'identifier les différentes entités, 2) de lister ce qu'elles font et 3) de respecter l'ordre des opérations.