Attaques TLS et défense

Prérequis : cours 8.1 et 8.2.

Pourquoi

TLS bien configuré aujourd'hui peut être attaquable demain (downgrade, mauvaise validation). Connaître les attaques classiques, c'est comprendre le pourquoi de chaque réglage — pas juste copier une config Mozilla.

Concepts

• MITM (Man-In-The-Middle) : l'attaquant entre client et serveur. Contre-mesures : vérification stricte du certificat + HSTS + certificate pinning (épingler le certificat attendu dans l'app mobile, pour les cas critiques).
• Downgrade (ex. POODLE, STRIPTLS) : forcer une version faible ou du HTTP. Contre-mesures : TLS min 1.2, HSTS (pas de retour HTTP possible), pas de fallback silencieux.
• ** stripping STARTTLS** (mail) : empêcher la montée en chiffrement. D'où : MTA-STS/DANE pour le mail sérieux — et la leçon générale : toute négociation « en clair d'abord » est attaquable.
• 5xx… non, les vraies failles : Heartbleed (lire la mémoire du serveur via une extension), clés faibles (1024 bits, ROBOT). Leçon : versions patchées (unattended-upgrades, cf. DevOps 8.1) + suites modernes uniquement.

Exemple : noter sa config (test externe régulier)

# Résumé : version min, HSTS, chaîne — via validateur externe type ssllabs.com
curl -sI https://example.com | grep -i "strict-transport"

Cas réel

curl -k laissé dans un script de supervision « parce que le cert interne n'était pas reconnu » : le monitoring lui-même devenu vulnérable au MITM — et surtout, il ne détectera jamais une expiration. Corriger la cause (CA interne déployée) plutôt que -k.

Pièges

• Copier une « config parfaite » de 2019 : les recommandations évoluent (suivre le guide Mozilla SSL actuel).
• Pinning sans plan de rotation : certificat renouvelé = app qui refuse de se connecter. Pinning = procédure de rotation avec.
• Croire TLS = sécurité : il chiffre le transport, pas l'app (injections, auth : inchangés derrière HTTPS).

À retenir

MITM → vérification + HSTS + pinning ; downgrade → versions min ; patchs + suites modernes ; TLS ≠ sécu applicative.