Sur Internet, chaque échange de données peut potentiellement être exposé à des risques s’il n’est pas correctement protégé. Informations personnelles, identifiants, coordonnées bancaires… sans système de sécurité, ces données peuvent facilement être interceptées. C’est pour répondre à cette problématique qu’est né le protocole SSL, conçu pour sécuriser les communications entre les utilisateurs et les sites web. Même s’il a depuis été remplacé techniquement par TLS, le terme SSL reste couramment utilisé pour parler des connexions sécurisées. Dans les lignes qui suivent, nous vous proposons de découvrir ce qu’est le protocole SSL, comment il fonctionne et pourquoi il reste un pilier incontournable de la sécurité sur le web.

Définition du protocole SSL : Une couche de sécurité entre le client et le serveur

Le protocole SSL, acronyme de Secure Sockets Layer, est un protocole de sécurisation des échanges sur Internet qui a vu le jour au début des années 1990, à une époque où le Web entamait à peine son essor commercial. Il a été développé par l’entreprise américaine Netscape Communications Corporation, cofondée en 1994 à Mountain View (Californie) par Marc Andreessen et Jim Clark. À l’époque, Netscape est déjà célèbre pour son navigateur web phare, Netscape Navigator, qui domine largement le marché naissant de la navigation Internet. Dans ce contexte d’expansion rapide du Web, la nécessité de sécuriser les transactions en ligne devient une priorité. Les premiers sites marchands, les services bancaires à distance et les formulaires de contact commencent à manipuler des informations sensibles : identifiants, adresses email, numéros de carte bancaire… C’est pour répondre à cette problématique que Netscape lance le protocole SSL en 1995, avec la publication de la version 2.0 (la version 1.0 n’ayant jamais été rendue publique en raison de failles de sécurité majeures). SSL a pour vocation de créer un canal de communication sécurisé entre deux machines reliées par Internet, généralement entre un client (le navigateur de l’utilisateur) et un serveur (le site web auquel il se connecte). Pour cela, le protocole ajoute une couche de sécurité au-dessus des protocoles de communication classiques comme HTTP. Ce mécanisme donne naissance au fameux HTTPS, ou HyperText Transfer Protocol Secure, qui intègre le chiffrement SSL (ou son successeur TLS) à la navigation web. Techniquement, SSL repose sur trois principes fondamentaux qui en font un standard de la sécurité numérique :

• Chiffrement : Les données échangées sont encodées à l’aide d’un algorithme mathématique afin qu’elles ne puissent être lues par des tiers non autorisés. Ce chiffrement repose sur des clés, qui peuvent être symétriques (même clé pour chiffrer et déchiffrer) ou asymétriques (clé publique et clé privée distinctes) ;
• Authentification : Grâce à un certificat numérique délivré par une autorité de certification (CA), le serveur peut prouver son identité au client. Ce mécanisme évite que l’utilisateur se connecte par erreur à un site frauduleux imitant un site légitime (attaque de type man-in-the-middle) ;
• Intégrité : SSL utilise des fonctions de hachage (comme SHA-256) pour s’assurer que les données n’ont pas été altérées entre l’envoi et la réception. Si une modification est détectée, la communication est interrompue.

Ces trois piliers (confidentialité, authentification et intégrité) permettent de sécuriser les interactions entre utilisateurs et services en ligne, rendant SSL indispensable pour des secteurs comme :

• Le commerce électronique (paiement en ligne, panier d’achat) ;
• La banque et les services financiers (consultation de comptes, virements) ;
• Les portails administratifs et e-gouvernement ;
• Les plateformes de messagerie ou d’échange de documents confidentiels.

En 1996, Netscape publie SSL 3.0, une version nettement plus robuste, élaborée avec l’aide de Paul Kocher, un cryptographe reconnu. Cette version est considérée comme l’ancêtre direct de TLS, le Transport Layer Security, qui sera standardisé par l’IETF (Internet Engineering Task Force) en 1999 pour succéder à SSL, jugé obsolète. Malgré son remplacement officiel, le terme « SSL » est resté profondément ancré dans le langage courant. On parle encore de « certificats SSL » ou de « connexion SSL », même lorsque c’est en réalité le protocole TLS qui est utilisé en arrière-plan, souvent dans ses versions les plus récentes (TLS 1.2 ou TLS 1.3).

Le fonctionnement du protocole SSL par étapes

Le fonctionnement du protocole SSL repose sur une série d’étapes bien définies qui s’exécutent de manière quasi-invisible pour l’utilisateur final. Voici comment se déroule une connexion SSL typique :

1. La négociation (ou « handshake »)

La première étape de toute communication sécurisée via le protocole SSL est appelée la négociation, ou SSL handshake. C’est un processus fondamental qui se déroule avant l’échange effectif des données, et dont l’objectif est d’établir un environnement de confiance entre les deux parties, tout en définissant les paramètres de la session sécurisée. Cette négociation se déroule en plusieurs phases successives, qui s’exécutent en quelques fractions de seconde. Voici les principales étapes de cette phase :

• 1.1 – Initialisation de la connexion : Le client (généralement un navigateur web ou une application) envoie un message « ClientHello » au serveur. Ce message contient un ensemble d’informations importantes : la version de SSL/TLS supportée, une liste de chiffres (algorithmes de chiffrement) compatibles, des paramètres aléatoires, ainsi que d’éventuelles extensions ;
• 1.2 – Réponse du serveur : Le serveur répond avec un message « ServerHello » qui contient, lui aussi, des paramètres aléatoires, la version du protocole choisie, et l’algorithme de chiffrement sélectionné pour la session (généralement le plus élevé supporté par les deux parties). Il transmet également son certificat numérique SSL, qui contient sa clé publique, le nom de domaine, les informations de l’organisation, la période de validité du certificat, et la signature d’une autorité de certification (ou CA, pour Certificate Authority) ;
• 1.3 – Vérification du certificat : Le client vérifie alors que le certificat présenté est bien signé par une autorité de certification reconnue et de confiance. Cette vérification permet de s’assurer que le client n’est pas en train de se connecter à un site malveillant. Si le certificat est invalide ou expiré, le navigateur affiche une alerte de sécurité ;
• 1.4 – Génération de la clé de session : Une fois le certificat validé, le client génère une clé de session, qui sera utilisée pour chiffrer les données pendant toute la durée de la session. Cette clé est dite « symétrique », car elle sera utilisée à la fois pour le chiffrement et le déchiffrement. Pour garantir sa confidentialité, le client chiffre cette clé de session à l’aide de la clé publique du serveur (obtenue via le certificat), et lui envoie ;
• 1.5 – Déchiffrement de la clé de session : Le serveur, de son côté, utilise sa clé privée (secrète et unique) pour déchiffrer la clé de session. Une fois la clé partagée, les deux parties disposent d’un secret commun leur permettant de communiquer de manière chiffrée et sécurisée.

Ce processus utilise la cryptographie asymétrique (à base de clés publique/privée) uniquement durant cette phase initiale de négociation. Une fois la clé de session échangée, la communication bascule sur un chiffrement symétrique, beaucoup plus rapide et adapté aux échanges de données en temps réel. La sécurité de cette négociation repose sur des standards de cryptographie éprouvés, comme RSA, ECDSA ou Diffie-Hellman, selon les configurations choisies par le client et le serveur. Certains échanges modernes (notamment avec TLS 1.3) utilisent exclusivement des clés éphémères pour renforcer la confidentialité (ce qu’on appelle Perfect Forward Secrecy). Ainsi, la phase de handshake SSL joue un rôle décisif dans la création d’une connexion sécurisée. Elle permet :

• De garantir l’identité du serveur (et parfois du client) ;
• De négocier les paramètres de sécurité de la session ;
• De partager une clé de session secrète à l’abri des regards extérieurs.

Une fois cette négociation terminée avec succès, la communication peut commencer sur une base sécurisée, en toute transparence pour l’utilisateur final.

2. L’échange sécurisé des données dans le protocole SSL

Une fois la phase de négociation (ou handshake) achevée avec succès, le client et le serveur disposent tous deux d’une clé de session symétrique, partagée de manière sécurisée. Cette clé devient la pierre angulaire de la communication : elle va servir à chiffrer et déchiffrer toutes les données échangées pendant la session SSL. Le chiffrement symétrique repose sur un principe simple mais puissant : Lmême clé est utilisée des deux côtés, à l’envoi comme à la réception. Contrairement au chiffrement asymétrique utilisé lors du handshake (clé publique / clé privée), ce mode de chiffrement est bien plus rapide et léger en termes de ressources. C’est précisément cette efficacité qui permet au protocole SSL de sécuriser des communications en temps réel sans ralentir l’expérience utilisateur. Les algorithmes de chiffrement symétrique les plus couramment utilisés avec SSL (et surtout TLS) incluent :

• AES (Advanced Encryption Standard) : Très répandu, il propose des longueurs de clé de 128, 192 ou 256 bits ;
• ChaCha20 : Un algorithme plus récent, conçu pour offrir une excellente sécurité même sur des appareils mobiles ou peu puissants ;
• 3DES (Triple DES) : Un algorithme plus ancien, aujourd’hui largement abandonné car considéré comme trop lent et moins sécurisé.

Grâce à ce chiffrement symétrique, toutes les informations envoyées (qu’il s’agisse de mots de passe, de coordonnées bancaires, de formulaires de contact ou de fichiers) sont rendues totalement inintelligibles pour tout tiers qui tenterait de les intercepter. Même si un pirate parvient à intercepter les données, il ne pourra rien en faire sans la clé de session, qui reste inconnue de toute personne extérieure à la communication. Mais la sécurisation des données ne s’arrête pas là. Le protocole SSL intègre également des mécanismes d’intégrité basés sur des fonctions de hachage cryptographique. Leur objectif est de s’assurer que les messages n’ont pas été modifiés, volontairement ou accidentellement, entre l’émetteur et le récepteur.

Concrètement, avant d’envoyer un paquet de données, le système calcule une empreinte numérique de ce message, appelée MAC (Message Authentication Code). Cette empreinte est jointe au message chiffré. À la réception, le destinataire recalcule la même empreinte à partir du message reçu, et la compare à celle envoyée. Si les deux valeurs correspondent, le message est validé. Sinon, il est rejeté automatiquement. Les algorithmes de hachage fréquemment utilisés dans ce contexte sont :

• SHA-256 (Secure Hash Algorithm) : utilisé dans les versions récentes de TLS pour garantir un haut niveau de sécurité ;
• SHA-1 : aujourd’hui déconseillé en raison de vulnérabilités connues, mais encore présent dans certaines implémentations plus anciennes ;
• MD5 : obsolète, et non recommandé dans les contextes sensibles.

Ce système permet de se prémunir contre plusieurs types d’attaques, notamment les attaques dites man-in-the-middle, où un pirate tente de modifier ou d’insérer des données dans la communication sans que les deux parties ne s’en aperçoivent. Grâce aux fonctions de hachage et à la vérification systématique de l’intégrité, toute modification frauduleuse est immédiatement détectée. Enfin, dans les versions les plus récentes du protocole (notamment TLS 1.3), les échanges sont encore plus sécurisés grâce à l’utilisation de clés éphémères générées pour chaque session, et à une simplification du processus de chiffrement qui élimine certains anciens algorithmes jugés vulnérables. Cela permet non seulement d’accélérer les échanges, mais aussi de renforcer la confidentialité à long terme des données (notion de forward secrecy).

3. La fermeture de la session SSL

Une fois que toutes les données ont été échangées entre le client et le serveur, la session SSL ne se termine pas brutalement. Au contraire, elle fait l’objet d’une fermeture structurée et sécurisée, afin de s’assurer que la communication a bien pris fin de manière volontaire et sans altération. Cette étape est essentielle pour préserver la fiabilité de la connexion et éviter certaines failles de sécurité.

Le protocole SSL (et TLS), par exemple sur un VPS d’OVH, prévoit un mécanisme spécifique appelé « close_notify ». Il s’agit d’un message de signalement envoyé par l’une des deux parties (en général le client) pour informer l’autre qu’aucune donnée supplémentaire ne sera transmise. Ce message indique clairement que la session sécurisée va être clôturée. À réception de ce message, le serveur répond à son tour par un close_notify, confirmant qu’il met également fin à la session. Ce processus bilatéral garantit que les deux parties sont d’accord sur la fermeture, et que celle-ci est intentionnelle et non provoquée par une coupure inattendue ou malveillante.

Ce mécanisme est particulièrement important pour contrer les attaques de type « truncation attack », dans lesquelles un attaquant intercepte la communication et la termine prématurément sans envoyer de message de clôture. Cela pourrait faire croire à l’une des parties que la session a été interrompue correctement, alors qu’en réalité, elle a été manipulée. Une telle attaque pourrait conduire à la perte ou à la corruption partielle de données, voire à des vulnérabilités exploitables. En suivant rigoureusement le protocole SSL jusqu’à la fermeture, le client et le serveur peuvent vérifier que :

• Toutes les données ont bien été transmises sans altération.
• Aucune partie n’a interrompu la session de façon non sécurisée.
• La clé de session n’est plus utilisée une fois la connexion terminée.

Il est important de noter que, dès la fermeture de la session, la clé de session symétrique est invalidée. Cela signifie qu’elle ne pourra plus être utilisée pour déchiffrer d’autres messages, même si un tiers venait à l’obtenir ultérieurement. Cette pratique contribue à renforcer la sécurité globale du protocole en limitant la réutilisation des clés et en protégeant les données échangées même après la session. Enfin, une bonne gestion des fermetures de session SSL est également essentielle pour les performances des serveurs web. Un serveur mal configuré ou qui ne libère pas correctement les ressources allouées aux sessions terminées peut rapidement voir ses performances dégradées, voire devenir vulnérable à des attaques de saturation (type denial-of-service). Voici un schéma simplifié récapitulant les différentes étapes d’une communication SSL typique :

Ce processus rigoureux, de l’ouverture à la fermeture de la session, montre à quel point le protocole SSL a été pensé pour garantir une sécurité de bout en bout dans les échanges numériques. Même les détails les plus subtils, comme la fin de la connexion, sont encadrés afin de minimiser les risques et d’assurer une confidentialité totale des données.

SSL, TLS et certificats numériques : Quelles sont les différences ?

Dans le langage courant, on parle souvent de « certificat SSL » ou de « connexion SSL » pour désigner un site sécurisé en HTTPS. Pourtant, dans la réalité technique d’aujourd’hui, SSL n’est plus utilisé : il a été remplacé par son évolution directe, le protocole TLS (Transport Layer Security), plus récent, plus performant et nettement plus sécurisé. Alors, pourquoi cette confusion persiste-t-elle ? Principalement pour des raisons d’usage historique. SSL a été le premier protocole de sécurisation des communications sur Internet, introduit au milieu des années 1990 par Netscape (notamment avec SSL 2.0 en 1995, suivi de SSL 3.0 en 1996). À l’époque, il a posé les bases de la confiance sur le Web, notamment pour les premiers paiements en ligne. Cependant, des failles critiques ont rapidement été identifiées dans SSL. En réponse, l’IETF (Internet Engineering Task Force), l’organisme chargé de la standardisation des protocoles Internet, a conçu TLS comme remplaçant officiel. TLS 1.0 a été publié en 1999, reprenant de nombreux éléments de SSL 3.0, mais en y ajoutant des corrections de sécurité. Aujourd’hui, SSL est considéré comme obsolète, et les navigateurs modernes ont même désactivé son support depuis plusieurs années. Voici les principales différences entre SSL et TLS :

• Sécurité : TLS intègre des algorithmes cryptographiques plus robustes et une meilleure protection contre les attaques connues (comme POODLE, BEAST, ou DROWN, qui ciblaient SSL et TLS dans ses premières versions) ;
• Efficacité : TLS est plus rapide dans l’établissement de la connexion, surtout dans sa version 1.3, grâce à une négociation plus simple et un nombre réduit d’échanges entre client et serveur ;
• Support : SSL 2.0 et SSL 3.0 sont aujourd’hui totalement abandonnés. TLS 1.2 reste la version la plus largement utilisée, tandis que TLS 1.3, publié en 2018, s’impose progressivement comme la norme actuelle pour les connexions sécurisées.

Malgré cette transition technique, le terme « SSL » continue d’être employé par commodité, notamment dans les interfaces d’hébergement web, les certificats numériques, ou les guides destinés aux débutants. Dans la pratique, quand vous achetez un « certificat SSL », il s’agit bien d’un certificat compatible TLS.

Les certificats numériques : La pièce d’identité d’un site Internet sécurisé

Que l’on parle de SSL ou de TLS, les deux protocoles reposent sur un élément central : le certificat numérique. Ce fichier, délivré par une autorité de certification (Certificate Authority, ou CA), sert à prouver l’identité d’un site web et à établir une connexion de confiance entre le client (le navigateur de l’utilisateur) et le serveur. Un certificat numérique contient plusieurs informations essentielles :

• Le nom de domaine (ou les sous-domaines) que le certificat protège ;
• La clé publique utilisée pour le chiffrement initial
• La durée de validité du certificat (souvent 1 an ou 90 jours pour les certificats gratuits)
• La signature numérique de l’autorité de certification qui l’a émis

Lorsque votre navigateur accède à un site web sécurisé en HTTPS, il vérifie automatiquement que le certificat est valide, signé par une autorité de confiance, et correspond bien au nom de domaine demandé. Si l’un de ces critères échoue, une alerte de sécurité s’affiche.

Les différents niveaux de validation de certificats SSL/TLS

Il existe plusieurs types de certificats numériques, selon le niveau de vérification effectué avant leur délivrance. Ce niveau influe directement sur la confiance que l’on peut accorder au site :

Les certificats DV sont les plus faciles à obtenir et peuvent même être gratuits (via Let’s Encrypt sur OVH par exemple). Ils assurent le chiffrement des données, mais sans garantie d’identité pour l’internaute. À l’inverse, les certificats EV demandent une procédure de validation approfondie, mais offrent un gage de confiance maximal, c’est notamment pour cette raison qu’ils sont utilisés par les sites traitant des données bancaires ou médicales.

Il est également possible d’obtenir des certificats multi-domaines (SAN pour Subject Alternative Names) ou des certificats Wildcard (qui couvrent tous les sous-domaines d’un domaine principal), en fonction des besoins spécifiques de chaque entreprise ou infrastructure web.