Comprendre HTTPS et HSTS (1/2)

To the non-french speaker, note that you can translate the articles using the Google Trad widget situated at the bottom of all pages.


Dans le premier article sur l’espionnage sur les réseaux, je vous ai montré que l’on pouvait sniffer les communications entre deux hôtes ou encore que l’on pouvait rediriger les victimes vers des sites factices dans le but de voler leurs identifiants. Pour contrer ces attaques, un protocole à été créé : SSL (qui est devenu TLS un peu plus tard).

Ce protocole permet de créer un tunnel entre deux hôtes dans le but que seuls ces deux hôtes puissent comprendre le contenu de leurs communications. Par conséquent si vous communiquez avec un serveur en utilisant le protocole TLS, et que quelqu’un tente de sniffer le contenu de vos communications alors voici ce qu’il obtiendra :

tlsbrou

Inutilisable donc. En plus de protéger contre le vol de données, SSL/TLS vont empêcher la mise en place d’attaques via spoofing DNS. Ça ne laisse plus beaucoup de possibilités pour de potentiels attaquants… Enfin… Pas vraiment 😉 !

Avant d’utiliser des outils informatiques il va falloir comprendre un sacré paquet de choses. Du coup cet article sera découpé en deux parties? Dans la première on parlera de HTTPS et dans la seconde d’HSTS et de comment attaquer ces deux protocoles. Et pour commencer on va parler cryptologie.

I/La cryptologie

La cryptologie est une science qui permet de cacher des messages à l’aide d’algorithmes mathématiques. Les premières méthodes de cryptologie sont apparues dans l’Antiquité. Le chiffrement de César est l’une d’entre elle. A l’époque César ne voulait pas que ses ennemies puissent lire les messages qu’ils envoyaient dans son empire. Il a donc pensé à chiffrer ses messages. Pour cela il remplaçait chaque lettre de son message par une lettre distante d’une distance n sur la droite ou la gauche.

Par exemple pour une distance de 3 sur la droite, le « a » était codé par un « d ». A l’époque ce code suffisait à duper les gens. Mais avec un peu de réflexion on se rend vite compte qu’il y a une faille majeure. En effet dans la langue française la lettre la plus courante est le « e ». Par conséquent il suffit de chercher dans le message codé la lettre qui est la plus souvent utilisée et à partir de là on obtient la distance et donc on peut déchiffrer le message.

On appelle ce genre d’algorithme des algorithmes symétriques. Car la même clé est utilisée pour chiffrer et déchiffrer le message. En l’occurrence si on choisit une distance de 5 pour chiffrer le message alors on pourra le déchiffrer avec cette même distance.

Avec le temps, de nouveaux algorithmes sont nés : plus complexe, plus rapide et surtout plus sécurisé. Un de ces algorithmes est le RSA (du nom de ses créateurs : Ronald Rivest, Adi Shamir et Leonard Adleman). Cet algorithme est apparu dans les années 70 et est très utilisé notamment dans le domaine du chiffrement web (étonnant que je vous en parle n’est-ce pas ?! 😏 )

Contrairement au chiffrement de César, le RSA est un algorithme asymétrique dans le sens où il a besoin de deux clés pour fonctionner. La première c’est la clé publique, tout le monde peut l’avoir. La seconde est la clé privée, celle-ci est détenue par une seule personne. Alors comment ça fonctionne ?

On va prendre un message M que l’on va chiffrer à l’aide de la clé publique. Puis on va l’envoyer à son destinataire. Le destinataire, qui dispose de la clé privée, va le recevoir et déchiffrer le message pour en lire le contenu :

cryptage

Seul celui qui dispose de la clé privée pourra déchiffrer un message chiffré avec la clé publique. En revanche l’inverse n’est pas vrai.

Avec ces bases en cryptologie il sera plus simple de comprendre le fonctionnement du protocole TLS !

II/ Le protocole TLS

Comme je vous l’ai dit le protocole TLS permet d’établir un tunnel qui chiffre les données entre deux hôtes. Ces données, ça peut être des communications HTTP, des données de type mail etc…

Tout le protocole repose sur ce que l’on appelle des certificats numériques. Ces certificats sont l’équivalent numérique de nos cartes d’identités sauf qu’ici ils permettent d’authentifier un serveur. On retrouve plusieurs informations dans ces certificats : la version (1, 2, 3, 3+), le numéro de série, l’algorithme de signature utilisé, l’émetteur, la date de début/fin de validité, le propriétaire, ainsi qu’un tas d’autres informations dont on reparlera plus tard. Voici une partie du certificat du site wordpress.com :

1

Généralement (et je reviendrai sur ce point plus tard), ces certificats sont délivrés par des autorités de certification qui ne sont, ni plus ni moins, que des entreprise spécialisées dans la vente de certificat numérique.


Voici un schéma récapitulatif du fonctionnement global de SSL/TLS :

4.png

Je sais, c’est pas très explicatif donc on va reprendre tout ça échange par échange.

  • 1 / Client Hello :

Pour initier une connexion TLS, il faut que le client fasse une requête au serveur web. Cette requête porte le nom de requête Hello. Mais contrairement à ce que l’on pourrait croire ce n’est pas juste un « Hello ». Dans cette requête le client va aussi joindre plusieurs informations telles que la version de SSL/TLS qu’il utilise ainsi que les protocoles de partage de clés, de hashage et de compression qu’il peut utiliser (on en reparlera plus tard ne vous inquiétez pas).

Voici un exemple de message de type « Client Hello » :

5

Si vous regardez la partie « Cipher Suites », vous verrez qu’il y a 14 possibilités. « Mais qu’est ce que ça veut dire TLS_ECDHE_RSA_WITH_AES128_CBC_SHA, c’est du charabia tout ça! »

Non du tout ahah ! Il faut juste connaître les conventions de nommage des Cipher Suites. Un CipherSuite c’est un ensemble d’algorithmes qui seront utilisées pour chiffrer des données. Les CipherSuites SSL/TLS respectent toujours ce schéma :

SSL_X_WITH_Y_Z //Pour SSL
ou
TLS_X_WITH_Y_Z //Pour TLS

Pour être plus précis, X est l’algorithme qui sera utilisé pour l’échange de clé, Y est l’algorithme de chiffrement des données et Z est l’algorithme de hashage. Par exemple, si on prend ce CipherSuite :

TLS_ECDHE_RSA_WITH_AES128_CBC_SHA

On peut voir que lors de la mise en place de la connexion sécurisée, l’algorithme d’échange de clé utilisé sera ECDHE_RSA (ECDHE pour l’échange de clé et RSA pour assurer l’authenticité du message), l’algorithme de chiffrement de données sera AES128 et l’algorithme de hashage sera CBC_SHA.

  • 2 / Serveur Hello :

Le serveur, de son côté va aussi dresser une liste des Cipher Suites qu’il peut gérer et parmi ceux qu’il a en commun avec le client, il va en choisir un : le plus sécurisé. Bah ouais une communication chiffrée qui utilise du chiffrement RC4 est extrêmement plus simple à casser que son équivalent en AES256.

Pour simplifier les explications à venir nous allons partir du principe que le CipherSuite utilisé est :

TLS_RSA_WITH_AES128_SHA256

En plus du CipherSuite, le serveur va envoyer sa clé publique ainsi que son certificat et une signature de son certificat. « Mais qu’est-ce qu’une signature de certificat ? » Une signature, c’est un document qui atteste de l’authenticité du certificat émis par le serveur. La première étape pour générer un certificat, c’est de le hasher à l’aide du fonction de hashage (SHA256 par exemple) :

8.png

Ce hash va ensuite être chiffré à l’aide de la clé privé du serveur et concaténer au certificat du serveur :

9.png

Une fois le hash chiffré, on dit que le certificat du serveur est signé et que cette signature prouve que le serveur est bien celui qu’il atteste être. Voici à quoi ressemble une partie de la signature du certificat du site wordpress.com :

7

  • 3 / Client cryptographic verification

A partir de maintenant, le client a en sa possession un Cipher Suite, une clé publique, un certificat et une signature de ce certificat. La première chose qu’il va faire, c’est vérifier le contenu du certificat : est-ce que le nom du domaine spécifié dans le certificat correspond au domaine que je contacte ? Est-ce que le certificat est encore valide ? Est-ce qu’il est complet ?

Si le navigateur a un doute, il rejettera la connexion directement. Si les informations sont correctes alors le  client va passer à la deuxième étape : la vérification de la signature ! Mais comment va-t-il faire puisque la signature est un hash chiffré ? Eh bien rappelez vous, le hash a été signé avec la clé privée du serveur. Or nous disposons de la clé publique ! On peut donc la déchiffrer et récupérer le hash du certificat :

10

Cependant on ne peut pas comparer un hash et un certificat… Par contre, on peut hasher ce même certificat et vérifier que les deux hash obtenus sont biens les mêmes :

11

Si les deux hash sont identiques, c’est que le certificat est authentique donc qu’on s’adresse au bon serveur ! Sinon c’est qu’il y a un problème et votre navigateur vous le fera savoir ! Ce mécanisme de sécurité nous permet tout simplement de nous assurer que le serveur que l’on contacte n’a pas été usurpé.

Si tout est bon, alors le client va générer une suite de 48 bits aléatoires appelés la PMS (Pre Master Key).

  • 4 / Chiffrement et envoi de la clé de chiffrement (MS) :

Cette PMS va être chiffrée à l’aide de la clé publique du serveur puis envoyée au serveur en utilisant l’algorithme d’échange de clés spécifiés dans la paramètre X de notre CipherSuite :

TLS_RSA_WITH_AES128_SHA256

Ici c’est RSA. Mais on aurait très bien pu utiliser autre chose comme Diffie Hellman par exemple !

Le serveur va recevoir la PMS chiffrée et la déchiffrer avec sa clé privée. A partir de maintenant les deux communicants disposent d’une PMS. Cette PMS, ils vont la dériver afin d’obtenir un Master Secret (la clé de chiffrement symétrique qui sera utilisée pour chiffrer les données)

  • 5 et 6 / Finished message :

Avant de commencer à envoyer des données chiffrées, le client et le serveur vont s’envoyer mutuellement un dernier message : le « finished » message qui indique que les deux communicants ont envoyé tous ce qu’ils avaient à envoyer !

  • 7 / Envoi des données :

Maintenant que les deux communicants disposent de la clé symétrique, ils vont pouvoir commencer à chiffrer et envoyer leurs données. Pour chiffrer leurs données ils utiliseront l’algorithme AES128 couplé à l’algorithme SHA256 qui leurs permettront de s’assurer que les données n’ont pas été altéré.


Jusque là on a vu que la clé publique du serveur nous était envoyé par le serveur lui même. Seulement dans la réalité ce genre de pratiques peut être vu comme une tentative de piratage. Quand un serveur signe son propre certificat on dit que le certificat est self-signed.

Et quand un serveur est self signed, ça veut dire qu’aucune autorité de certification n’a certifié que ce certificat est valide. Donc vous ne pouvez théoriquement pas avoir confiance en ce type de certificat. Dès qu’un navigateur croisera un certificat self-signed il vous le fera savoir avec ce genre de messages :

notsafe

Généralement on utilise ce type de certificat pour des réseaux intranet ou bien pour faire des tests sur une machine en particulier. Pour qu’il n’y ait pas ce genre d’erreurs il faut que le certificat soit signé par une autorité de certification.

Alors comment ça marche dans ce cas là ? Eh bien le processus est un peu plus long. En effet avant de déployer son certificat sur un serveur, il va falloir créer une demande de signature de certificat. Cette demande, il va ensuite falloir l’envoyer à une autorité de certification (Symantec, GoDaddy etc…) accompagnée de la clé publique du serveur.

De leurs côtés, les autorités de certification vont vérifier les données de votre certificat et, si tout est bon, ils vont signer le certificat non pas avec la clé privée du serveur qui utilisera le certificat mais avec leur clé privée !

Là où ça devient tricky, c’est que lorsque le client récupérera le certificat d’un serveur, il tentera de le déchiffrer. Et pour cela il aura besoin de la clé publique de l’autorité de certification. Heureusement pour lui, les clés des autorités de certification sont très souvent incorporées directement dans le navigateur. Pas de problème du coup, on va pouvoir déchiffrer la signature ! Si ça fonctionne c’est que le certificat a été approuvé par l’autorité de certifications sinon ça veut dire qu’il y a un problème.

Ensuite le protocole reste le même donc on continue à partir du point 3 (génération du PMS puis chiffrement à l’aide de l’algorithme d’échange de clé etc…)

Voilà pour la partie théorique sur le protocole TLS/SSL. Comme vous l’avez constaté c’est plutôt lourd à comprendre du coup si vous avez des questions n’hésitez pas à m’en faire part dans l’espace commentaire et/ou sur Facebook. Pour que tout soit bien clair, j’ai fait ce gros schéma qui récapitule plus ou  moins tout ce qu’il faut savoir pour bien comprendre TLS/SSL :

finaltlsschema

Avant de pouvoir attaquer HTTPS il va falloir étudier le fonctionnement d’un deuxième protocole : HSTS.

6 commentaires

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l'aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s