Name: Sécurité des applications web Stratégies offensives et défensives
Rating: 5 (2 reviews)

Historique de TLS

TLS (Transport Layer Security) est un protocole de communication fonctionnant au-dessus de la couche TCP/IP, permettant de garantir la confidentialité des échanges, l’intégrité des données et l’authentification des différentes parties (généralement du serveur, et possiblement du client). HTTP faisant transiter les informations en clair, c’est la combinaison de celui-ci et du protocole TLS qui permet la création d’un canal de communication sécurisé, nommé HTTPS (S pour Secure).

À l’origine de TLS se trouvait le protocole SSL (Secure Sockets Layer) qui a été développé par la société Netscape. La première version, SSL 1.0, date de 1994, et n’a jamais été publiée, en raison de problèmes de sécurité. La seconde version de la norme, SSL 2.0, a été publiée en 1995, et a été dépréciée en 2011, tandis que la version SSL 3.0, apparue en 1996, a été dépréciée en 2015, tous deux en raison de problèmes de sécurité.

En 1999, l’IETF (Internet Engineering Task Force) continua le travail de Netscape et publia la norme TLS en version 1.0, ainsi que la version 1.1 en 2006. Ces deux versions ne sont officiellement plus supportées...

Certificat TLS

1. Principe de fonctionnement

Avant de s’attaquer au fonctionnement de TLS, il est important de comprendre la notion de certificat. Un certificat TLS est un objet numérique semblable à une carte d’identité. Il contient des informations concernant le sujet du certificat, ainsi que sa clé publique. La clé privée correspondante, quant à elle, est stockée de façon sécurisée par le sujet. Un certificat contient également une signature, apposée par une autorité de confiance. En plus de cela, le certificat contient des informations sur les algorithmes cryptographiques utilisés ainsi que des informations de validité temporelle.

En simplifiant, cette signature peut être vue comme un tampon de la mairie délivrant une carte d’identité physique. La confiance accordée au tampon de l’autorité de confiance, c’est-à-dire la mairie, permet de s’assurer que la carte d’identité a bien été émise par cette dernière, et n’est donc pas contrefaite. De par ce fonctionnement, peut en découler la nécessité de pouvoir vérifier la légitimité de cette autorité de confiance.

2. Le standard X.509

a. Version 1

Les certificats TLS se basent sur la norme X.509, imposant un certain nombre de champs. La version initiale de la norme a été créée en 1988 et possède les champs suivants (qui sont également disponibles pour les versions ultérieures) :

Nom du champ	Description
Version	Version du certificat, soit ici version 1.
Numéro de série du certificat	Un numéro de série attribué par l’autorité de certification. Le numéro de série doit être unique pour l’autorité de certification en question.
Algorithme de signature	L’algorithme de signature utilisé.
Information de l’autorité de certification	Le DN (Distinguished Name) de l’autorité de certification émettrice.
Validité	Période de temps pendant laquelle le certificat est valide.
Information du détenteur du certificat	Le DN du détenteur du certificat.
Information de la clé publique	La clé publique, ainsi que l’algorithme...

Suites cryptographiques (Cipher suites)

Les suites cryptographiques sont des chaînes de caractères représentant des combinaisons d’algorithmes et de paramètres cryptographiques utilisées lors de l’établissement de la connexion TLS.

Une suite cryptographique se décompose de la façon suivante :

algorithme d’échange de clés ;
algorithme d’authentification ;
algorithme de chiffrement symétrique (accompagné de ses propriétés) ;
algorithme de code d’authentification de message (MAC).

Voici un exemple d’une telle suite cryptographique :

ECDHE est un algorithme d’échange de clés Diffie-Hellman (DH) basé sur les courbes elliptiques (EC) dont il est possible d’utiliser une variante statique ou éphémère (E pour Ephemeral).
RSA est l’algorithme cryptographique asymétrique permettant d’authentifier l’entité (le serveur web).
AES est l’algorithme cryptographique symétrique qui sera utilisé pour chiffrer le flux de données, utilisant une taille de clé de 128 bits et le mode d’opération GCM (Galois/Counter Mode).
SHA256 est l’algorithme de hachage utilisé pour le calcul d’intégrité et l’authenticité des messages (MAC).

Suivant le cas, certaines suites cryptographiques n’indiquent pas tous les éléments. Voici un tel exemple :

L’algorithme d’échange...

Négociation TLS

La négociation TLS s’effectue juste après la poignée de main en trois étapes (Three-way handshake) TCP (Transmission Control Protocol). Commence alors un jeu de requêtes/réponses entre le navigateur, qui initie la demande (lorsque l’utilisateur souhaite accéder à une page web protégée par HTTPS), et le serveur web. Ces échanges vont permettre de mettre en place la connexion sécurisée tout en se mettant d’accord sur les divers paramètres à utiliser. Le contenu de la négociation TLS peut légèrement varier suivant la version de TLS utilisée ainsi que les paramètres cryptographiques utilisés.

1. TLS 1.2

Voici un exemple simplifié d’échanges lorsque l’algorithme RSA est utilisé en tant qu’échange de clés et d’authentification :

Il est possible de suivre et d’observer ces échanges en utilisant un outil d’analyse réseau tel que Wireshark, c’est ce qui est fait tout au long de cette démonstration.

Client Hello : le navigateur démarre la négociation TLS en envoyant un message Client Hello au serveur. Ce message contient la version la plus récente de TLS que le client peut utiliser ainsi que les suites cryptographiques supportées par le client.

Server Hello : le serveur répond au client en spécifiant la version de TLS et la suite cryptographique qui seront utilisées. Soit ici la suite cryptographique TLS_RSA_WITH_AES_128_CBC_SHA .

Certificate : le serveur transmet également son certificat au client afin de prouver son identité.

Server Hello Done : le serveur indique au client qu’il a terminé d’envoyer les informations nécessaires et se met en attente d’une réponse de la part du client.

Client Key Exchange : le client génère une clé...

Tester et sécuriser sa configuration SSL/TLS

Certains outils en ligne, tels que SSL Labs de Qualys (https://www.ssllabs.com/ssltest/analyze.html), permettent de connaître un ensemble d’information concernant la configuration SSL/TLS de la cible. En plus d’une note globale, allant de A à F, il est possible de connaître les versions de TLS supportées par le site web analysé, permettant ainsi d’identifier des versions vulnérables nécessitant d’être désactivées :

Mieux encore, il est possible de connaître la liste des suites cryptographiques disponibles en mettant en évidence celles nécessitant une attention particulière :

L’outil permet également de récupérer des informations concernant le certificat TLS, ainsi que d’autres informations additionnelles. Ce type d’outil peut être utilisé par les clients des entreprises, surtout en B2B, car facile à prendre en main.

Pour tester et sécuriser un ensemble de serveurs d’entreprise, dont certains peuvent être sur des réseaux internes ou difficilement accessibles depuis l’extérieur, ces outils ne sont pas forcément adaptés. Mieux vaut alors opter pour des outils en ligne de commandes, tels que testssl.sh (https://testssl.sh/) ou sslscan (https://github.com/rbsec/sslscan). De plus, avec...

Fonctionnement de TLS