08. TLS 1.3 et limites du canal

Comprendre le mécanisme

TLS protège un canal avec négociation cryptographique et authentification selon le mode choisi. Un navigateur peut obtenir un canal authentifié vers un nom sans que chaque action applicative soit légitime. La terminaison TLS peut aussi se trouver avant l’application : le trajet interne et la confiance proxy doivent être décrits. Les clés de session et la clé privée du certificat ont des fonctions différentes.

Raisonner et vérifier

Les données précoces 0-RTT de TLS 1.3 présentent des contraintes de rejeu. Ne les traitez pas comme une garantie d’unicité pour une mutation sensible ; les politiques du serveur et du protocole applicatif doivent en tenir compte. Conservez des tests de validation de certificat et des erreurs de transport, puis testez séparément l’autorisation métier sur le canal établi.

Protection du trajet

TLS protège un canal selon un mode d’authentification. La protection du transport n’autorise pas les opérations. TLS protège les échanges entre ses deux terminaisons lorsque l’authentification et les paramètres sont corrects. Il ne remplace ni validation des entrées ni décision de permission sur une opération applicative.

Proxy et application

Une terminaison proxy sépare des trajets. Le trajet suivant demande sa propre configuration. Si TLS termine au reverse proxy, le trajet suivant possède sa propre configuration. Dessinez les deux connexions et vérifiez séparément chiffrement, authentification et réseau entre proxy et application.

Clés de rôles distincts

La clé de certificat et les clés de session ont des rôles différents. Négociation et identité utilisent des éléments distincts. La clé liée au certificat sert à l’authentification selon le protocole. Les secrets de trafic sont issus de l’établissement de session ; évitez de décrire TLS comme un simple chiffrement intégral par la clé du certificat.

Données précoces

Les données précoces 0-RTT demandent une analyse de rejeu. Le protocole prévoit des contraintes de rejeu spécifiques. Le 0-RTT de TLS 1.3 peut être rejoué dans certaines conditions. N’y admettez pas sans analyse une opération qui débite ou déclenche un effet non répétable ; gardez un contrôle applicatif adapté.

Identité attendue

Le client doit vérifier l’identité attendue. Le chiffrement sans confiance correcte ne suffit pas. Le client vérifie la chaîne et le nom de la destination. Un certificat valide pour un autre service ne suffit pas, même si la connexion chiffre effectivement les octets échangés.

Droits applicatifs

Une connexion valide peut porter une demande interdite. Le contrôle de droit reste serveur. Un attaquant peut utiliser HTTPS lui aussi. Contrôlez acteur et ressource pour chaque mutation ; la présence du cadenas ne prouve aucun droit sur la réservation demandée.

Échéance observée

L’expiration du certificat doit être surveillée. Le renouvellement relève d’un cycle d’exploitation. Surveillez le certificat réellement présenté depuis l’extérieur, avec marge avant expiration. Un nouveau fichier sur disque peut ne pas avoir été chargé par le service ou par tous ses nœuds.

Refus conservé

Les pannes de confiance doivent rester des refus. Le contournement supprime la garantie de pair attendu. Ne désactivez pas la validation de pair ou de nom pour contourner une panne. Corrigez chaîne, magasin de confiance ou destination puis testez que le service mal identifié reste refusé.

Tests séparés

Le test doit distinguer transport et métier. Le résultat métier ne décrit pas tous les contrôles de canal. Un test de connexion valide couvre un trajet de transport. Ajoutez des demandes autorisées et interdites sur le même canal pour établir les règles métier indépendamment de la réussite TLS.

Configuration versionnée

Les versions et paramètres font partie du périmètre. Il faut vérifier le service et les hypothèses réels. Inventoriez versions TLS, bibliothèques clientes et politiques de confiance. Un résultat obtenu avec un client récent ne décrit pas forcément un worker ancien ou une autre terminaison de la chaîne.

Atelier guidé : lire, expliquer et vérifier le code

// Extrait de configuration PHP cURL à analyser, non exécuté :
curl_setopt($handle, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($handle, CURLOPT_SSL_VERIFYHOST, 0);

Les deux options cURL de l’extrait désactivent les contrôles de chaîne et de nom. Elles peuvent rendre une connexion possible tout en retirant l’authentification attendue du serveur. Réparez le certificat ou le magasin de confiance dans un laboratoire, puis vérifiez qu’un certificat pour une autre destination reste refusé.

L’encodage ne constitue pas une vérification d’identité. Les options montrées désactivent précisément ces protections. Un nom de client ne vérifie pas le pair. La méthode HTTP ne restaure pas TLS.

Travail pratique : Dessinez une terminaison TLS locale et testez une requête non autorisée sur un canal valide. Étudiez la politique de données précoces du service.

Critères de correction : Le canal peut fonctionner tandis que l’action est refusée. Documentez l’activation ou le refus de 0-RTT et interdisez les conclusions d’unicité fondées uniquement sur TLS.