.st0{fill:#FFFFFF;}

Réseau

Comment protéger ses échanges sur Internet ?

 avril 5, 2020

By  Thierry DAUGER

Dans quasi tous mes articles, je rappelle qu’il est important d’utiliser HTTPS pour se connecter à un site web. Ceci est en effet essentiel afin de garantir la sécurité des échanges sur Internet et ainsi se protéger de personnes malveillantes. HTTPS, c’est bien, mais comment ça fonctionne ? Et surtout, c’est quoi ce « S » à la fin ?

De la navigation de plaisance au commerce Internet

Pourquoi sécuriser ses échanges ?

Les échanges sur Internet devenant de plus en plus nombreux et surtout de plus en plus commerciaux, il fallait trouver un moyen de les sécuriser. En effet, lorsque l’on réalise un achat sur le net, on aime bien s’assurer de :

  • L’authentification du serveur sur lequel on est connecté, afin d’être sûr que l’on achète sur le vrai site du commerçant.
  • La confidentialité des échanges, afin que personne entre nous et le serveur ne puisse voler notre numéro de carte bleue.
  • L’intégrité des échanges, afin que personne ne puisse changer ma commande de 2 paquets de mouchoir en un container entier de cotons tiges…

Le pionner Netscape

C’est pourquoi en 1994, la société Netscape[1], pionnière du Web, a inventé un protocole de sécurisation des échanges, le SSL, pour Secure Sockets Layer. Sa première version, SSLv1, resta purement théorique mais permis en 1995 la sortie de SSLv2 puis de SSLv3 en 1996.

Afin de normaliser tout cela, l’IETF a créé TLS (Transport Layer Security) en 1999. La première version de TLS était quasi identique à SSL v3. La dernière version en date de TLS est TLS 1.3[2].

Savoir conserver un secret

Depuis longtemps, pour pouvoir échanger en secret, on utilise différents moyens de chiffrement. Les moyens de cryptographie utilisés peuvent être symétrique ou asymétrique.

De Jules César à Internet

Le chiffre de César[3] est l’une des méthodes de chiffrement symétrique des plus connus. Elle était utilisée par Jules César dans ses correspondances secrètes. Le texte chiffré s’obtient en remplaçant chaque lettre par une lettre se trouvant à distance fixe, la clé. La transmission de cette clé permet alors de déchiffrer le message, en appliquant le décalage dans l’autre sens. Par exemple, le message « LQIRUPDWLTXH VDQV FRPSOHAH », sachant que la clé est 3, correspond à « INFORMATIQUE SANS COMPLEXE ». L’algorithme AES, encore l’un des plus utilisé à ce jour, est un algorithme symétrique. Leur plus gros avantage est leur rapidité d’exécution, ne pénalisant ainsi pas la vitesse des échanges. Leur inconvénient est qu’il faut envoyer la clé de chiffrement à son interlocuteur.

Chiffrement par décalage
Chiffrement par décalage

Retirons alors la symétrie

C’est pourquoi sont apparus les algorithmes asymétriques. On parle souvent aussi d’algorithme à clé publique et clé privée. Les plus connus sont le RSA[4] et le Diffie-Hellman[5]. Avec un algorithme symétrique, 2 clés sont générées : L’une, publique, est fournie au client. L’autre, privée, est soigneusement et secrètement conservée. Tout repose alors sur le fait que tous les messages qui sont chiffrées avec la clé publique ne seront déchiffrables qu’avec la clé privée.

Chiffrement à clé publique et clé privée

Ces algorithmes ont l’avantage d’être plus sécurisé que les algorithmes symétriques. Ils ont cependant l’inconvénient d’être beaucoup plus lents et consommateurs de ressources. Ils sont alors en général utilisés pour échanger la clé d’un algorithme symétrique.

J’entends déjà qui vont me dire : « Non mais là, si quelqu’un espionne entre le serveur et le client et m’envoie une mauvaise clé publique, je vais n’y voir que du feu ! ». Tout est prévu ! C’est pourquoi il existe un mécanisme de certificats.

Comment savoir si tu es bien celui que tu dis être ?

Vos papiers s’il vous plait !

Pour prouver son identité, un serveur va fournir un certificat. C’est un peu comme sa carte d’identité. Et comme pour les papiers officiels, ceux-ci sont délivrés par les autorités compétentes, les Autorités de Certification[6] (CA en anglais). Ce sont des tiers de confiance, faisant partie de la gouvernance d’Internet, qui atteste de l’identité de la personne (physique ou morale) qui souhaite mettre en place un serveur avec SSL. L’un des plus connu est Verisign®. Tu te souviens, on en a déjà parlé dans l’article sur le DNS.

Ces autorités de certifications, qui font autorité, diffusent leurs clés publiques. Ces dernières sont d’ailleurs intégrées aux navigateurs que tu utilises pour aller sur le web.

Une sécurité assurée

Afin de protéger leurs certificats racines, les autorités de certifications utilisent des certificats intermédiaires. En effet, la corruption d’un certificat d’une CA entrainerait la corruption de tous les certificats qui ont été signés avec. On parle alors de chaîne de confiance, depuis le certificat racine jusqu’au certificat du serveur. Le certificat racine signe un certificat qui signe un certificat…qui signe le certificat du serveur.

Par exemple, le site www.informatiquesanscomplexe.com possède un certificat signé par « Let’s Encrypt Authority X3 », lui-même signé par le certificat racine « DST Root CA X3 ».

Il existe plusieurs formats de certificats. Le plus utilisé est le X.509. Un certificat contient de nombreuses informations, et entre autres :

  • Le format et la version du format
  • Un numéro de série unique
  • L’algorithme qui a servi à signer le certificat
  • Des dates de validités :
    • Une date « pas avant » qui donne la date de début de validité du certificat.
    • Une date « pas après » qui donne la date de fin de validité du certificat.
  • Une information d’authentification, comme par exemple l’URL du site web.
  • La clé publique et l’algorithme associé.

Les certificats ayant une date de validité, il est donc essentiel de les renouveler périodiquement.

Signez, s’il vous plait !

Les certificats garantissent donc, entre autres :

  • La non-répudiation : L’organisme qui a signé le certificat ne pourra pas le nier.
  • L’intégrité : Les données du certificat ne peuvent pas être modifier, grâce à la signature.
  • La confidentialité : Les données du certificat sont chiffrées.
  • L’authentification : Les données du certificat sont certifiées authentiques par la CA.

Pour obtenir un certificat signé, on doit envoyer ses données à l’autorité de certification (CA). Après vérification de l’exactitude des données, la CA calcule l’empreinte numérique de ces données avec une fonction de hachage[7] (En général SHA-256). Elle chiffre ensuite cette empreinte avec sa clé privée. Cette empreinte chiffrée est la signature du certificat. L’autorité fournit alors le certificat contenant cette signature.

La signature d'un certificat SSL
La signature d’un certificat SSL

Je sais qui tu es vraiment !

Lorsque ton navigateur se connecte sur un site Internet en HTTPS, celui-ci va récupérer le certificat associé. Grâce aux clés publiques, il va vérifier toute la chaîne de certification jusqu’au certificat du serveur. Il va alors calculer l’empreinte de ce certificat serveur avec la même fonction de hachage que l’autorité de certification. Puis il utilise la clé publique du certificat pour en déchiffrer la signature et obtenir ainsi l’empreinte inscrite dans celui-ci. Il lui suffit alors de comparer les 2 empreintes et de s’assurer qu’elles coïncident.

Authentification d'un certificat
Authentification d’un certificat

Les échanges SSL

Le protocole comporte 2 grandes parties :

  • La partie « Handshake » : le client et le serveur se mettent d’accord sur la façon dont ils vont communiquer.
  • La partie « Record » : le client et le serveur échange effectivement des données.

Serrons-nous la main

Lors de la première phase, le « Handshake[8] » (Poignée de main en français), le client et le serveur vont négocier les paramètres nécessaires à leurs échanges via les messages suivants (ici volontairement simplifié) :

  • ClientHello : Le client envoie au serveur sa version de SSL, un identifiant unique de session et la liste des algorithmes de chiffrement et de compression qu’il sait utiliser.
  • ServerHello : Suivant ses propres capacités, le serveur envoie au client la version de SSL qui va être utilisé, un identifiant unique de session ainsi que les algorithmes de chiffrement et de compression qui seront utilisés.
  • Certificate : Le serveur envoie son certificat au client. Ce dernier peut alors l’authentifier comme nous l’avons vu précédemment.
  • ClientKeyExchange : Le client génère un clé pré-maître, chiffre celle-ci avec la clé publique du serveur et lui envoie.
  • MasterKey : Le client et le serveur génère les secrets maîtres qui serviront à chiffrer les échanges. A partir de maintenant, tous les échanges seront chiffrés.
  • Finished : Le client et le serveur conclue leur négociation et entame l’échange de données.

Le protocole prévoie également la possibilité pour le serveur de demander un certificat au client. Cela permet au serveur d’authentifier les personnes autorisées à s’y connecter.

SSL : Protocole Handshake
SSL : Protocole Handshake

Et maintenant, échangeons

Le protocole « Record[9] » se charge alors des échanges de données entre le client et le serveur. Il assure :

  • La confidentialité des échanges, grâce au chiffrement des données échangées.
  • L’intégrité des échanges, grâce à la signature des paquets envoyés.

Comme nous l’avions vu dans l’article sur la communication des ordinateurs, tout cela est affaire d’encapsulation.

Quand le client veut envoyer des données, celles-ci sont découpées en fragments. Ces fragments sont alors compressés. Une fonction de hachage en calcul une signature, le MAC (Message Authentication Code). Cette signature est accolée au fragment et le tout est chiffré, avec les clés déterminées avec le protocole « handshake ». Ce paquet est alors envoyé au serveur.

Une fois arrivé sur le serveur, son entête est lu puis le paquet est déchiffré. La signature du paquet est calculée et comparée avec celle qui lui est accolée. Si tout coïncide, alors le serveur décompresse le paquet et le réassemble avec les autres pour reconstituer les données.

Si jamais quelque chose se passait mal, il existe un protocole « Alarm » qui permet de le signaler à son interlocuteur.

SSL : Protocole Record
SSL : Protocole Record

SSL : si possible tout le temps !

Voilà, maintenant tu sais un peu plus comment tes communications sont protégées lorsque tu effectues des achats sur Internet. Alors la prochaine fois que tu achèteras une paire de basket ou un téléviseur sur le web, n’oublie pas de vérifier la présence du cadenas dans ton navigateur. Cela signifiera que tout ce que tu viens de lire est mis en place pour te protéger. Rassurant, non ?


[1] https://www.engadget.com/2014-05-10-history-of-netscape.html
[2] https://tools.ietf.org/html/rfc8446
[3] https://fr.wikipedia.org/wiki/Chiffrement_par_d%C3%A9calage
[4]https://www.tutorialspoint.com/cryptography_with_python/cryptography_with_python_understanding_rsa_algorithm.htm
[5] https://fr.wikipedia.org/wiki/%C3%89change_de_cl%C3%A9s_Diffie-Hellman
[6] https://fr.wikipedia.org/wiki/Autorit%C3%A9_de_certification
[7] https://fr.wikipedia.org/wiki/Fonction_de_hachage
[8] https://www.frameip.com/ssl-tls/#41-8211le-protocole-hanshake
[9] https://www.frameip.com/ssl-tls/#44-8211le-protocole-record

Thierry DAUGER


Your Signature

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Subscribe to our newsletter now!

>