Vous êtes sur la page 1sur 10

INTRODUCTION

L’objectif de ce TP est la mise en place d’une transmission sécurisée HTTPs entre le serveur
web Apache et le client navigateur. Les notions sous-jacentes de clés privée/publique/secrète,
certificats et signature sont abordées et l’analyse de trames permet de comprendre le
fonctionnement d’une liaison sécurisée. Le TP est réalisé en équipe de deux avec une session
Windows client et une session Windows Server qui héberge un serveur DNS. Les deux sessions
hébergent un serveur http sous Apache qui servira de base pour mettre en place une liaison
sécurisée HTTPs. Nous ferons des rappels concernant les généralités des protocoles HTTP et
HTTPs et nous répondront aux questions de synthèse proposées par le sujet de TP.
DÉROULÉ DU TP

Pour ce TP nous disposons donc de deux sessions Windows (1 client et 1 serveur) directement
préconfigurées dans le même réseau IP dans le réseau privé 10.0.0.0/16. La première étape a
été d’installer le logiciel Apache afin d’héberger 1 serveur web par poste. Il nous a fallu ensuite
une fois Apache installé modifier le fichier de configuration afin de donner le bon nom à nos
serveurs et de mettre les bons chemins pour accéder à la page web. Voici les modifications
que nous avons fait dans le fichier httpd.conf :

Nous avons donc pu démarrer le serveur et ainsi nous connecter chacun sûr la pages des
autres serveurs à l’aide de l’adresse IP directe des différents postes.
Afin d’avoir un accèes personnalisé, nous avons mis en place sûr une des deux machines un
serveur DNS qui nous à permis de faire de la résolution de noms. Nous avons donc pu changer
de methode pour accéder au site et utilisé un URL avec le nom de domaine correspondant au
serveur que nous voulions joindre. Voici l’affichage du serveur DNS avec les correspondances
Adresse IP / Noms de domaines (Enregistrements A) :

Ici on voit 3 enregistrements DNS car notre groupe est impair, notre binôme est donc devenu
un trinôme.
Les échanges http étaient donc à ce stade bien fonctionnels.
Nous devions maintenant ajouter des notions de sécurité à ces échanges et faire en sorte que
la liaison client-serveur soit sécurisée. Pour ce faire, nous avons utilisé le logiciel openssl qui
fonctionne en ligne de commandes afin de mettre en place des solutions de chiffrement.
Nous avons ensuite fait un aparté pour comprendre comment fonctionnait la génération de
clé et le chiffrement de fichiers dans un environnement Windows. Nous avons également vu
le contenu d’un certificat chiffré via l’algorithme asymétrique RSA qui nous a donné cet
affichage :

On obtient alors quelque chose de complètement illisible pour nous mais qui peut être
déchiffré par une machine grâce à la clé privée associée.
Nous allons ensuite mettre en place un certificat auto-signé afin de sécuriser les liaisons http
grâce à la fonction d’openssl que nous avons ajouté à notre serveur Apache. Voici la comande
qui nous à permis de rentrer dans la configuration d’un certificat auto-signé :

Nous rentrons alors des informations concernant le serveur dans un formulaire sous cette
forme :
Deux nouveaux fichiers sont alors apparus. Ce sont les clés publique et clés privées relatives
au serveur qui permettront de sécuriser les échanges (fichier privkey.pem) et un fichier qui
contient la demande de certificat (fichier www.entreprise.rt.csr).
Nous avons ensuite chiffré la clé privé et stocké dans un fichier appelé www.entreprise.rt.key
grâce à la commande suivante :

Enfin grâce à la commande suivante, nous générons le certificat autosigné grâce au fichier
contenant la clé privée, et le fichier contenant la demande de certificat. A noter que le
certificat est valable 365 jours, soit un an.

Afin de visualiser ce certificat sous windows, on convertit le certificat au format cert


nouvellement généré au format crt que l’on peut ouvrir sous windows. Voici à quoi ressemble
la visualisation de ce certificat :
Nous disposons maintenant de tout ce dont nous avons besoin pour mettre en place un accès
HTTP sécurisé avec l’algorithme de chiffrement RSA. Nous avons donc remodifié les fichiers
de configuration d’Apache afin d’autoriser le protocole https/tls sûr le port 443 :

Voici les variables que nous avons modifié pour y arriver :

Une fois ceci fait, le serveur Apache démarre directement en utilisant le protocole https/tls et
nous permet d’avoir un accès sécurisé avec l’URL https://www.entreprise.rt :
RÉPONSE AUX QUESTIONS DE SYNTHÈSE

1- Quels sont les ports des protocoles HTTP et HTTPs ?

Le protocole http est un protocole qui permet de normaliser le transfert de fichiers comme le
texte, les images, le son ou la vidéo sur le Web. Il est utilisé systématiquement lors de l’usage
d’un navigateur. Le protocole HTTPs reprend exactement les mêmes notions en ajoutant de
la sécurité (authentification, intégrité, chiffrement). Ils ont un usage similaire mais ils utilisent
tous deux des ports différents malgré l’usage du même protocole de transport (TCP): Le port
TCP 80 pour HTTP et TCP443 pour HTTPs.

2- Etablir un diagramme détaillé permettant de comprendre le fonctionnement d’une


interrogation d’une page web via le protocole HTTP et comprenant les
ouvertures/fermetures de connexions et transferts de données/commandes TCP/HTTP.

Nous allons établir un diagramme permettant de mieux voir les échanges qui se font lors d’une
connexion http non sécurisée :
FAIRE DIAGRAMME AVEC PAGES MAC
3- Etablir un diagramme détaillé permettant de comprendre le fonctionnement d’une
interrogation d’une page web via le protocole HTTPs et comprenant les
ouvertures/fermetures de connexions et transferts de données/commandes TCP/HTTP.

Nous allons établir le même diagramme permettant de mieux voir les échanges cette fois ci
qui se font lors d’une connexion https sécurisée :

Faire DIAGRAMME AVEC PAGES MAC

4- En visualisant le certificat numérique sous Windows, identifier les diverses informations


contenues dans le certificat.

Voici une capture d’écran du gestionnaire de ce certificat au format « .cert ». Cela permet un
affichage plus simple afin de mieux comprendre ce que contient un certificat :
On y retrouve des informations concernant la création de ce certificat comme l’émetteur (le
nom le lieu, la date de création etc…) mais aussi et surtout les algorithmes de chiffrement, et
les clés publiques relative à ce serveur Web www.entreprise.rt qui permettent d’établir une
connexion HTTPs sécurisée. On y retrouve aussi la date de validité étant donné qu’un certificat
n’est valable qu’un certain temps.
Comme ce certificat est généré par notre ordinateur et qu’il n’a été vérifié par aucune
autorité, il n’est pas connu des navigateurs et ne passe donc pas inaperçu lors de l’accès au
Site web sécurisé. Voici une capture du message d’avertissement affiché :
Cela ne nous a pas empêché d’accéder au site web de façon sécurisée, on le voit grâce à l’url
et la présence du protocole https dans ce dernier :

5- Illustrer sous forme d’exemples commentés la génération d’un couple de clés


privée/publique et le chiffrement/déchiffrement asymétrique via RSA.

Dans le cours, le but est que deux individus (Bob et Alice) s’échangent des informations et
s’envoient des données confidentielles. Supposons ici que Alice veuille envoyer des données
à Bob. Il rend la clé publique accessible. Alice utilise cette clé publique pour chiffrer les
données et les signer. Bob, lors de la réception des données, utilise sa clé privée pour
déchiffrer les données d’Alice. L’échange se fait tel que le schéma du cours le présente ci-
dessous :

La génération de ces clés se fait par un calcul mathématique a sens unique en fonction de
variables aléatoires, qui permettent le décryptage impossible. Le renouvellement de ces clés
à chaque transfert n’est donc pas nécessaire, elles expirent en cas de compromission d’une
de ces dernières ou via une limite temporelle.

6- Illustrer sous forme d’exemples commentés la génération d’une clé secrète et le


chiffrement/déchiffrement symétrique via DES ou AES.

Contrairement au système RSA, le système de chiffrement AES/DES est symétrique. Le


chiffrement ne se fait donc pas de la même manière, mais avec une clé secrète partagée aux
deux utilisateurs. Si nous reprenons notre exemple, Bob et Alice utilisent la même clé pour
chiffrer et déchiffrer les messages de l’un et de l’autre. Le schéma ci-dessous illustre le
fonctionnement d’un échange entre Bob et Alice :

La clé est générée par celui qui envoie le message, transférée à l’autre utilisateur par un canal
sûr, et déchiffré par l’autre utilisateur. Cette clé est générée par une substitution et une
permutation de n blocs de x bits allant de 128 à 256 bits pour l’AES et une longueur variable
en fonction des besoins de déchiffrement pour le DES.
Bien souvent, on ajoute à cet algorithme des fonctions de hachage et de signature et de
contrôle d’authenticité afin d’augmenter encore le niveau de sécurité. Ces fonctions sont aussi
généralement ajoutées aux algorithmes de chiffrement asymétriques tel que le RSA.

7- Illustrer sous forme d’exemples commentés le calcul d’une signature et sa vérification.

Pour faire une signature d’un message chiffré, on transmet en réalité deux messages :
- Un message chiffré original
- Un message condensé signé
Le premier message est chiffré à l’aide des méthodes vues précédemment. Le second en
revanche est généré de deux manières possibles :
- Symétriquement avec transfert d’un nouveau message et de la signature avec un
algorithme de hachage
- Asymétriquement avec le système de clés publique/clé privée

Pour le chiffrement symétrique, on utilise le système HMAC pour chiffrer le message et


l’empreinte comme le montre le schéma ci-dessous :
On voit bien que pour former l’empreinte, on utilise le message original et la clé secrète
partagée (identique pour Alice et Bob) que l’on envoie en plus du message original.

Pour le chiffrement Asymétrique, on inverse le sens des clés, c’est-à-dire que l’on chiffre le
message toujours à l’aide de la clé publique, sauf que l’on chiffre la signature avec la clé privée.
Naturellement on déchiffre avec la clé privé le message et la clé publique la signature.
Le schéma ci-dessous montre le fonctionnement du chiffrement de cette signature :

Vous aimerez peut-être aussi