Jour 40 Day 40 · jeudi 1 octobre 2026 Thursday 1 October 2026 Sécurité Intermédiaire
Chiffrement symétrique/asymétrique & TLS Symmetric/asymmetric encryption & TLS
Une clé partagée ou une paire publique/privée ? Comprendre pourquoi TLS utilise les deux, ce que prouve un certificat et comment répondre à « explique-moi HTTPS » — question quasi garantie en entretien. One shared key or a public/private pair? Understand why TLS uses both, what a certificate actually proves, and how to answer "explain HTTPS to me" — a near-guaranteed interview question.
L’essentiel
Le chiffrement transforme des données lisibles en données illisibles pour quiconque n’a pas la bonne clé. Deux familles se partagent le travail, et tout l’art des protocoles modernes consiste à les combiner.
Le chiffrement symétrique (AES) utilise une seule clé pour chiffrer et déchiffrer. Il est très rapide — les CPU ont des instructions dédiées (AES-NI), on chiffre plusieurs Go/s. Son talon d’Achille : les deux parties doivent posséder la même clé. Comment l’échanger à travers un réseau qu’on ne contrôle pas ? L’envoyer en clair revient à poster le code du coffre avec le coffre.
Le chiffrement asymétrique (RSA, courbes elliptiques) résout ce problème avec une paire de clés : la clé publique se distribue à tout le monde, la clé privée ne quitte jamais son propriétaire. Ce que l’une chiffre, seule l’autre le déchiffre. Le prix : c’est lent — environ mille fois plus que l’AES — et limité à de petits messages.
| Symétrique (AES) | Asymétrique (RSA / EC) | |
|---|---|---|
| Clés | Une seule, partagée | Paire publique / privée |
| Vitesse | Go/s (accélération matérielle) | ~1000× plus lent |
| Taille de clé | 128–256 bits | RSA ≥ 2048 bits, EC 256 bits |
| Problème central | Échanger la clé | Lier la clé publique à une identité |
| Usage typique | Chiffrer le trafic (session TLS) | Échange de clé, signatures, certificats |
D’où le schéma universel — TLS, SSH, Signal, tous pareil : l’asymétrique sert à se mettre d’accord sur une clé de session, le symétrique chiffre ensuite tout le trafic. On parle de chiffrement hybride.
Comment ça marche
Le handshake TLS 1.3 tient en une phrase : client et serveur échangent de quoi dériver une clé commune, le serveur prouve son identité, puis tout passe en symétrique.
Client Serveur
│ ClientHello │
│ versions, ciphers, part DH éphémère │
│────────────────────────────────────────▶│
│ ServerHello + part DH │
│ Certificat + signature │
│◀────────────────────────────────────────│
│ │
│ chacun dérive la même clé de session │
│ (ECDHE) — elle ne circule jamais │
│ │
│═════ trafic chiffré en AES-GCM ════════▶│Étape par étape :
- ClientHello — le client annonce les versions TLS et suites cryptographiques qu’il accepte, et joint sa part publique d’un échange Diffie-Hellman éphémère.
- ServerHello — le serveur choisit la suite, renvoie sa propre part DH, son certificat, et une signature faite avec sa clé privée : la preuve qu’il détient bien la clé correspondant au certificat.
- Dérivation — chacun combine sa part privée avec la part publique de l’autre et obtient le même secret, sans qu’il ait jamais transité sur le réseau. Les clés DH étant éphémères, voler la clé privée du serveur plus tard ne permet pas de déchiffrer le trafic passé : c’est la forward secrecy.
- Session symétrique — tout le trafic passe en AES-GCM ou ChaCha20-Poly1305, du chiffrement authentifié : confidentialité et intégrité en une seule opération.
TLS 1.3 (2018) fait tout ça en un seul aller-retour (contre deux pour TLS 1.2) et a purgé les algorithmes cassés : échange de clé RSA sans forward secrecy, RC4, SHA-1.
Reste la confiance : un attaquant en position d’intermédiaire peut faire un handshake parfaitement propre… avec son propre certificat. D’où les CA (Certificate Authorities) : le certificat du serveur est signé par une CA intermédiaire, elle-même signée par une CA racine préinstallée dans l’OS ou le navigateur. Le client remonte cette chaîne de confiance jusqu’à une racine qu’il connaît ; un maillon invalide et c’est l’avertissement rouge. Let’s Encrypt a rendu les certificats gratuits et automatisés (protocole ACME, renouvellement tous les 90 jours) : plus aucune excuse pour servir du HTTP en clair.
🎤 En entretien — « Explique HTTPS à un débutant » est un classique. Version qui marche : « le cadenas fait deux promesses. Un : personne ne peut lire ni modifier ce qui transite — c’est le chiffrement. Deux : tu parles bien au site affiché dans la barre d’adresse — c’est le certificat, vérifié par un tiers de confiance. Une enveloppe scellée, plus une carte d’identité. » Deux idées, zéro jargon.
Concepts clés à maîtriser
- Chiffrer vs signer : même paire de clés, sens inverse. Chiffrer = clé publique du destinataire (lui seul déchiffre). Signer = clé privée de l’émetteur sur le hash du message ; n’importe qui vérifie avec la clé publique. La signature prouve l’auteur et l’intégrité, elle ne cache rien.
- Hash ≠ chiffrement : un hash (SHA-256) est irréversible et sans clé — on ne « déchiffre » pas un hash, on ne peut que tester des candidats. Usages : intégrité, signatures, stockage de mots de passe (via bcrypt/argon2, jamais un SHA nu).
- Certificat : une clé publique + une identité (le domaine) + des dates de validité + la signature d’une CA. Rien de secret dedans — c’est un document public.
- Courbes elliptiques : mêmes garanties que RSA avec des clés bien plus courtes (EC 256 bits ≈ RSA 3072). Le standard actuel : X25519 pour l’échange de clé, Ed25519/ECDSA pour les signatures.
- HTTPS partout : le HTTP en clair permet à tout intermédiaire (Wi-Fi public, FAI) de lire et modifier les pages — injection de scripts comprise. Le header HSTS interdit au navigateur de retenter du HTTP.
Le tout se manipule très bien avec openssl :
# Générer une paire RSA : privée (secrète) puis publique
openssl genrsa -out priv.pem 2048
openssl rsa -in priv.pem -pubout -out pub.pem
# Chiffrer avec la clé PUBLIQUE du destinataire :
# seul le détenteur de la privée pourra lire
openssl pkeyutl -encrypt -pubin -inkey pub.pem \
-in msg.txt -out msg.enc
# Signer avec sa clé PRIVÉE (hash SHA-256 signé)…
openssl dgst -sha256 -sign priv.pem -out msg.sig msg.txt
# …et n'importe qui vérifie avec la publique
openssl dgst -sha256 -verify pub.pem \
-signature msg.sig msg.txt # → Verified OK
# Voir le certificat et la chaîne d'un vrai site
openssl s_client -connect example.com:443 \
-servername example.com💡 Ordre de grandeur à retenir — AES chiffre des Go/s, RSA des Ko/s. C’est ce facteur ~1000 qui impose l’architecture hybride : l’asymétrique ne sert qu’à ouvrir la session, jamais à chiffrer le flux.
En entretien
« Symétrique vs asymétrique — et pourquoi les combiner ? » — Symétrique : une clé partagée, très rapide, mais problème d’échange de la clé. Asymétrique : paire publique/privée, résout l’échange, mais mille fois plus lent. TLS combine : échange de clé asymétrique (ECDHE) pour établir un secret commun, puis session symétrique (AES) pour le trafic. Le meilleur des deux.
« Déroule un handshake TLS. » — Version 1.3 : ClientHello avec part DH éphémère → ServerHello avec sa part DH, son certificat et une signature → chacun dérive la même clé de session → trafic en AES-GCM. Un seul aller-retour. Bonus : mentionner la forward secrecy grâce aux clés éphémères.
« À quoi sert le certificat, exactement ? » — À authentifier le serveur, pas à chiffrer. Il lie une clé publique à un domaine, sous la signature d’une CA que le client connaît déjà (chaîne de confiance). Sans lui, le chiffrement marcherait aussi bien… avec un attaquant au milieu.
« Quelle différence entre chiffrer et signer ? » — Chiffrer protège la confidentialité : clé publique du destinataire. Signer prouve l’origine et l’intégrité : clé privée de l’émetteur, vérifiable par tous. Une signature ne cache pas le message.
« Pourquoi hasher les mots de passe plutôt que les chiffrer ? » — Chiffré = réversible pour qui a la clé, et la clé est quelque part sur le serveur. Un hash lent et salé (bcrypt, argon2) ne se déchiffre pas : même l’admin de la base ne peut pas retrouver le mot de passe, seulement vérifier une tentative.
Pièges & idées reçues
⚠️ Règle d’or — on n’implémente jamais sa propre crypto, et on n’assemble même pas soi-même les primitives (mode ECB, IV réutilisé, comparaison non constante… les pièges sont innombrables). En pratique : TLS pour le transport, une lib éprouvée (libsodium) pour le reste.
- « Le certificat chiffre la connexion » — non : il authentifie. Les clés de session viennent de l’échange Diffie-Hellman ; le certificat garantit juste qu’on la négocie avec le bon serveur.
- « HTTPS cache tout » — le contenu et le chemin de l’URL, oui. Mais le domaine visité fuit via la requête DNS et le SNI du handshake (ECH est en cours de déploiement pour ce dernier).
- « SSL » — le terme survit dans le langage courant (et dans « openssl »), mais SSL 2/3 sont morts et interdits depuis des années. Le protocole s’appelle TLS, versions 1.2 et 1.3.
- Certificat auto-signé en prod — il chiffre, mais ne prouve rien : les clients doivent cliquer sur « accepter le risque », ce qui les entraîne exactement au mauvais réflexe. Réserver ça au dev local.
- MD5 et SHA-1 sont cassés pour tout usage de sécurité (collisions pratiques). SHA-256 minimum.
Pour aller plus loin
- Cloudflare — What happens in a TLS handshake? : le handshake vulgarisé proprement
- The Illustrated TLS 1.3 Connection : chaque octet du handshake, annoté — spectaculaire
- Let’s Encrypt — How it works : le protocole ACME expliqué
- RFC 8446 : la spec TLS 1.3, lisible en diagonale
- badssl.com : une galerie de certificats cassés pour voir les erreurs navigateur en vrai
The essentials
Encryption turns readable data into data that is unreadable to anyone without the right key. Two families share the work, and the whole art of modern protocols lies in combining them.
Symmetric encryption (AES) uses a single key to encrypt and decrypt. It is very fast — CPUs have dedicated instructions (AES-NI), you can encrypt several GB/s. Its Achilles heel: both parties need the same key. How do you exchange it over a network you don’t control? Sending it in cleartext is like mailing the safe’s code along with the safe.
Asymmetric encryption (RSA, elliptic curves) solves that problem with a key pair: the public key is handed out to everyone, the private key never leaves its owner. What one encrypts, only the other decrypts. The price: it is slow — roughly a thousand times slower than AES — and limited to small messages.
| Symmetric (AES) | Asymmetric (RSA / EC) | |
|---|---|---|
| Keys | One, shared | Public / private pair |
| Speed | GB/s (hardware acceleration) | ~1000× slower |
| Key size | 128–256 bits | RSA ≥ 2048 bits, EC 256 bits |
| Core problem | Exchanging the key | Binding the public key to an identity |
| Typical use | Encrypting traffic (TLS session) | Key exchange, signatures, certificates |
Hence the universal scheme — TLS, SSH, Signal, all the same: asymmetric crypto is used to agree on a session key, then symmetric crypto encrypts all the traffic. This is called hybrid encryption.
How it works
The TLS 1.3 handshake fits in one sentence: client and server exchange what they need to derive a common key, the server proves its identity, then everything switches to symmetric.
Client Server
│ ClientHello │
│ versions, ciphers, ephemeral DH share │
│────────────────────────────────────────▶│
│ ServerHello + DH share │
│ Certificate + signature │
│◀────────────────────────────────────────│
│ │
│ both derive the same session key │
│ (ECDHE) — it never travels │
│ │
│═════ traffic encrypted with AES-GCM ═══▶│Step by step:
- ClientHello — the client announces the TLS versions and cipher suites it accepts, and attaches its public share of an ephemeral Diffie-Hellman exchange.
- ServerHello — the server picks the suite, returns its own DH share, its certificate, and a signature made with its private key: proof that it really holds the key matching the certificate.
- Derivation — each side combines its private share with the other’s public share and obtains the same secret, without it ever crossing the network. Since the DH keys are ephemeral, stealing the server’s private key later doesn’t decrypt past traffic: that’s forward secrecy.
- Symmetric session — all traffic switches to AES-GCM or ChaCha20-Poly1305, authenticated encryption: confidentiality and integrity in a single operation.
TLS 1.3 (2018) does all this in a single round trip (versus two for TLS 1.2) and purged the broken algorithms: RSA key exchange without forward secrecy, RC4, SHA-1.
Trust remains: a man-in-the-middle attacker can run a perfectly clean handshake… with his own certificate. Hence the CAs (Certificate Authorities): the server’s certificate is signed by an intermediate CA, itself signed by a root CA preinstalled in the OS or browser. The client walks this chain of trust up to a root it already knows; one invalid link and you get the red warning. Let’s Encrypt made certificates free and automated (ACME protocol, renewal every 90 days): no excuse left for serving cleartext HTTP.
🎤 In an interview — “Explain HTTPS to a beginner” is a classic. A version that works: “the padlock makes two promises. One: nobody can read or modify what’s in transit — that’s encryption. Two: you’re really talking to the site in the address bar — that’s the certificate, verified by a trusted third party. A sealed envelope, plus an ID card.” Two ideas, zero jargon.
Key concepts to master
- Encrypting vs signing: same key pair, opposite directions. Encrypt = the recipient’s public key (only they can decrypt). Sign = the sender’s private key over the message hash; anyone can verify with the public key. A signature proves author and integrity, it hides nothing.
- Hash ≠ encryption: a hash (SHA-256) is irreversible and keyless — you don’t “decrypt” a hash, you can only test candidates. Uses: integrity, signatures, password storage (via bcrypt/argon2, never a bare SHA).
- Certificate: a public key + an identity (the domain) + validity dates + a CA’s signature. Nothing secret inside — it’s a public document.
- Elliptic curves: the same guarantees as RSA with much shorter keys (EC 256 bits ≈ RSA 3072). Today’s standard: X25519 for key exchange, Ed25519/ECDSA for signatures.
- HTTPS everywhere: cleartext HTTP lets any intermediary (public Wi-Fi, ISP) read and modify pages — script injection included. The HSTS header forbids the browser from ever retrying HTTP.
All of it is easy to poke at with openssl:
# Generate an RSA pair: private (secret) then public
openssl genrsa -out priv.pem 2048
openssl rsa -in priv.pem -pubout -out pub.pem
# Encrypt with the recipient's PUBLIC key:
# only the private key holder can read
openssl pkeyutl -encrypt -pubin -inkey pub.pem \
-in msg.txt -out msg.enc
# Sign with your PRIVATE key (signed SHA-256 hash)…
openssl dgst -sha256 -sign priv.pem -out msg.sig msg.txt
# …and anyone verifies with the public key
openssl dgst -sha256 -verify pub.pem \
-signature msg.sig msg.txt # → Verified OK
# Inspect a real site's certificate and chain
openssl s_client -connect example.com:443 \
-servername example.com💡 Order of magnitude to remember — AES encrypts GB/s, RSA KB/s. That ~1000× factor is what forces the hybrid architecture: asymmetric crypto only opens the session, it never encrypts the stream.
In an interview
“Symmetric vs asymmetric — and why combine them?” — Symmetric: one shared key, very fast, but the key-exchange problem. Asymmetric: public/private pair, solves the exchange, but a thousand times slower. TLS combines them: asymmetric key exchange (ECDHE) to establish a common secret, then a symmetric session (AES) for the traffic. Best of both.
“Walk me through a TLS handshake.” — 1.3 version: ClientHello with an ephemeral DH share → ServerHello with its DH share, its certificate and a signature → both derive the same session key → traffic in AES-GCM. A single round trip. Bonus: mention forward secrecy thanks to the ephemeral keys.
“What is the certificate for, exactly?” — To authenticate the server, not to encrypt. It binds a public key to a domain, under the signature of a CA the client already knows (chain of trust). Without it, the encryption would work just as well… with an attacker in the middle.
“What’s the difference between encrypting and signing?” — Encrypting protects confidentiality: the recipient’s public key. Signing proves origin and integrity: the sender’s private key, verifiable by everyone. A signature does not hide the message.
“Why hash passwords instead of encrypting them?” — Encrypted = reversible for whoever has the key, and the key sits somewhere on the server. A slow, salted hash (bcrypt, argon2) cannot be decrypted: even the database admin can’t recover the password, only verify an attempt.
Pitfalls & misconceptions
⚠️ Golden rule — never implement your own crypto, and don’t even assemble the primitives yourself (ECB mode, reused IV, non-constant-time comparison… the traps are endless). In practice: TLS for transport, a battle-tested library (libsodium) for the rest.
- “The certificate encrypts the connection” — no: it authenticates. The session keys come from the Diffie-Hellman exchange; the certificate just guarantees you’re negotiating it with the right server.
- “HTTPS hides everything” — the content and the URL path, yes. But the visited domain leaks via the DNS query and the handshake’s SNI (ECH is being rolled out for the latter).
- “SSL” — the term survives in everyday speech (and in “openssl”), but SSL 2/3 have been dead and forbidden for years. The protocol is TLS, versions 1.2 and 1.3.
- Self-signed certificate in production — it encrypts, but proves nothing: clients have to click “accept the risk”, training them into exactly the wrong reflex. Keep it for local dev.
- MD5 and SHA-1 are broken for any security purpose (practical collisions). SHA-256 minimum.
Going further
- Cloudflare — What happens in a TLS handshake?: the handshake, properly popularized
- The Illustrated TLS 1.3 Connection: every byte of the handshake, annotated — spectacular
- Let’s Encrypt — How it works: the ACME protocol explained
- RFC 8446: the TLS 1.3 spec, skimmable
- badssl.com: a gallery of broken certificates to see browser errors for real