Mais qu’est ce que SSL?
SSL/TLS est un protocole permettant la sécurisation d'échange réseau à un niveau applicatif (par opposition à une sécurisation qui aurait lieu à un niveau réseau comme avec Ipsec [Ipsec] mais on y reviendra)
Massivement utiliser pour le web en permettant la déclinaison de [http] en [https] ou [ftp] en [ftps] (attention à ne pas confondre avec sftp qui est un ftp dans ssh [sftp-ssh]), le protocole propose de compléter le protocole à sécuriser en y ajoutant ses propres échanges.
Sur la base d’un modèle client serveur, son rôle sera triple:
- Authentification : garantir que client et (surtout) serveur sont bien ce qu’ils prétendent être
- Intégrité: garantir que les données échangés entre le client et le serveur non pas été modifiées
- Confidentialité : garantir que les données échangés entre le client et le serveur ne peuvent être lu par quiconque d’autre
Si celle ci est valide (potentiellement via une auto signature du serveur mais nous y reviendrons) alors le client va utiliser la clef publique du certificat pour partager avec le serveur une clé de chiffrement permettant au client serveur de communiquer de façon sécurisée.
À noter que de façon optionnel (si le système l’impose) le serveur peut également demander au client un certificat afin de l’identifier.
Prenons un exemple, considérons un site web exposé via un server apache. Pour y accéder, un client réalise alors une requête http sur le serveur du type
GET http://localhost:80/index.html
Si l’on configure le server apache avec par exemple la conf suivante (non exhaustive):
SSLCertificateFile /etc/apache2/servercert/server.crt SSLCertificateKeyFile /etc/apache2/servercert/server.nopassphrase.key SSLVerifyClient require SSLVerifyDepth 1 SSLCACertificateFile /etc/apache2/cacrt/ca.crt
Alors pour accéder à la ressources index.html, il faudra employer le protocole https:
GET https://localhost:443/index.html
Mais est ce suffisant? non bien sûr, nous avions parlé de certificats! il faut bien entendu fournir des certificats afin de permettre à tout ce petit monde de communiquer entre eux. Pour cela on va les produire nous même avec [OpenSSL].
Mais tout d’abord, nous avons besoin d’une Autorité de Certification…et ca on peut l’obtenir sur internet auprès d’organismes spécialisés, pourtant il va falloir lâcher quelques billet si on veut procéder ainsi donc comme pour les certificats, on va aussi créer la notre avec openssl.
Sachez tout de même que cette démarche de créer notre propre AC n’est pas viable à terme puisque même si elle va nous permettre de créer les certificats serveur et client, le fait que la chaîne de certification ne soit pas complète fait qu’elle aura une valeur très mineure et pourra même être vu comme une faille de sécu.
Certificat de l'AC
Enfin bref du coup, commençons tout d’abord générons une clé privée pour la AC:$ openssl genrsa -out ./$OUTPUT_DIR/ca.key
Ensuite on va créer une signature à partir de cette clef en lui associant une identité:
openssl req -subj '/C=FR/ST=VILLE/L=VILLE/O=TC/CN=tc.org' -new -key ./$OUTPUT_DIR/ca.key -out ./$OUTPUT_DIR/ca.csr
et pour finir on va enfin construire le certificat de la CA:
openssl x509 -req -days 350 -in ./$OUTPUT_DIR/ca.csr -out ./$OUTPUT_DIR/ca.crt -signkey ./$OUTPUT_DIR/ca.key
Certificats du client et du serveur
Maintenant que nous avons un certificat pour la CA, il va nous etre possible de produire les certificats serveur et ensuite client.De la même maniere que pour la CA il va nous falloir une clef privé que nous utiliserons pour creer les signatures:
openssl genrsa -des3 -out ./$OUTPUT_DIR/$CLIENT_NAME.key openssl req -subj '/C=FR/ST=VILLE/L=VILLE/O=TC/CN=$CLIENT_NAME.tc.org' -new -key ./$OUTPUT_DIR/$CLIENT_NAME.key -out ./$OUTPUT_DIR/$CLIENT_NAME.csr openssl genrsa -des3 -out ./$OUTPUT_DIR/server.key openssl req -subj '/C=FR/ST=VILLE/L=VILLE/O=TC/CN=tc.org' -new -key ./$OUTPUT_DIR/server.key -out ./$OUTPUT_DIR/server.csr
Voila nous avons les signatures, il reste plus qu’à générer nos certificats à l’aide de la CA:
openssl x509 -req -in ./$OUTPUT_DIR/$CLIENT_NAME.csr -CA $SSLCA_DIR/ca.crt -CAkey $SSLCA_DIR/ca.key -CAcreateserial -out ./$OUTPUT_DIR/$CLIENT_NAME.crt -days 350 openssl x509 -req -in ./$OUTPUT_DIR/server.csr -CA $SSLCA_DIR/ca.crt -CAkey $SSLCA_DIR/ca.key -CAcreateserial -out ./$OUTPUT_DIR/server.crt -days 350
À noter que certains outils préféreront utiliser les certificats sous la forme d’un package. Pour cela on va donc le transformer une dernière fois en pkcs12:
openssl pkcs12 -export -in ./$OUTPUT_DIR/$CLIENT_NAME.crt -inkey ./$OUTPUT_DIR/$CLIENT_NAME.key -out ./$OUTPUT_DIR/$CLIENT_NAME.p12 -name \"client certificate\" openssl pkcs12 -export -in ./$OUTPUT_DIR/server.crt -inkey ./$OUTPUT_DIR/server.key -out ./$OUTPUT_DIR/server.p12 -name \"server certificate\”
Enfin pour en vérifier le contenu vous pouvez appeler la commande info:
openssl pkcs12 -info -in ./$OUTPUT_DIR/$PKCS12_FILE.p12
Pour ceux qui auront ete un peu attentif, il nous manque un fichier pour la configuration du serveur apache2, le nopassphrase.key… la encore, OpenSSL:
openssl rsa -in ./$OUTPUT_DIR/server.key -out ./$OUTPUT_DIR/server.nopassphrase.key
Et voila, il reste donc à déposer les fichiers la où il convient dans le serveur, et côté client, de d’enregistrer son certificat dans le navigateur preferé! Sans oublier bien sur celui de l’AC!
Voila, j’espere que ce petit article aura aider à mieux comprendre comment fonctionne SSL et TLS, à bientot!
Références:
[tls] https://en.wikipedia.org/wiki/Transport_Layer_Security[rfc5246] https://tools.ietf.org/html/rfc5246
[rfc8446] https://tools.ietf.org/html/rfc8446
[ipsec] https://www.securiteinfo.com/cryptographie/IPSec.shtml
[http] https://tools.ietf.org/html/rfc2616
[https] https://tools.ietf.org/html/rfc2818
[ftp] https://tools.ietf.org/html/rfc959
[ftps] https://tools.ietf.org/html/rfc4217
[sftp-ssh] https://wiki.filezilla-project.org/SFTP_specifications
[OpenSSL] https://www.openssl.org/
Aucun commentaire:
Enregistrer un commentaire