R410B - TP 3

TLS et GnuPG

1 Introduction

Au cours de ce TP vous allez mettre en place une connexion TLS pour sur un serveur HTTP (HTTPS) et manipuler GnuPG pour chiffrer et signer des messages (en l'occurence un fichier) pour observer les effets de l'utilisation de la cryptographie.

Lors de ce TP vous allez travailler avec deux machines virtuelles préparées spécialement pour l'occasion.

2 Préparation de l'environnement de travail

Sur votre machine physique créez les machines virtuelles suivantes en utilisant les modèles de disque spécifiés (via l'option -d de la commande vmiut) :

r410b-tp3-serveur via le modèle /home/public/r410b/tp3/r410b-tp3-serveur.vdi ;
r410b-tp3-client via le modèle /home/public/r410b/tp3/r410b-tp3-client.vdi.

Copiez correctement (faites notamment attention au droit du fichier de la clé privé) dans votre dossier $HOME/.ssh la paire de clé SSH contenu dans les fichiers :

clé privée : /home/public/r410b/tp3/id-tp3
clé publique : /home/public/r410b/tp3/id-tp3.pub

Configurez correctement ssh de façon à ce qu'il utilise cette paire de clé (regardez le sens de IdentityFile dans ssh_config(1)) et que :

ssh serveur vous connecte directement sur le serveur en tant que root ;
ssh client vous connecte directement en tant que user.

Assurez-vous que les modèles ont bien été utilisés en vérifiant que :

le serveur ait l'adresse IP 192.168.194.30 ;
le client ait l'adresse IP 192.168.194.31 ;
que depuis les 2 machines les noms monserveur.fr et monclient.fr soit bien résolus avec les adresses IP adéquates.

3 Mise en place de TLS sur HTTP

TLS (Transport Layer Security) est un protocole permettant de faciliter la communication de données de manière sécurisée. Il permet notamment de chiffrer des transmissions en utilisant une infrastructure de gestion des clés (Public Key Infrastructure) avec délégation de la confiance à une autorité de certification.

C'est un protocole très utilisé notamment sur le web où HTTPS implémente simplement une connexion HTTP au dessus de TLS. Techniquement TLS permet notamment à 2 services de s'entendre sur la nature de la cryptographie à utiliser pour leur transmission à partir d'une poignée de main qui initialise la communication (handshake). Vous pouvez étudiez les étapes de l'établissement d'une telle connexion par exemple sur : https://tls13.xargs.org/.

TLS se base sur l'utilisation de certificat. Pour mémoire un certificat est un fichier contenant une clé publique, des informations d'identification et une signature. Il sert à identifier un service et à chiffrer la communication avec lui.

Dans ce genre de PKI on délègue la gestion de la vérification de l'identification à une autorité de certification. Cette autorité est en charge de délivrer des certificats aux entités ou services qui en ont besoin.

Ils existent de nombreuses autorités de certifications et chacune choisit ses procédures, conditions de vérification de l'identité du demandeur, méthode de délivrance, délégation et le coût attaché à la certification. Let's Encrypt offre gratuitement des certificats à qui en veut en se basant sur l'utilisation d'un protocle spécifique (ACME).

Les outils utilisant TLS pour sécuriser leur communication ont besoin de connaître et surtout de faire confiance aux autorités de certification qui délivrent les certificats. Pour cela ils embarquent souvent les certificats des autorités en qui ils ont confiance. C'est notamment le cas de Firefox dont la liste des autorités embarqués par défaut est à la fois disponible en ligne et dans le navigateur (cf about:preferences, onglet Vie privée et sécurité, rubrique Certificats).

Cette année dans le cadre du TP nous ne pourrons ni utiliser une autorité reconnue par défaut par Firefox ni utilisé une autorité délivrant des certificats gratuitement.

Vous allez donc simuler une autorité de certification en générant un certificat que nous allons signé nous même et ajouter aux autorités de confiance. Vous allez faire ça grâce à mkcert.

Connexion sans TLS

Serveur web en HTTP

Assurez-vous que vous avez bien un serveur web nginx qui est en service sur votre serveur et qu'il sert en HTTP les fichiers contenus dans /var/www/html. Pour cela il vous faudra sans doute :

créer un fichier =/etc/nginx/conf.d/default.conf contenant au moins :

server {
   listen 80;
   server_name monserveur.fr;
   root /var/www/html;
}

vérifier la configuration (nginx -t) ;
redémarrer nginx.

Ajoutez un fichier /var/www/html/login contenant uniquement votre login de salle de TP.

Observation des paquets web circulant sur le serveur

Depuis un terminal de votre machine physique observer les paquets web circulant sur le serveur avec la commande suivante :

ssh serveur 'tcpdump -ni enp0s3 -U -w -' | wireshark -i - -k -Y 'tcp.port == 80 || tcp.port == 443'

Depuis le client naviguer avec Firefox pour atteindre l'URL http://monserveur.fr/login.

Qu'observe-t-on dans les paquets capturés ?

Connexion avec TLS

Installation d'un autorité de certification

Sur votre serveur :

installer mkcert en suivant les instructions de https://mkcert.dev ;
créer une autorité de certification locale ;
identifier le fichier contenant le certificat de l'autorité de certification.

Création d'un certificat pour le serveur web

Sur votre serveur :

créer un certificat et une clé pour la machine serveur grâce à mkcert ;
déplacer ces fichiers dans le dossier /etc/tls ;
configurer nginx pour qu'il serve les fichiers de /var/www/html en HTTPS.

Il devrait vous suffir d'ajouter quelque chose ressemblant à ça dans sa configuration (avec XXXX et YYYY remplacé par les chemins adéquats) :
```
server {
    listen *:443 ssl;
    root /var/www/html;
    server_name monserveur.fr;
    ssl_certificate XXXX;
    ssl_certificate_key YYYY;
 }
```
redémarrer nginx après avoir vérifié sa configuration.

Connexion et observation des paquets

Depuis le client naviguer avec Firefox pour atteindre l'URL https://monserveur.fr/login.

Que se passe-t-il ? Pourquoi ?

Corriger le problème en modifiant la configuration de Firefox pour qu'il fasse confiance à notre autorité de certification.

Observer à nouveau les paquets web circulant sur le serveur.

Quelle est la différence avec l'observation précédente.

4 GnuPG

GnuPG est une suite de logiciels implémentant la RFC-4880 (i.e. OpenPGP). Elle permet notamment de chiffrer et signer les messages (fichiers). La confiance en les clés utilisés n'est pas délégué à une autorité de confiance mais à des proches entités que l'on connait et que l'on a identifié soit même ou via un réseau de confiance.

Vous allez ici utiliser GPG pour créer des clés, chiffrer des messages, signer des messages et signer des clés.

Avant de commencer lisez les chapitres 3, 4 et 5 du GPG Mini HOWTO.

Pour toutes vos opérations vous utiliserez l'option -a qui permet d'obtenir des caractères codés sur 7 bits.

Création d'une paire de clés

En utilisant l'option --gen-key construisez-vous une paire de clé publique/privée.

Copiez votre clé publique dans /home/public/r410b/tp3/cles-publiques avec comme nom de base votre login.

Chiffrement de fichier

Pour cet exercice vous allez devoir choisir un binôme (votre voisin ou un ou une autre étudiant du groupe).

Créez un fichier /home/public/r410b/tp3/fichiers/BINOME-clair avec BINOME remplacé par le login de votre binôme et comme contenu votre login.
Chiffrez ce fichier avec la clé publique de votre binôme.

Déchiffrement de fichier

Récupérez le fichier que votre binôme a préparé pour vous et déchiffrez le. Vérifiez que le contenu est celui attendu (le login de votre binôme).

Signature

Signez le fichier /home/public/r410b/tp3/fichiers/BINOME-clair avec BINOME remplacé par le login de votre binôme et stockez la signature dans le fichier /home/public/r410b/tp3/signatures/BINOME-clair.asc

Vérifiez la signature du fichier /home/public/r410b/tp3/fichiers/LOGIN-clair stocké dans /home/public/r410b/tp3/signatures/LOGIN-clair.asc.

Signez la clé publique de votre binôme puis refaites la vérification précédente.

Quelle différence est apparue ?

Quel est le problème que la signature des clés fait apparaître ?