Partage des données du secteur public

HTTPS, SSL, TLS : Sécuriser les échanges sur Internet

#Sécurité 27.03.2015 4min

Depuis les débuts d’Internet, la sécurité des communications a toujours été un enjeu majeur pour les utilisateurs comme pour les fournisseurs de services. Le chiffrement et l’authentification des échanges, destinés à empêcher une personne malveillante d’intercepter les communications, sont assurés par le protocole SSL/TLS qui fournit le “S” (pour Secure) de HTTPS.

TLS & HTTPS, les piliers de la sécurité sur Internet

TLS (le successeur de SSL) offre deux fonctionnalités majeures : l’authentification des acteurs et le chiffrement de la communication. L’authentification se fait par le biais de certificats numériques attribués aux serveurs et, dans ces certains cas, aux clients. Lors de l’établissement de la connexion, ces certificats sont échangés et vérifiés par TLS.

Une fois les participants authentifiés, TLS génère et échange une clé de chiffrement. Cette clé sera utilisée par la suite pour chiffrer toutes les données échangées durant la session. Une fois chiffrées, ces données sont alors inutilisables pour un attaquant qui ne dispose pas de la clé.

On assiste depuis quelques années à une prise de conscience des risques liés aux communications non sécurisées sur Internet et de plus en plus de services proposent une connexion HTTPS, si ce n’était pas déjà le cas, voire migrent vers du “HTTPS only”. C’est également le cas d’Oodrive, qui propose depuis longtemps une connexion sécurisée à ses services. Quant à RKube, l’offre grand publique, elle n’est disponible qu’en HTTPS.

Des exigences de sécurité toujours plus fortes

Toutefois, suite aux révélations sur la NSA et la découverte de certaines failles dans TLS (comme Heartbleed), il est devenu nécessaire d’aller plus loin dans le niveau de sécurité proposé aux utilisateurs. C’est pourquoi les versions récentes de TLS proposent une fonctionnalité importante appelée Forward Secrecy ou Confidentialité Persistante.

Comme décrit précédemment, TLS utilise une clé de chiffrement partagée entre le client et le serveur pour chiffrer la communication. Cette clé ne doit pas être interceptée par un attaquant, aussi est-elle générée simultanément par le client et le serveur en partant d’une “pré-clé” générée par le client et chiffrée via la clé publique du serveur. Le serveur la déchiffre ensuite en utilisant sa clé privée*, qu’il est le seul à posséder et sur laquelle repose toute la sécurité de l’échange .

* Ce type de chiffrement est appelé chiffrement asymétrique : tout le monde peut chiffrer via le clé publique mais seule la clé privée, qui est secrète, peut déchiffrer

BLOG_articleJeremyC_schema1_27.03.15

La clé privée du serveur est donc une donnée critique. Si quelqu’un arrive à s’en emparer, il sera en mesure de déchiffrer la pré-clé et donc de reconstituer la clé de chiffrement finale de la session, lui permettant ensuite de déchiffrer l’ensemble de la communication.

Le risque ne s’arrête pas là puisqu’une personne ayant enregistré les précédentes communications entre les utilisateurs et le serveur sera alors en mesure de toutes les déchiffrer une fois en possession de la clé privée, et ce sans limite de durée dans le temps. C’est là qu’intervient le concept de Confidentialité Persistante qui assure non seulement que vos communications sont confidentielles aujourd’hui, mais qu’elles le seront aussi dans le futur même si le serveur est victime d’un piratage et que sa clé privée est volée.

La Confidentialité Persistante via un échange de clés plus sûr

Afin d’assurer cette persistance de la confidentialité, TLS propose un système d’échange de clés alternatif appelé Diffie-Hellman. Ici, la clé finale est toujours générée simultanément sur le serveur et sur le client mais sans avoir besoin d’échanger une pré-clé secrète et donc sans avoir à se reposer sur la clé privée du serveur. Cet échange de clé utilise une fonction mathématique complexe et peut-être schématisé comme suit.

BLOG_articleJeremyC_schema2_27.03.15

Icônes de iconsmind.com et Murat Ak de thenounproject.com

Comme on peut le voir sur le schéma le client et le serveur génèrent la clé finale (BLOG_articleJeremyC_picto_clef_orange1_27.03.15) en utilisant une valeur secrète (BLOG_articleJeremyC_picto_cadena_vert2_27.03.15 pour le navigateur, BLOG_articleJeremyC_picto_cadena_Bleu3_27.03.15 pour le serveur) qui n’est jamais échangée et n’a donc pas besoin d’être chiffrée via une clé privée. De plus, tous les paramètres utilisés pour la génération sont uniques pour cette communication. Cela signifie que même si un attaquant rentre en possession de la clé de chiffrement finale ou des valeurs secrètes, cela ne lui sera utile que pour déchiffrer une seule session, à l’inverse du système d’échange précédent avec lequel la possession de la clé privée permet de déchiffrer toutes les sessions futures et/ou passées.

La Confidentialité Persistante offre donc un niveau de sécurité supplémentaire et constitue le seul moyen de garantir aux utilisateurs la sécurité de leurs communications dans le temps. Aujourd’hui, la plupart des navigateurs web supportent TLS avec la Confidentialité Persistante. C’est aux services web de configurer leurs serveurs afin qu’ils proposent eux aussi cette fonctionnalité or seulement 60% le font. Oodrive, pour qui la sécurité est au coeur de son métier, propose évidement la Confidentialité Persistante sur la majeure partie de ses services et s’emploie à la déployer sur les autres.