Pour que notre machine soit accéssible depuis internet, nous allons crééer un petit LAN, contenant un pfsense et notre machine linuxmint.
Avant d’installer notre machine, il faut créer un pfsense.
Voir installation pfsense
Voir installation linux mint
Entrer la commande :
sudo apt update
.png)
sudo apt install nginx (1).
Entrer ‘O’ pour ‘oui’ (2).
.png)
systemctl status nginx
Nous pouvons voir que en s’installant nginx a lancé un serveur et que celui ci est fonctionnel.
.png)
Nous allons à présent modifier les règles de notre pare feu afin de rendre notre site nginx accessible depuis le wan.
Rendez-vous dans l’interface web de notre pfsense.
.png)
Cliquer sur le menu déroulant (1).
Dérouler l’onglet “Firewall” (2).
Cliquer sur “Rules” (3).
.png)
Nous commencons déja par supprimer des régles déja existantes qui interdisent l’accés par adresse privée. Notre réseau simule des IP publics avec des IPs privée nous allons donc désactiver ces règles.
Cliquer sur le premier petit enrouage (1).
Appliquer les deux prochains screen shots, puis refaite l’action avec le deuxieme (2).
.png)
Décocher “Enable interface”.
.png)
Cliquer sur “Save”.
.png)
Ajouter une nouvelle règle.
Dans Destination, sélectionner “Single host or alias” (1).
Selectionner l’adresse ip de notre serveur (2).
Sélectionner HTTP pour “from” (3) et “to” (4).
Nous ajouterons une règle pour le https en temps voulu.
.png)
Ajouter une description dans un soucis de clareté des règles (1).
Cliquer sur “Save” (2).
.png)
Notre site est désormais accessible en HTTP depuis notre machine physique connecté au VPN.
.png)
Dans le powershell de DC01 créer une clé privée.
openssl gensra -out .\miniCA\private\server.key 2048
.png)
Générer le csr correspondant à la clé pour le serveur nginx
openssl req -new -key .\miniCA\private\server.key -out .\miniCA\csr\server.csr -sha512
.png)
Générer le certificat pour le seveur nginx
openssl ca -config .\miniCA\ca-ssl.cfg -out .\miniCA\cert\server.crt -in .\miniCA\csr\server.csr
.png)
Importer le .crt et le .key créé précedemment sur le CA.
Ici nous les mettons dans un dossier serveur_cert par soucis de clarté.

Installer vim ou un autre editeur de texte.
.png)
Ouvrir le fichier /etc/nginx/site-available/default.

Décommenter les 2 lignes suivantes pour activer TLS via les certificats coté server.

Ajouter les lignes suivantes à la fin de la configuration afin de préciser à NGINX ou ce trouves le .cert et le .key du server.

Aprés redémarrage du service nginx via la commande :
systemctl restart nginx
Nous pouvons voir que notre site est accéssible en HTTPS grâce au petit cadenas qui apparait.

Dans le powershell de DC01, lier la clé et le certificat d’un utilisateur du domaine
openssl pkcs12 -export -out sbombal.pfx -inkey .\miniCA\private\sbombal.key -in .\miniCA\cert\sbombal.crt
Rentrer deux fois le mot de passe de votre choix qui respecte les bonnes pratiques

On importe alors le .cert et le .pfx créés précedemment, sur le server nginx.
Nous les mettons ici dans un dossier client_cert par soucis de clarté.

Ajouter les deux dernieres lignes pour préciser à nginx le chemin vers le certificat client avec lequel il devra comparer ceux fournis par les clients.
ssl_verify_client indique à nginx que le certificat client est nécessaire.

Aprés redemarrage du service nginx l’authentification mutuelle est activée.
Question 1 : l’interception TLS est-elle possible ?
Dans le cas d’une authentification mutuelle, le client ainsi que le server doivent s’authentifier à l’autre via des certificats. Le certificat de l’entité A est signé par la clé privée du CA, et permet donc à l’entité B de vérifier l’identité de A. Pour pouvoir intercepter les paquets HTTPS il faut donc pour une entité tierce posséder à la fois le certificat client et le certificat server pour pouvoir intercepter les paquets, les déchiffrer, les traiter, les rechiffrer et tout ça de manière fluide et discrète.
Question 2 : quelles sont vos propositions pour y remédier ?
La question revient donc à se demander, comment pouvons nous nous procurer les certificats d’une autre entité afin de se faire passer pour elle. Il est possible, pour un attaquant s’il a déjà accès à une des deux machines de récupérer à la fois le certificat client et le certificat server. Ces deux certificats étant centralisés, il n’est donc fondamentalement pas plus compliqué de mettre la main sur les deux certificats que sur un seul. L’authentification mutuelle n’est donc pas plus sécurisée mais s’utilise à des fins différentes. Par exemple si un server n’est pas publique et que son contenu ne s’adresse pas à tout le monde, comme le wiki de M. Bombal.