TLS côté app : versions, HSTS, certificats

Prérequis : cours précédent + Réseaux 8.1-8.2 (handshake, certificats).

Pourquoi

Côté app, TLS se résume à : exiger les bonnes versions, servir la bonne chaîne, forcer le HTTPS (HSTS) — et diagnostiquer quand ça casse. Ce cours = la checklist applicative.

Concepts

• Versions : TLS 1.2 minimum tolérable, 1.3 recommandé (cf. Réseaux 8.1). Côté app/node : minVersion: 'TLSv1.2' explicite, jamais de fallback silencieux.
• Chaîne servie : final + intermédiaires (pas la racine). Testée au mobile (pas au desktop qui cache !) ou validateur externe.
• HSTS : Strict-Transport-Security = plus jamais de HTTP. À activer quand le HTTPS est solide (sinon lock-out), avec includeSubDomains réfléchi.
• Certificats internes : CA privée déployée sur les clients (pas de -k/verify off qui devient permanent !).

Exemple : vérifier comme un client exigeant

curl --tlsv1.3 -sI https://app.fr | head -1          # 1.3 négocié ?
curl -sI https://app.fr | grep -i strict-transport    # HSTS présent ?

Cas réel

NODE_TLS_REJECT_UNAUTHORIZED=0 en prod « pour débugger le webhook interne » : resté 14 mois, MITM possible sur toutes les sorties HTTPS de l'app. L'équivalent du curl -k permanent : corriger la cause (CA déployée), jamais désactiver la vérification.

Pièges

• Désactiver la vérif « temporairement » : le temporaire dure (voir cas réel). Jamais en prod, même 5 minutes.
• HSTS sans monitoring d'expiration : certificat expiré + HSTS = site vraiment mort (pas de contournement possible).
• Oublier les clients non-navigateurs (applis mobiles, webhooks entrants) dans l'inventaire avant durcissement.

À retenir

1.2 min / 1.3 visé, chaîne testée au mobile, HSTS quand solide + expiration monitorée, jamais de -k.