Ce que personne ne vous dit sur SSL et TLS
SSL et TLS protègent vos données en ligne. Pourtant, la majorité des gens confondent les deux. Pire : beaucoup de sites utilisent encore des versions obsolètes sans le savoir.
C'est un problème sérieux. Une mauvaise configuration expose vos utilisateurs à des attaques réelles.
Le problème : êtes-vous vraiment protégé ?
Votre site affiche un cadenas vert. Vous dormez tranquille. Mais ce cadenas ne dit pas quelle version du protocole tourne sous le capot.
SSL 3.0 est mort depuis 2015. TLS 1.0 et 1.1 sont officiellement dépréciés depuis 2021. Pourtant, des serveurs mal configurés les acceptent encore.
Un attaquant n'a pas besoin de casser votre chiffrement. Il lui suffit de vous forcer à utiliser une version vulnérable : c'est le principe du downgrade attack.
Ce que sont vraiment SSL et TLS
SSL : l'ancêtre qui ne devrait plus tourner
SSL signifie Secure Sockets Layer. Netscape l'a inventé en 1994 pour sécuriser les transactions en ligne. À l'époque, c'était nouveau.
SSL 1.0 n'a jamais été publié. SSL 2.0 est sorti en 1995, criblé de failles. SSL 3.0 a suivi en 1996, avant que l'attaque POODLE l'enterre définitivement en 2014.
Aujourd'hui, SSL n'existe plus. Le terme reste dans le langage courant, mais le protocole ne devrait figurer sur aucun serveur moderne.
TLS : le successeur qui tient ses promesses
TLS signifie Transport Layer Security. C'est le vrai protocole derrière le HTTPS que vous utilisez chaque jour.
TLS 1.0 est apparu en 1999, TLS 1.1 en 2006, TLS 1.2 en 2008. C'est cette troisième version qui a vraiment stabilisé la sécurité web. TLS 1.3, sorti en 2018, est ce qui tourne sur les serveurs sérieux.
Chaque version corrige les failles de la précédente. L'évolution n'est pas cosmétique, elle est structurelle.
Comment ça fonctionne : la poignée de main expliquée
Le handshake : tout se joue ici
Quand votre navigateur se connecte à un serveur HTTPS, une négociation s'engage. On l'appelle le handshake (poignée de main). C'est là que tout se décide.
Le navigateur annonce les versions et algorithmes qu'il prend en charge. Le serveur répond avec son choix. Le certificat est échangé, vérifié, et une clé de session est générée.
Cette clé de session ne sert qu'une seule fois. Si un attaquant la capture, elle devient inutile dès la prochaine connexion : c'est le Perfect Forward Secrecy.
Chiffrement asymétrique puis symétrique
SSL/TLS combine deux types de chiffrement. D'abord le chiffrement asymétrique (clé publique/clé privée) pour l'échange initial. Ensuite le chiffrement symétrique, bien plus rapide, pour les données échangées.
RSA, ECDSA et ECDHE gèrent l'asymétrique. AES-GCM ou ChaCha20 gèrent le symétrique. TLS 1.3 a retiré les algorithmes faibles de cette liste.
Résultat : personne entre vous et le serveur ne peut lire ce qui transite.
Les différences entre TLS 1.2 et TLS 1.3
TLS 1.2 : fiable mais verbeux
TLS 1.2 nécessite deux allers-retours complets avant d'envoyer des données (2-RTT). C'est fonctionnel, mais lent. Il accepte aussi des algorithmes historiquement faibles comme RC4 ou SHA-1.
Sa flexibilité se retourne parfois contre lui. Plus d'options signifie plus de risques de mauvaise configuration : un administrateur peu vigilant peut activer des suites cryptographiques obsolètes sans s'en apercevoir.
TLS 1.2 reste acceptable quand il est correctement configuré, mais il exige une attention constante.
TLS 1.3 : rapide et radical
TLS 1.3 réduit le handshake à un seul aller-retour (1-RTT). Dans certains cas, la reprise de session se fait en 0-RTT. Les gains de performance sont mesurables.
Surtout, TLS 1.3 a supprimé la négociation des algorithmes faibles. Pas d'option, pas de compromis : les suites cryptographiques disponibles sont toutes solides.
Le Perfect Forward Secrecy est obligatoire dans TLS 1.3, alors qu'il n'était qu'une option dans TLS 1.2. Décision radicale, et c'était la bonne.
Les certificats : le maillon humain de la chaîne
Un protocole solide ne sert à rien avec un mauvais certificat. Le certificat SSL/TLS prouve l'identité du serveur auprès du navigateur.
Il existe trois niveaux de validation : DV (Domain Validation), OV (Organization Validation) et EV (Extended Validation). Le niveau DV suffit techniquement pour chiffrer, mais il ne prouve pas que vous êtes bien l'entreprise que vous prétendez être.
Les Autorités de Certification comme Let's Encrypt, DigiCert ou Sectigo signent ces certificats. Si l'une d'elles est compromise, toute sa chaîne de confiance s'effondre. C'est pour ça que les navigateurs maintiennent des listes de CA révoquées.
Ce que vous devez vérifier aujourd'hui
Audit de votre configuration
Rendez-vous sur SSL Labs (ssllabs.com/ssltest). Entrez votre domaine. Le score idéal est A+. Si vous obtenez B ou moins, vous avez un problème concret à régler.
Vérifiez quelles versions de TLS votre serveur accepte. Désactivez TLS 1.0 et 1.1 immédiatement. Activez TLS 1.3 si ce n'est pas encore fait.
Ce qui doit être actif
- TLS 1.3, activé et prioritaire
- TLS 1.2, activé avec suites cryptographiques strictes
- TLS 1.1 et antérieur, désactivés sans exception
- HSTS, activé pour forcer HTTPS sur toutes les connexions
- OCSP Stapling, activé pour valider les certificats plus rapidement
Une question de priorité, pas de compétence
Configurer TLS correctement prend moins d'une heure. Pourtant, des milliers de sites ne le font pas.
La sécurité passe après le design, après le SEO, après les fonctionnalités. C'est un choix, souvent inconscient.
Vos utilisateurs vous font confiance quand ils voient ce cadenas. Méritez-le.
