Créez un certificat autosigné avec OpenSSL
Prérequis
Pour réaliser cet exercice, vous devez disposer d'une machine Linux Ubuntu avec un serveur web
Apache et un accès root.
Installez Apache
Ouvrez le terminal et entrez :
sudo apt-get install apache2
Créez une paire de clés et un certificat autosigné avec OpenSSL :
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout
/etc/ssl/private/[Link] -out /etc/ssl/certs/[Link]
Quelques explications sur la commande :
openssl req -x509. Demande à OpenSSL de créer un certificat de type x509 autosigné ;
nodes. Option pour ne pas chiffrer la clé privée avec un mot de passe, pour qu'Apache
puisse utiliser la clé privée sans intervention utilisateur ;
days 365. Durée de validité du certificat, d'un an ;
newkey rsa:2048. Option pour générer une nouvelle paire de clés pour le certificat, en
utilisant le système RSA avec une clé de 2 048 bits ;
keyout /etc/ssl/private/[Link]. Emplacement où sera stockée la clé privée
générée ;
out /etc/ssl/certs/[Link]. Emplacement où sera stocké le certificat, qui
contient la clé publique générée.
Vous pouvez laisser les informations par défaut demandées par OpenSSL lors de la génération du
certificat en appuyant sur Entrée.
Le certificat autosigné est créé ! Il faut maintenant configurer Apache pour l'utiliser. Entrez la
commande suivante pour ouvrir le fichier de configuration du Virtual Host TLS par défaut d'Apache
:
sudo gedit /etc/apache2/sites-available/[Link]
trouvez les lignes :
SSLCertificateFile /etc/ssl/certs/[Link]
SSLCertificateKeyFile /etc/ssl/private/[Link]
et remplacez-les par le certificat et la clé privé que vous venez de créer :
SSLCertificateFile /etc/ssl/certs/[Link]
SSLCertificateKeyFile /etc/ssl/private/[Link]
Puis enregistrez et fermez le fichier.
Il faut ensuite activer le mod ssl d'Apache avec la commande :
sudo a2enmod ssl
puis activez le Virtual Host TLS d'Apache :
sudo a2ensite default-ssl
Redémarrez Apache :
sudo systemctl restart apache2
Vous pouvez maintenant tester en ouvrant votre navigateur, par exemple Firefox, et en visitant
[Link]
Le navigateur affiche un message d'erreur ?!
C'est normal ! Le navigateur est configuré pour ne pas faire confiance aux certificats autosignés.
Vous pouvez néanmoins ajouter une exception pour ce site en cliquant sur Avancé puisAjouter
une exception puis Confirmer l'exception.
Vous pouvez maintenant visiter [Link] grâce au certificat autosigné.
Utiliser un certificat autosigné (ou expiré) ne diminue pas la force du chiffrement des données
HTTP par rapport à un certificat valide signé par une autorité de certification. En revanche, un
certificat autosigné ne permet pas d'authentifier le serveur web, ce qui signifie qu'un attaquant
exécutant une attaque MITM peut intercepter et remplacer le certificat du serveur par le sien, puis
déchiffrer et modifier toutes les informations échangées entre le client et le serveur, réduisant à
néant la sécurité de TLS.
Un certificat autosigné est généralement utilisé en environnement local de développement, de
test ou de préproduction.
Par ailleurs, le certificat racine d'une autorité de certification racine est autosigné, puisque c'est elle-
même qui est chargée de signer les certificats ! Cependant, ce certificat fait partie des certificats de
confiance des machines clientes, et est donc reconnu comme valide.
Découvrez le protocole HTTPS
L'usage le plus courant de TLS est en association avec HTTP pour former le protocole HTTPS
(HTTP over TLS).
D’abord, un petit rappel sur le protocole HTTP.
Le protocole HTTP est un protocole texte réseau encapsulé dans la suite de protocoles Internet
TCP/IP de la manière suivante : IP(TCP(HTTP)). Le protocole HTTP n'applique aucune sécurité :
les données sont envoyées en clair et sans contrôle d'intégrité. Les données échangées en HTTP
peuvent être lues et modifiées par n'importe qui sur le réseau Internet.
Et c’est donc ce que permet HTTPS, c’est ça ?
Oui ! HTTPS authentifie et chiffre les données HTTP avec TLS. En HTTPS, le protocole TLS se
place entre les protocoles TCP et HTTP comme ceci : IP(TCP(TLS(HTTP))). Ainsi, toutes les
données HTTP sont chiffrées et authentifiées, en particulier l'URL, les en-têtes HTTP, et le corps
des requêtes et réponses HTTP.
Le protocole IP, ou Internet Protocol, est un protocole réseau de routage qui permet de
communiquer entre 2 adresses IP distantes. Le protocole TCP, ou Transmission Control Protocol,
permet d'établir une session de communication. En particulier, il numérote les paquets réseaux dans
l'ordre afin de pouvoir reconstruire une requête découpée en paquets. Le protocole TCP est fiable,
c'est-à-dire qu'il détecte les erreurs de réseau. En revanche, il ne protège pas contre les attaques
malveillantes sur le réseau.
Cependant, les données échangées au niveau des protocoles IP et TCP ne sont pas sécurisées par
TLS, en particulier les adresses IP du client et du serveur. De plus, les requêtes DNS ne sont pas
sécurisées par TLS et peuvent donc fournir des informations sur le nom d'hôte (ou nom de domaine)
du serveur.
Il existe plusieurs versions du protocole TLS. Les versions SSL ne sont plus considérées comme
sécurisées. La version la plus utilisée de TLS actuellement est TLS 1.2. Il existe également une
version plus récente, TLS 1.3, qui n'est pas encore très utilisée. La principale différence entre les
versions est la liste des algorithmes cryptographiques utilisés, appelés suites cryptographiques.
Découvrez l'anatomie du protocole TLS
Une communication TLS est composée de 2 parties :
l'établissement de la liaison(TLS handshake) qui utilise la cryptographie à clé publique
(chiffrement asymétrique et signature de certificat) ;
l'échange de données (TLS record) qui utilise la cryptographie symétrique (chiffrement
symétrique et code MAC).
TLS handshake
Le protocole TLS handshake s'effectue une fois au début de la communication. Il utilise la
cryptographie asymétrique pour échanger une clé de session.
1. Avant la communication, le client fait confiance au certificat d'un CA racine et le serveur
possède un certificat signé par le même CA racine. C'est la PKI HTTPS.
2. Le client démarre la connexion avec une requête "Client Hello" en clair contenant les
versions de TLS et les algorithmes de chiffrement qu'il est capable d'utiliser.
3. Le serveur répond avec une requête "Server Hello" en clair contenant la version de TLS
choisie parmi celles proposées par le client, ainsi que son certificat X509 contenant sa clé
publique et signée par un CA racine.
4. Le client vérifie la signature du certificat avec la clé publique du CA racine. Si le certificat
est expiré ou n'est pas signé par un CA de confiance, le navigateur affiche une erreur. Si le
certificat est validé, le client génère une clé secrète symétrique (appelée clé de session)
avec un GNPA issu de l'entropie.
5. Le client chiffre la clé de session avec la clé publique du serveur et la lui transmet.
6. Le serveur déchiffre la clé de session avec sa propre clé privée.
7. Le client et le serveur partagent maintenant une clé de session symétrique.
TLS record
1. Le client chiffre la requête HTTP avec la clé de session et calcule le code MAC. Il envoie
cette requête chiffrée au serveur.
2. Le serveur déchiffre la requête avec la clé de session et vérifie le code MAC.
3. Il traite la requête HTTP, puis il chiffre la réponse HTTP avec la clé de session et calcule le
code MAC.
4. Il envoie cette réponse chiffrée au client qui la déchiffre à son tour et affiche le site Internet.
Si le client envoie une autre requête HTTP, il répète les opérations.
TEST ENTRE UNE CONTENEUR DOCKER KALI ET MA MACHINE HÔTE
Étape 1 : Installer Docker
Si Docker n'est pas déjà installé sur votre machine hôte Ubuntu, vous pouvez l'installer en suivant
ces étapes :
sudo apt update
sudo apt install [Link]
Il faut vérifier que le service Docker est en cours d'exécution :
sudo systemctl start docker
sudo systemctl enable docker
Étape 2 : Télécharger l'image Docker
Téléchargez l'image brimstone/kali :
sudo docker pull brimstone/kali
Étape 3 : Démarrer un conteneur avec l'image
Démarrez un conteneur basé sur l'image que vous venez de télécharger :
sudo docker run -it --name kali_container brimstone/kali /bin/bash
Cela vous donnera un accès shell à l'intérieur du conteneur Kali.
Étape 4 : Installer OpenSSL dans le conteneur (si nécessaire)
Si OpenSSL n'est pas déjà installé dans le conteneur Kali, vous pouvez l'installer avec les
commandes suivantes :
apt update
apt install openssl
Étape 5 : Configurer OpenSSL pour la connexion
Pour établir une connexion sécurisée avec OpenSSL, vous pouvez créer un serveur SSL dans le
conteneur ou utiliser OpenSSL pour se connecter à un serveur SSL.
Exemple de création d'un serveur SSL
1. Générer un certificat auto-signé :
openssl req -new -x509 -days 365 -keyout [Link] -out [Link]
Suivez les instructions à l'écran pour remplir les informations demandées.
2. Démarrer le serveur SSL :
openssl s_server -key [Link] -cert [Link] -accept 4433
Exemple de connexion à un serveur SSL
Établir une connexion à un serveur SSL (par exemple, un serveur web), utilisez la commande
suivante :
openssl s_client -connect <adresse_ip_hote>:4433
Remplacez <adresse_ip_hote> par l'adresse IP de votre machine hôte
