Chapitre 1.3 - Cryptographie et securite reseau
Module 1 : Fondamentaux et paysage des menaces Niveau : Intermediaire a Avance | Temps de lecture estime : 55-70 min
Table des matieres
- Primitives cryptographiques - Les blocs de construction
- Chiffrement symetrique
- Chiffrement asymetrique et echange de cles
- Hachage et authentification de messages
- TLS - Comment internet chiffre reellement le trafic
- PKI - Infrastructure a cle publique
- Attaques cryptographiques et mauvaises configurations courantes
- Cryptographie pratique en ligne de commande
- Diagramme d'architecture
1. Primitives cryptographiques
La cryptographie en securite reseau repose sur un petit ensemble de primitives mathematiques. Chaque protocole - TLS, SSH, IPSec, PGP - est construit a partir de combinaisons de ces primitives. Comprendre ce que chacune garantit (et ce qu'elle ne garantit pas) est essentiel pour evaluer les conceptions de securite et identifier les faiblesses.
Les proprietes de securite fondamentales
| Propriete | Definition | Outil cryptographique |
|---|---|---|
| Confidentialite | Les donnees ne sont lisibles que par les parties concernees | Chiffrement symetrique/asymetrique |
| Integrite | Les donnees n'ont pas ete modifiees en transit | Fonctions de hachage, MAC, AEAD |
| Authentification | La partie communicante est bien celle qu'elle pretend etre | Signatures numeriques, certificats, HMAC |
| Non-repudiation | L'expediteur ne peut pas nier avoir envoye le message | Signatures numeriques (asymetriques) |
| Confidentialite persistante | Les sessions passees restent securisees si la cle a long terme est compromise | Echange de cles ephemeres (ECDHE, DHE) |
Le principe de Kerckhoffs
"Un cryptosysteme doit etre sur meme si tout ce qui concerne le systeme, sauf la cle, est de notoriete publique."
C'est fondamental. La securite par obscurcissement - cacher l'algorithme - n'est pas de la securite cryptographique. Tous les algorithmes cryptographiques en production (AES, RSA, ChaCha20) sont entierement publics. Leur securite provient entierement du secret de la cle.
Implication pour les defenseurs : Si vous evaluez un produit qui affirme que son algorithme de chiffrement est "proprietaire" pour des raisons de securite, traitez cela comme un signal d'alarme. La crypto proprietaire ne peut pas etre auditee et contient presque toujours des faiblesses.
2. Chiffrement symetrique
Le chiffrement symetrique utilise la meme cle pour le chiffrement et le dechiffrement. Il est rapide (accelere materiellement sur les processeurs modernes) et adapte au chiffrement de donnees en masse.
2.1 AES - Advanced Encryption Standard
AES est le chiffrement symetrique dominant utilise aujourd'hui. Il fonctionne comme un chiffrement par blocs (traite des blocs de 128 bits de taille fixe) avec des tailles de cle de 128, 192 ou 256 bits.
Modes de fonctionnement AES - le mode determine comment plusieurs blocs sont enchaines et si le chiffrement fournit de l'authentification :
| Mode | Nom complet | Auth ? | IV requis ? | Notes |
|---|---|---|---|---|
| ECB | Electronic Codebook | Non | Non | Ne jamais utiliser - texte clair identique -> texte chiffre identique, fuite de patterns |
| CBC | Cipher Block Chaining | Non | Oui | Largement utilise, vulnerable aux oracles de rembourrage si non authentifie |
| CTR | Counter Mode | Non | Oui (nonce) | Convertit le chiffrement par blocs en chiffrement par flot, parallelisable |
| GCM | Galois/Counter Mode | Oui (AEAD) | Oui (nonce) | Standard pour TLS 1.3, SSH - fournit confidentialite + integrite en un |
| CCM | Counter with CBC-MAC | Oui (AEAD) | Oui (nonce) | Utilise dans 802.11i (WPA2), IoT |
| ChaCha20-Poly1305 | - | Oui (AEAD) | Oui (nonce) | Alternative a AES-GCM, pas besoin d'acceleration materielle, utilise dans TLS 1.3 |
Pourquoi ECB est casse - le Pingouin ECB :
ECB chiffre chaque bloc independamment. Parce que le meme bloc de texte clair produit toujours le meme bloc de texte chiffre, les grandes regions uniformes (comme le fond d'une image de couleur unie) produisent des patterns de texte chiffre visuellement identiques. L'image chiffree du pingouin Tux Linux est l'exemple canonique - la forme du pingouin est entierement visible dans le texte chiffre.
Texte clair : [BLOC_A][BLOC_A][BLOC_B][BLOC_A]
ECB : [CHIF_A][CHIF_A][CHIF_B][CHIF_A] <- patterns preserves
CBC : [SOR_1 ][SOR_2 ][SOR_3 ][SOR_4 ] <- chaque bloc depend du precedent
2.2 AES-GCM en pratique
# Chiffrer un fichier avec AES-256-GCM en utilisant OpenSSL
openssl enc -aes-256-gcm \
-in texte_clair.txt \
-out chiffre.bin \
-K $(openssl rand -hex 32) \
-iv $(openssl rand -hex 12)
# Plus robuste : deriver la cle depuis une phrase secrete en utilisant PBKDF2
openssl enc -aes-256-cbc \
-in secret.txt \
-out secret.enc \
-pbkdf2 \
-iter 600000 \
-salt
# Dechiffrer
openssl enc -d -aes-256-cbc \
-in secret.enc \
-out secret_dechiffre.txt \
-pbkdf2 \
-iter 600000
# Generer une cle AES aleatoire cryptographiquement sure
openssl rand -hex 32 # Cle 256 bits (hex)
openssl rand -base64 32 # Cle 256 bits (base64)
# Python : AES-GCM avec PyCryptodome
python3 -c "
from Crypto.Cipher import AES
from Crypto.Random import get_random_bytes
import base64
key = get_random_bytes(32) # AES-256
nonce = get_random_bytes(12) # Nonce de 96 bits pour GCM
cipher = AES.new(key, AES.MODE_GCM, nonce=nonce)
ciphertext, tag = cipher.encrypt_and_digest(b'Message secret')
print('Cle : ', base64.b64encode(key).decode())
print('Nonce : ', base64.b64encode(nonce).decode())
print('Texte chiffre :', base64.b64encode(ciphertext).decode())
print('Tag auth : ', base64.b64encode(tag).decode())
# Le tag d'authentification prouve l'integrite - si le texte chiffre est altere, la verification echoue
"
2.3 Le probleme de distribution des cles
La faiblesse fondamentale du chiffrement symetrique est la distribution des cles. Si Alice et Bob veulent communiquer en toute securite :
- Ils doivent partager une cle secrete avant de pouvoir chiffrer quoi que ce soit
- S'ils la partagent via un canal non securise, un attaquant l'intercepte
- S'ils la partagent en personne, cela ne s'adapte pas a des millions de connexions TLS
Solution : Le chiffrement asymetrique (section suivante) resout la distribution des cles. En pratique, la crypto asymetrique est utilisee pour echanger de maniere securisee une cle symetrique, puis la crypto symetrique chiffre les donnees reelles (cryptographie hybride - ce que fait TLS).
3. Chiffrement asymetrique et echange de cles
La cryptographie asymetrique utilise une paire de cles mathematiquement liee : une cle publique (partageable avec tout le monde) et une cle privee (gardee secrete). Ce que la cle publique chiffre, seule la cle privee peut le dechiffrer - et vice versa.
3.1 RSA
RSA est l'algorithme asymetrique le plus largement deploye. Sa securite repose sur la difficulte de factoriser le produit de deux grands nombres premiers.
Tailles de cles et equivalence de securite :
| Taille de cle RSA | Equivalent symetrique | Statut |
|---|---|---|
| 1024 bits | ~80 bits symetriques | Casse - NIST deprecie en 2010 |
| 2048 bits | ~112 bits symetriques | Minimum acceptable, abandonne d'ici 2030 |
| 3072 bits | ~128 bits symetriques | Recommande actuellement |
| 4096 bits | ~140 bits symetriques | Haute securite, plus lent |
Operations RSA :
# Generer une paire de cles RSA-4096
openssl genrsa -out privee.pem 4096
# Extraire la cle publique depuis la cle privee
openssl rsa -in privee.pem -pubout -out publique.pem
# Chiffrer un fichier en utilisant la cle publique RSA (pour petites donnees uniquement - ex. cle symetrique)
openssl rsautl -encrypt \
-inkey publique.pem \
-pubin \
-in cle_symetrique.bin \
-out cle_symetrique.enc \
-oaep # Utiliser le rembourrage OAEP - ne jamais utiliser PKCS#1 v1.5 (attaques oracle)
# Dechiffrer
openssl rsautl -decrypt \
-inkey privee.pem \
-in cle_symetrique.enc \
-out cle_symetrique_dechiffree.bin \
-oaep
# Signer un fichier avec la cle privee (cree une signature)
openssl dgst -sha256 -sign privee.pem -out signature.bin document.pdf
# Verifier la signature avec la cle publique
openssl dgst -sha256 -verify publique.pem -signature signature.bin document.pdf
# Sortie : "Verified OK" ou "Verification Failure"
# Inspecter la cle RSA
openssl rsa -in privee.pem -text -noout | head -20
Faiblesses RSA a connaitre :
- Rembourrage PKCS#1 v1.5 - vulnerable a l'attaque oracle de rembourrage de Bleichenbacher (1998, toujours exploitee dans l'attaque ROBOT 2017). Toujours utiliser OAEP.
- Attaques a petit exposant - utiliser e=3 avec des messages non rembourres permet des attaques par racine cubique
- Pas de confidentialite persistante - si la cle privee du serveur est compromise, toutes les sessions passees sont dechiffrables (resolu par l'echange de cles ephemeres)
3.2 Cryptographie a courbes elliptiques (ECC)
ECC fournit une securite equivalente a RSA avec des longueurs de cle dramatiquement plus courtes, en exploitant la difficulte du probleme du logarithme discret sur les courbes elliptiques (ECDLP).
Comparaison de taille :
| Niveau de securite | Taille de cle RSA | Taille de cle ECC |
|---|---|---|
| 128 bits | 3072 bits | 256 bits (P-256 / secp256r1) |
| 192 bits | 7680 bits | 384 bits (P-384 / secp384r1) |
| 256 bits | 15360 bits | 521 bits (P-521 / secp521r1) |
Les cles plus petites d'ECC signifient des poignees de main plus rapides, moins de bande passante et une utilisation CPU reduite - critique pour les performances TLS a grande echelle et les systemes IoT/embarques.
# Generer une paire de cles EC (courbe P-256 - courante pour TLS)
openssl ecparam -name prime256v1 -genkey -noout -out ec_privee.pem
# Extraire la cle publique
openssl ec -in ec_privee.pem -pubout -out ec_publique.pem
# Voir les parametres de cle
openssl ec -in ec_privee.pem -text -noout
# Lister les courbes disponibles
openssl ecparam -list_curves | grep -E "prime|secp|brainpool"
Notes de securite des courbes :
- P-256 (secp256r1 / prime256v1) : Courbe NIST, largement deployee, preoccupations concernant une porte derobee NIST (non prouvee)
- Curve25519 : Courbe de Bernstein, concue pour etre immune a plusieurs classes d'attaques, utilisee dans TLS/SSH modernes (X25519 pour l'echange de cles, Ed25519 pour les signatures)
- secp256k1 : Courbe de Bitcoin - non recommandee pour TLS general
3.3 Echange de cles Diffie-Hellman et ECDHE
DH permet a deux parties d'etablir un secret partage sur un canal non securise sans transmettre le secret. ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) est la norme moderne.
Flux conceptuel ECDHE :
Alice Bob
----- ----
Generer une paire de cles EC ephemeres Generer une paire de cles EC ephemeres
(a_priv, a_pub) (b_priv, b_pub)
Envoyer a_pub ──────────────────> Recevoir a_pub
Recevoir b_pub <──────────────── Envoyer b_pub
Calculer partage = a_priv * b_pub Calculer partage = b_priv * a_pub
[Meme resultat grace aux maths des courbes elliptiques]
Deriver les cles de session depuis le secret partage
Les deux cotes ont des cles de session identiques sans les avoir jamais transmises
"Ephemere" signifie qu'une nouvelle paire de cles est generee pour chaque session. Meme si la cle privee a long terme du serveur est ulterieurementt volee, les sessions passees ne peuvent pas etre dechiffrees - c'est la confidentialite persistante (PFS).
4. Hachage et authentification de messages
4.1 Fonctions de hachage cryptographiques
Une fonction de hachage cryptographique produit un condens de taille fixe depuis une entree arbitraire. Proprietes requises :
- Deterministe : Meme entree -> toujours meme sortie
- Unidirectionnel (resistance a la preimage) : Etant donne H(x), infaisable de trouver x
- Resistance aux collisions : Infaisable de trouver x != y ou H(x) = H(y)
- Effet avalanche : Petit changement dans l'entree -> sortie completement differente
| Algorithme | Taille de sortie | Statut | Utilisation |
|---|---|---|---|
| MD5 | 128 bits | Casse - collisions triviales | Compatibilite heritee uniquement, jamais pour la securite |
| SHA-1 | 160 bits | Casse - SHAttered 2017 | Depreciee dans TLS/signature de code |
| SHA-256 | 256 bits | Sur | TLS, signature de code, commits git |
| SHA-384 | 384 bits | Sur | NSA Suite B, usage gouvernemental |
| SHA-512 | 512 bits | Sur | Hachage haute securite |
| SHA-3 (Keccak) | Variable | Sur | Norme NIST, conception differente |
| BLAKE2 | Variable | Sur | Plus rapide que SHA-2, utilise dans WireGuard |
| bcrypt | 184 bits | Sur | Hachage de mots de passe (lent par conception) |
| Argon2 | Variable | Sur | Hachage de mots de passe, gagnant PHC |
# Hacher un fichier avec plusieurs algorithmes pour comparaison
sha256sum /bin/ls
sha512sum /bin/ls
md5sum /bin/ls # Uniquement pour la verification de compatibilite heritee
# Python : demonstrer l'effet avalanche
python3 -c "
import hashlib
msg1 = b'Bonjour, Monde !'
msg2 = b'Bonjour, Monde.' # Seulement le '!' change en '.'
h1 = hashlib.sha256(msg1).hexdigest()
h2 = hashlib.sha256(msg2).hexdigest()
print(f'Hachage message 1 : {h1}')
print(f'Hachage message 2 : {h2}')
# Compter les bits differents
diff = bin(int(h1, 16) ^ int(h2, 16)).count('1')
print(f'Bits differents : {diff}/256 ({diff/256*100:.1f}%)')
# Attendu : ~50% des bits different malgre un changement d\'1 caractere
"
# Verifier l'integrite d'un fichier en utilisant la somme de controle
sha256sum -c checksums.sha256
# Creer des sommes de controle pour un repertoire
find /opt/app -type f -exec sha256sum {} \; > app_checksums.sha256
4.2 HMAC - Code d'authentification de message base sur le hachage
Un simple hachage n'authentifie pas l'expediteur - n'importe qui peut hacher un message. HMAC utilise une cle secrete partagee combinee avec la fonction de hachage pour produire un Code d'Authentification de Message qui prouve a la fois l'integrite et l'authenticite.
HMAC(cle, message) = Hachage((cle XOR opad) || Hachage((cle XOR ipad) || message))
import hmac, hashlib, os
# Generer un secret partage (serait echange de maniere securisee en pratique)
cle_secrete = os.urandom(32) # Cle 256 bits
message = b"Transferer 10 000 EUR vers le compte 12345"
# Calculer HMAC-SHA256
mac = hmac.new(cle_secrete, message, hashlib.sha256).hexdigest()
print(f"HMAC : {mac}")
# Verifier (comparaison en temps constant previent les attaques de timing)
def verifier_hmac(cle, message, mac_recu):
calcule = hmac.new(cle, message, hashlib.sha256).hexdigest()
# hmac.compare_digest est sur en termes de timing
return hmac.compare_digest(calcule, mac_recu)
# Si l'attaquant modifie le message, la verification HMAC echoue
altere = b"Transferer 10 000 EUR vers le compte 99999"
print(verifier_hmac(cle_secrete, altere, mac)) # False
print(verifier_hmac(cle_secrete, message, mac)) # True
Critique : Ne jamais utiliser == pour comparer les HMACs - utiliser hmac.compare_digest(). Une simple comparaison de chaines fuit des informations de timing : elle retourne plus vite quand les premiers octets correspondent, permettant a un attaquant de forcer le HMAC octet par octet.
4.3 Hachage de mots de passe
Le stockage des mots de passe necessite des fonctions de hachage lentes avec salage. Les hachages rapides (SHA-256) peuvent etre forces a raison de milliards de hachages par seconde sur les GPU modernes.
# Generer un hachage bcrypt (Python)
python3 -c "
import bcrypt
mot_de_passe = b'MotDePasseSecurise123!'
# Hacher avec bcrypt (facteur de travail 12 = 2^12 iterations)
hache = bcrypt.hashpw(mot_de_passe, bcrypt.gensalt(rounds=12))
print(f'Hachage bcrypt : {hache.decode()}')
# Verifier
print(bcrypt.checkpw(mot_de_passe, hache)) # True
print(bcrypt.checkpw(b'MauvaisMotDePasse', hache)) # False
"
# Argon2 (gagnant PHC, recommande pour les nouveaux systemes)
python3 -c "
from argon2 import PasswordHasher
ph = PasswordHasher(
time_cost=3, # Nombre d'iterations
memory_cost=65536, # 64 Mo de memoire (rend les attaques GPU couteuses)
parallelism=2 # Threads
)
hash = ph.hash('MotDePasseSecurise123!')
print(f'Hachage Argon2 : {hash}')
try:
ph.verify(hash, 'MotDePasseSecurise123!')
print('Mot de passe valide')
except:
print('Mot de passe invalide')
"
# Verifier la vitesse de hachage des mots de passe (moins = mieux pour les defenseurs)
# bcrypt au cout 12 : ~250ms par hachage -> 4 tentatives/sec
# SHA-256 : ~0.00001ms par hachage -> 10 milliards de tentatives/sec (GPU)
# Le ratio 10 milliards contre 4 explique pourquoi bcrypt/Argon2 est important
5. TLS - Comment internet chiffre reellement le trafic
TLS (Transport Layer Security) est le protocole qui chiffre la grande majorite du trafic internet. Comprendre ses mecanismes internes est essentiel pour identifier les mauvaises configurations, intercepter le trafic dans des contextes autorises, et comprendre exactement ce qu'il protege et ce qu'il ne protege pas.
5.1 Poignee de main TLS 1.3 (Norme moderne)
TLS 1.3 (RFC 8446, 2018) a reduit la poignee de main de 2 allers-retours (TLS 1.2) a 1 aller-retour, supprime toutes les suites de chiffrement heritees, et mandate la confidentialite persistante.
Client Serveur
------ -------
1. ClientHello
├── Version TLS : 1.3
├── Nonce aleatoire (32 octets)
├── Suites de chiffrement supportees :
│ TLS_AES_256_GCM_SHA384
│ TLS_CHACHA20_POLY1305_SHA256
│ TLS_AES_128_GCM_SHA256
└── Partage de cle (cle publique ECDHE, ex. X25519)
─────────────────────────────────────────────────────────>
2. ServerHello
├── Suite de chiffrement selectionnee
├── Cle publique ECDHE du serveur
└── [Les deux cotes calculent le secret partage]
├── {ExtensionsChiffrees}
├── {Certificat}
├── {VerifCertificat} <- signe avec la cle privee serveur
└── {Termine} <- HMAC de la transcription de poignee de main
<─────────────────────────────────────────────────────────
3. Le client verifie la chaine de certificats
Le client envoie {Termine}
─────────────────────────────────────────────────────────>
[Donnees applicatives chiffrees avec AES-256-GCM ou ChaCha20-Poly1305]
Ameliorations cles de TLS 1.3 vs 1.2 :
- Confidentialite persistante obligatoire - seul l'echange de cles ECDHE/DHE autorise (RSA statique supprime)
- Moins de suites de chiffrement - algorithmes herites supprimes (RC4, 3DES, mode CBC, MD5)
- Reprise 0-RTT - pour les connexions repetees (avec mises en garde sur les attaques par rejeu)
- Poignee de main plus chiffree - le certificat est chiffre dans TLS 1.3 (etait en texte clair dans 1.2)
5.2 Anatomie d'une suite de chiffrement
Une suite de chiffrement specifie quels algorithmes sont utilises pour chaque fonction cryptographique dans TLS :
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
│ │ │ │ │ │ │
│ │ │ │ │ │ └── Hachage PRF/HMAC : SHA-384
│ │ │ │ │ └────── Mode : GCM (AEAD)
│ │ │ │ └─────────── Taille de cle : 256 bits
│ │ │ └──────────────── Chiffrement symetrique : AES
│ │ └──────────────────────── Auth/Signature : cert RSA
│ └─────────────────────────────── Echange de cles : ECDHE (ephemere)
└──────────────────────────────────── Protocole : TLS
Forme simplifiee TLS 1.3 (echange de cles toujours ephemere, implicite) :
TLS_AES_256_GCM_SHA384
│ │ │ │
│ │ │ └── Hachage pour la derivation de cle HKDF
│ │ └────── Mode : GCM (AEAD)
│ └─────────── Taille de cle : 256 bits
└──────────────── Chiffrement symetrique : AES
5.3 Inspection de la configuration TLS
# Inspection TLS complete avec OpenSSL
openssl s_client -connect target.com:443 \
-tls1_3 \
-showcerts \
-servername target.com
# Verifier quelles suites de chiffrement un serveur supporte (avec nmap)
nmap --script ssl-enum-ciphers -p 443 target.com
# Verifier les suites de chiffrement faibles avec testssl.sh (complet)
./testssl.sh --severity HIGH --color 3 https://target.com
# Verifier l'expiration du certificat
echo | openssl s_client -connect target.com:443 2>/dev/null | \
openssl x509 -noout -dates
# Verifier le support TLS 1.0/1.1 depreciee (doit retourner une erreur sur les serveurs durcis)
openssl s_client -connect target.com:443 -tls1 # TLS 1.0
openssl s_client -connect target.com:443 -tls1_1 # TLS 1.1
# Extraire et inspecter le certificat serveur
echo | openssl s_client -connect target.com:443 2>/dev/null | \
openssl x509 -noout -text | grep -A5 "Subject:\|Issuer:\|Validity\|Subject Alternative"
# Verifier l'en-tete HSTS (HTTP Strict Transport Security)
curl -sI https://target.com | grep -i strict-transport
# Verifier l'agrafage OCSP
openssl s_client -connect target.com:443 -status 2>/dev/null | grep -A5 "OCSP response"
5.4 Configuration de securite TLS (Nginx / Apache)
# Nginx : configuration TLS durcie
server {
listen 443 ssl http2;
server_name target.com;
ssl_certificate /etc/ssl/certs/target.com.crt;
ssl_certificate_key /etc/ssl/private/target.com.key;
# Versions TLS : desactiver 1.0 et 1.1
ssl_protocols TLSv1.2 TLSv1.3;
# Suites de chiffrement : les suites TLS 1.3 sont automatiques ; celles-ci s'appliquent a TLS 1.2
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
ssl_prefer_server_ciphers off;
# Preference de courbe ECDHE
ssl_ecdh_curve X25519:prime256v1:secp384r1;
# Reprise de session (performance, avec mises en garde sur la confidentialite persistante)
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;
# HSTS : forcer HTTPS pendant 1 an, inclure les sous-domaines, autoriser le preloading
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
# Agrafage OCSP - le serveur recupere et met en cache la reponse OCSP
ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;
# Transparence des certificats
add_header Expect-CT "max-age=86400, enforce";
}
6. PKI - Infrastructure a cle publique
La PKI est le systeme de confiance qui fait fonctionner TLS a l'echelle internet. Elle repond a la question : comment sais-je que cette cle publique appartient reellement a google.com ?
6.1 La chaine de confiance des certificats
AC racine (auto-signee, dans le magasin de confiance OS/navigateur)
| Signe v
AC intermediaire (emise par l'AC racine)
| Signe v
Certificat serveur (emis par l'AC intermediaire, contient la cle publique du serveur)
|
└── Sujet : CN=target.com
SAN : DNS:target.com, DNS:www.target.com
Cle publique : [cle publique du serveur]
Signature : [signee par la cle privee de l'AC intermediaire]
Pourquoi des intermediaires ? Les cles privees des AC racines sont stockees hors ligne dans des HSM (modules de securite materiels) dans des coffres physiques. Elles signent les AC intermediaires, puis se deconnectent. Si une AC intermediaire est compromise, elle peut etre revoquee sans remplacer l'AC racine incorporee dans tous les magasins de confiance OS/navigateur.
6.2 Champs de certificat critiques pour la securite
# Inspecter le certificat en detail
openssl x509 -in cert.pem -text -noout
# Champs cles a examiner :
# Subject - a qui le cert a ete emis
# Issuer - qui a signe le cert
# Validity - NotBefore, NotAfter (verifier l'expiration)
# SubjectAltName (SAN) - tous les noms d'hotes pour lesquels ce cert est valide
# KeyUsage - quelles operations sont autorisees (Signature numerique, Chiffrement de cle)
# ExtendedKeyUsage - Authentification serveur web TLS
# BasicConstraints - CA:TRUE signifie qu'il peut signer d'autres certs (dangereux si inattendu)
# CRL Distribution Points - ou verifier si le cert est revoque
# OCSP (AuthorityInfoAccess) - verification de revocation en temps reel
# Exemple : trouver tous les SAN sur un certificat
echo | openssl s_client -connect target.com:443 2>/dev/null | \
openssl x509 -noout -text | grep -A1 "Subject Alternative"
6.3 Transparence des certificats (CT)
CT est un journal public en ajout seul de tous les certificats jamais emis. Tout certificat ne figurant pas dans un journal CT est rejete par Chrome/Firefox. Cela permet de detecter :
- Les certificats mal emis (compromission AC, detournement BGP + demande de cert frauduleuse)
- Les certificats non autorises pour votre domaine
- L'IT fantome - certificats emis pour des sous-domaines que vous ne saviez pas exister
# Surveiller les journaux CT pour votre domaine en utilisant crt.sh
curl -s 'https://crt.sh/?q=%.votredomaine.com&output=json' | \
python3 -c "
import sys, json
certs = json.load(sys.stdin)
for c in certs:
print(f\"{c['not_before'][:10]} {c['name_value']}\")
" | sort -u
# Surveillance automatisee : certspotter (open source)
go install software.sslmate.com/src/certspotter/cmd/certspotter@latest
certspotter -watchlist domaines.txt -script alerte.sh
6.4 Revocation de certificat
Si une cle privee est compromise, le certificat doit etre revoque. Deux mecanismes existent :
| Mecanisme | Fonctionnement | Faiblesse |
|---|---|---|
| CRL (Liste de revocation de certificats) | L'AC publie une liste de numeros de serie revoques | Fichiers enormes, mis en cache pendant des jours - revocation retardee |
| OCSP (Protocole de statut de certificat en ligne) | Requete en temps reel au repondeur OCSP de l'AC | Confidentialite (l'AC voit chaque site visite), le repondeur OCSP peut etre attaque par DoS |
| Agrafage OCSP | Le serveur recupere et agrafe la reponse OCSP a la poignee de main TLS | Resout le probleme de confidentialite, le serveur doit se rafraichir periodiquement |
Le probleme de l'echec en douceur : La plupart des navigateurs implementent OCSP avec un "echec en douceur" - si le repondeur OCSP est inaccessible, le navigateur accepte quand meme le certificat. Un attaquant qui vole une cle privee peut bloquer le repondeur OCSP pour empecher l'application de la revocation.
7. Attaques cryptographiques et mauvaises configurations courantes
7.1 Suppression SSL
La suppression SSL degrade une connexion HTTPS en HTTP en interceptant la requete HTTP initiale avant la redirection vers HTTPS.
Flux normal :
L'utilisateur tape : http://banque.com
Navigateur -> HTTP GET / -> Serveur -> Redirection 301 vers https://banque.com
Navigateur -> connexion HTTPS etablie
Suppression SSL (Moxie Marlinspike, 2009) :
L'utilisateur tape : http://banque.com
Navigateur -> HTTP GET / -> [L'attaquant intercepte]
Attaquant -> connexion HTTPS -> banque.com (l'attaquant voit le texte clair)
Attaquant -> reponse HTTP -> Navigateur (la victime croit etre en HTTP)
Tout le trafic : Banque <HTTPS> Attaquant <HTTP> Victime
# Suppression SSL avec mitmproxy (tests autorises uniquement)
mitmproxy --mode transparent --ssl-insecure
# Detection : verifier si le site envoie l'en-tete HSTS
curl -sI http://banque.com | grep -i "strict-transport"
# Sans HSTS : vulnerable a la suppression SSL
# Avec HSTS max-age=31536000 : le navigateur refuse HTTP pendant 1 an
# Preloading HSTS : protection ultime
# Les domaines soumis a https://hstspreload.org sont codes en dur dans les navigateurs
# Le navigateur ne tentera JAMAIS le HTTP, meme lors de la premiere visite
7.2 Epinglage de certificat et contournement
L'epinglage de certificat incorpore un certificat specifique ou un hachage de cle publique dans une application, rejetant tout autre cert meme s'il est signe par une AC de confiance.
# Verification d'epinglage : en-tete HPKP (depreciee dans les navigateurs, toujours utilisee dans les apps mobiles)
# Public-Key-Pins: pin-sha256="base64hash"; max-age=5184000; includeSubDomains
# Tentatives de contournement lors des tests d'applications mobiles :
# 1. Crochet Frida (instrumentation dynamique)
# Patcher SSLContext.checkServerTrusted() a l'execution
frida -U -l ssl_pinning_bypass.js com.target.app
# 2. objection (construit sur Frida)
objection -g com.target.app explore
# ios sslpinning disable
# android sslpinning disable
# 3. Verifier les epingles de certificat dans l'APK
apktool d target.apk
grep -r "sha256\|pin\|certificate" target/res/xml/network_security_config.xml
7.3 POODLE, BEAST, CRIME, BREACH, ROBOT
Ce sont toutes des attaques cryptographiques contre TLS :
| Attaque | Annee | Cible | Mecanisme | Attenuation |
|---|---|---|---|---|
| BEAST | 2011 | TLS 1.0 CBC | Prediction IV en mode CBC | Desactiver TLS 1.0 |
| CRIME | 2012 | Compression TLS | Oracle de compression fuit les secrets | Desactiver la compression TLS |
| BREACH | 2013 | Compression HTTP | Similaire a CRIME mais niveau HTTP | Desactiver la compression HTTP pour les donnees secretes |
| POODLE | 2014 | SSLv3 CBC | Oracle de rembourrage via degradation SSLv3 | Desactiver SSLv3/TLS 1.0/1.1 |
| FREAK | 2015 | Suite de chiffrement export RSA | Degradation vers RSA 512 bits | Supprimer les suites de chiffrement export |
| Logjam | 2015 | Echange de cles DHE | Degradation vers DH 512 bits | Utiliser DHE 2048 bits ou ECDHE |
| DROWN | 2016 | Cross-protocole SSLv2 | Oracle SSLv2 sur cles partagees | Desactiver SSLv2, ne pas reutiliser les cles |
| ROBOT | 2017 | RSA PKCS#1 v1.5 | Oracle Bleichenbacher ressurgit | Utiliser RSA-OAEP ou privilegier ECDHE |
| RACCOON | 2020 | Timing DHE | Oracle de timing dans le pre-secret DH | Desactiver DHE, utiliser ECDHE uniquement |
7.4 Mauvaises configurations cryptographiques courantes
# 1. Verification des suites de chiffrement faibles
nmap --script ssl-enum-ciphers -p 443 target.com | grep -E "WEAK|DES|RC4|export|anon"
# 2. Detection de certificat auto-signe
echo | openssl s_client -connect target.com:443 2>/dev/null | \
openssl x509 -noout -issuer -subject | \
awk '{if($0 ~ /issuer/ && $0 ~ /subject/) print "AUTO-SIGNE"}'
# 3. Verification de certificat expire
openssl x509 -enddate -noout -in cert.pem | \
python3 -c "
import sys, datetime
ligne = sys.stdin.read().strip()
date_str = ligne.split('=')[1]
expiry = datetime.datetime.strptime(date_str, '%b %d %H:%M:%S %Y %Z')
jours_restants = (expiry - datetime.datetime.utcnow()).days
print(f'Expire : {expiry} ({jours_restants} jours restants)')
if jours_restants < 30:
print('AVERTISSEMENT : Certificat bientot expire !')
if jours_restants < 0:
print('CRITIQUE : Certificat EXPIRE !')
"
# 4. Verification des parametres DH faibles (Logjam)
openssl s_client -connect target.com:443 2>/dev/null | grep "Server Temp Key"
# Chercher : "Server Temp Key: DH, 1024 bits" = VULNERABLE
# Bon : "Server Temp Key: X25519, 253 bits" ou "ECDH, P-256, 256 bits"
# 5. Verification TLS 1.0/1.1 active
for v in tls1 tls1_1; do
result=$(echo | openssl s_client -connect target.com:443 -$v 2>&1)
if echo "$result" | grep -q "Cipher is"; then
echo "$v : ACTIVE (devrait etre desactive)"
else
echo "$v : Desactive (bien)"
fi
done
8. Cryptographie pratique en ligne de commande
8.1 GPG pour le chiffrement et la signature de fichiers
# Generer une paire de cles GPG
gpg --full-generate-key
# Choisir : RSA et RSA, 4096 bits, expiration, nom/email
# Lister les cles
gpg --list-keys
gpg --list-secret-keys
# Exporter la cle publique (partager avec les autres)
gpg --export --armor analyste@entreprise.com > analyste_publique.asc
# Importer la cle publique de quelqu'un d'autre
gpg --import leur_publique.asc
# Chiffrer un fichier pour un destinataire
gpg --encrypt --armor --recipient destinataire@entreprise.com secret.txt
# Produit : secret.txt.asc (chiffre, seul le destinataire peut dechiffrer)
# Dechiffrer
gpg --decrypt secret.txt.asc > secret_dechiffre.txt
# Signer un fichier (prouve l'authenticite)
gpg --detach-sign --armor document.pdf
# Produit : document.pdf.asc (fichier de signature)
# Verifier la signature
gpg --verify document.pdf.asc document.pdf
# Chiffrer ET signer en une seule etape
gpg --encrypt --sign --armor \
--recipient destinataire@entreprise.com \
--local-user analyste@entreprise.com \
rapport_sensible.pdf
8.2 OpenSSL - Le couteau suisse
# Generer une demande de signature de certificat (CSR) pour un nouveau certificat
openssl req -new -newkey rsa:4096 -nodes \
-keyout serveur.key \
-out serveur.csr \
-subj "/C=FR/ST=Ile-de-France/O=Entreprise/CN=target.com" \
-addext "subjectAltName=DNS:target.com,DNS:www.target.com,DNS:api.target.com"
# Creer un cert auto-signe (pour les tests uniquement)
openssl req -x509 -newkey rsa:4096 -days 365 -nodes \
-keyout auto_signe.key \
-out auto_signe.crt \
-subj "/CN=localhost"
# Convertir PEM en PKCS#12 (pour importer dans les magasins de cles Windows/Java)
openssl pkcs12 -export \
-out certificat.p12 \
-inkey serveur.key \
-in serveur.crt \
-certfile chaine_ca.crt
# Convertir PKCS#12 en PEM
openssl pkcs12 -in certificat.p12 -out serveur.pem -nodes
# Tester une poignee de main TLS et mesurer la latence
time echo | openssl s_client -connect target.com:443 -tls1_3 2>/dev/null | grep "Protocol\|Cipher"
# Decoder un token JWT base64 pour inspecter les revendications (sans verification)
echo "eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJ1c2VyMTIzIn0.SIGNATURE" | \
cut -d. -f2 | \
base64 -d 2>/dev/null | python3 -m json.tool
8.3 WireShark / tcpdump - Validation du chiffrement
# Capturer le trafic TLS et verifier qu'il est chiffre
tcpdump -i eth0 -w capture.pcap 'tcp port 443' &
curl -s https://target.com > /dev/null
pkill tcpdump
# Inspecter avec tshark - doit voir des donnees applicatives chiffrees, pas du texte clair
tshark -r capture.pcap -Y "tls" -T fields \
-e tls.record.content_type \
-e tls.handshake.type \
-e tls.app_data
# Dechiffrer TLS avec SSLKEYLOGFILE (export du pre-secret maitre du navigateur/curl)
# Dans votre shell avant d'executer curl :
export SSLKEYLOGFILE=/tmp/cles_tls.log
curl https://target.com > /dev/null
# Wireshark peut maintenant dechiffrer : Edition -> Preferences -> TLS -> Fichier log des secrets
# Dechiffrement tshark :
tshark -r capture.pcap \
-o "tls.keylog_file:/tmp/cles_tls.log" \
-Y "http" \
-T fields -e http.request.uri
# C'est ainsi que fonctionne l'inspection TLS d'entreprise / break-and-inspect a grande echelle