TP 1 : Autorités de certification et HTTPS

François Lesueur (francois.lesueur@insa-lyon.fr)

Ce TP présente le modèle des autorités de certification et l’applique au protocole HTTPS. Il sera réalisé dans la VM VirtualBox MI-LXC disponible ici. Comme expliqué dans la vidéo tuto (à regarder avant ou au début de TP !, la vidéo décrit l’installation, la prise en main et le lancement mais attention la fin de la vidéo décrit des machines et interactions liées à un autre TP de 5TC-SRS), avant de lancer la VM, il peut être nécessaire de diminuer la RAM allouée. Par défaut, la VM a 3GO : si vous avez 4GO sur votre machine physique, il vaut mieux diminuer à 2GO, voire 1.5GO pour la VM (la VM devrait fonctionner de manière correcte toujours).

L’infrastructure déployée simule plusieurs postes dont le SI de l’entreprise target (routeur, serveur web, poste admin), le SI de l’autorité de certification mica, un AS d’attaquant ecorp et quelques autres servant à l’intégration de l’ensemble.

Pour les curieux, le code de MI-LXC, qui sert à générer cette VM automatiquement, est disponible avec une procédure d’installation documentée ici

Vous devez vous connecter à la VM en root/root. MI-LXC est déjà installé et l’infrastructure déployée, il faut avec un terminal aller dans le dossier /root/mi-lxc. Pour démarrer l’infrastructure, tapez ./mi-lxc.py start.

Vous pouvez afficher un plan de réseau avec ./mi-lxc.py print.

Pour vous connecter à une machine :

Toutes les machines ont les deux comptes suivants : debian/debian et root/root (login/mot de passe).

L’objectif du TP est de permettre à la machine isp-a-home de naviguer de manière sécurisée sur le site www.target.milxc (hébergé sur la machine target-dmz).

Si la souris reste bloquée dans une fenêtre virtuelle, appuyez sur CTRL+SHIFT pour la libérer.

Dans la VM et sur les machines MI-LXC, vous pouvez installer des logiciels supplémentaires. Par défaut, vous avez mousepad pour éditer des fichiers de manière graphique. La VM peut être affichée en plein écran. Si cela ne fonctionne pas, il faut parfois changer la taille de fenêtre manuellement, en tirant dans l’angle inférieur droit, pour que VirtualBox détecte que le redimensionnement automatique est disponible. Il y a une case adéquate (taille d’écran automatique) dans le menu écran qui doit être cochée. Si rien ne marche, c’est parfois en redémarrant la VM que cela peut se déclencher. Mais il faut la VM en plein écran.

Connexion en clair

Depuis la machine isp-a-home, ouvrez un navigateur pour vous connecter à http://www.target.milxc. Vous accédez à une page Dokuwiki, qui est bien la page attendue.

Nous allons maintenant attaquer depuis l’AS ecorp cette communication en clair, non sécurisée, entre isp-a-home et target-dmz. L’objectif est que le navigateur, lorsqu’il souhaite se connecter à l’URL http://www.target.milxc, arrive en fait sur la machine ecorp-infra. Deux pistes peuvent être explorées :

Nous constatons ainsi le cas d’attaque que nous souhaitons détecter : un utilisateur sur isp-a-home qui, en tapant l’URL www.target.milxc, arrive en fait sur un autre service que celui attendu. Remettez le système en bon ordre de marche pour continuer (pour DNS, remettre la bonne IP 100.80.1.2 ; pour BGP, désactivez l’interface eth1:0 sur ecorp-router ifconfig eth1:0 down).

Création d’une CA

Pour sécuriser les communications vers www.target.milxc, nous allons créer, déployer et utiliser une CA. Cette CA sera hébergée dans l’AS mica et manipulée sur la machine mica-infra (son nom DNS dans l’infra sera www.mica.milxc). Nous utiliserons le protocole ACME (celui de Let’s Encrypt) pour l’opération de la CA (challenges, émission des certificats) via la suite d’outils de Smallstep.

Dans un premier temps, il faut initialiser une nouvelle CA en tant que root (création d’une paire de clés, d’un certificat racine, etc.) (doc) :

# step ca init                  <- le # dénote une commande shell à taper en root

Dans un second temps, il faut activer le protocole ACME pour cette CA (doc, le protocole ACME est responsable des défis/réponse pour la génération automatique des certificats) :

# step ca provisioner add acme --type ACME

Il faut démarrer le serveur de la CA (il doit rester actif pour la suite du TP) :

# step-ca .step/config/ca.json

La commande step-ca est bloquante, soit vous la mettez en arrière plan avec Ctrl+z puis bg, soit vous ouvrez ensuite un autre terminal. Ne la lancez pas avec un &, elle doit en effet demander au lancement le mot de passe de la clé privée, ce qu’elle ne pourrait pas faire lancée avec un &.

Rendez enfin le certificat racine root.crt accessible au téléchargement, en l’extrayant grâce à la commande suivante puis en le copiant (avec les bons droits) vers /var/www/html (il sera ainsi accessible depuis toutes les autres machines par l’URL http://www.mica.milxc/root.crt).

# step ca root root.crt         <- ceci extrait le certificat racine vers le fichier root.crt

Si, après avoir affiché à l’écran un document chiffré (par exemple avec la commande cat), votre terminal affiche de mauvais caractères, utilisez la combinaison de touches Ctrl+v, Ctrl+o pour retrouver un affichage fonctionnel (ou tapez reset).

Pour reprendre la configuration à 0, il faut supprimer le dossier /root/.step sur la machine mica-infra

Intégration de la CA à l’écosystème HTTPS

Pour que la CA soit opérationnelle, il faut qu’elle soit reconnue par les clients HTTPS, ie, les navigateurs web (Firefox ici). Cette reconnaissance, dans le cas d’une CA globale, passe par l’intégration du certificat racine dans le magasin de certificats fourni avec le navigateur, donc par l’éditeur de ce navigateur.

En entreprise, on rencontre souvent une CA locale qui est ajoutée localement au magasin de certificats. Dans ce TP, nous étudions le fonctionnement général de HTTPS global à travers le monde et non un déploiement à l’échelle locale.

Vous devez pour cela :

La nouvelle CA est ainsi devenue une CA par défaut, reconnue globalement. Vérifiez, après avoir redémarré Firefox, que vous la retrouvez bien dans le magasin de certiticats de Firefox.

Certification du serveur target-dmz

Sur l’AS target, vous disposez du serveur target-dmz sur lequel il faut déployer du matériel cryptographique pour faire du HTTPS. Vous devrez notamment :

Connectez-vous maintenant en HTTPS depuis isp-a-home (si vous aviez ajouté une exception de sécurité à un moment du TP, retirez-la avant). Tout doit se dérouler sans alerte, visualisez le certificat reçu. (Vous arrivez sur une page par défaut, le dokuwiki est accessible à l’URL https://www.target.milxc/dokuwiki/)

Attaques sur un serveur HTTPS

Attaque sur la connexion au serveur

Refaites l’attaque du début (DNS ou BGP) et vérifiez que la connexion depuis isp-a-home, lorsqu’elle est routée vers le serveur attaquant, génère bien une alerte de sécurité.

Quelle est d’habitude votre réaction face à ce genre d’alerte ? Que pouvons nous en conclure sur la protection et le risque restant avec HTTPS ?

Attaque lors de la création du certificat

En reprenant les attaques du début, obtenez depuis ecorp-infra un certificat bien signé par MICA lié à l’URL www.target.milxc. Ces attaques DNS/BGP vont vous permettre de vous faire passer pour Target auprès de mica, lors de la phase de création du certificat.

Validez la réussite en vous connectant depuis isp-a-home vers ce faux serveur, maintenant sans alerte de sécurité.

Bonus : Authentification mutuelle

Mettez en place une authentification des clients par le serveur au moyen de certificats clients.

Attention vous ne pourrez pas le faire avec ACME (les certificats clients ne correspondent pas à des noms d’hôtes et ne sont donc pas validables avec ACME). La partie de doc nécessaire est ici

Révocation

Dans Smallstep, la révocation par CRL/OCSP n’est pas (encore) gérée. À la place, les certificats ont par défaut une durée courte (24h) et doivent être renouvelés automatiquement, ce qui limite largement le besoin de révocation explicite. Ce positionnement et toutes les limites de la révocation explicite sont très bien expliqués par les auteurs ici