Échec de la négociation TLS dans PCAP : ClientHello, ServerHello, certificat, alerte et réinitialisation des preuves

Les échecs de négociation TLS sont souvent signalés sous la forme d'une « erreur SSL », d'un « problème de certificat », d'un « échec de la négociation » ou d'une « réinitialisation de la connexion ». Ces messages sont utiles, mais un PCAP peut montrer où la poignée de main s'est arrêtée. Cet emplacement compte.

Un échec TLS avant ServerHello est différent d'une alerte de validation de certificat. Une réinitialisation TCP après « ClientHello » est différente d'une alerte TLS fatale après un échange de certificat. La chronologie de capture de paquets peut identifier la limite.

Commencez par la connexion TCP

Avant de déboguer TLS, confirmez TCP :

• SYN
• SYN/ACK
• ACK
• données du client

Si TCP ne s’établit jamais, il ne s’agit pas d’un échec de négociation TLS. Il s'agit du routage, du pare-feu, du port, de l'accessibilité du serveur ou de la politique TCP.

Si TCP s'établit et que le client envoie « ClientHello », TLS démarre.

ClientHello montre ce que le client a proposé

ClientHello peut révéler :

• Versions TLS prises en charge
• suites de chiffrement proposées
• Nom d'hôte SNI
• Protocoles ALPN
• groupes pris en charge
• algorithmes de signature

Si SNI est manquant, le serveur peut renvoyer un certificat par défaut ou rejeter la négociation. Si le client ne propose que d'anciens protocoles ou chiffrements, le serveur peut répondre par un échec de négociation ou une réinitialisation.

C'est pourquoi les captures sont utiles pour les anciens clients intégrés, les proxys et les intégrations personnalisées.

ServerHello ou No ServerHello

Si le client envoie « ClientHello » et qu'aucun « ServerHello » n'arrive, inspectez :

• dépôt de pare-feu ou de middlebox
• la politique du serveur se ferme silencieusement
• Problème de MTU/chemin autour des messages de prise de contact volumineux
• TCP réinitialisé depuis le serveur
• comportement de l'équilibreur de charge

Si ServerHello arrive, inspectez la version et le chiffrement choisis. Le choix du serveur peut expliquer un échec ultérieur.

Les alertes sont des preuves, pas du bruit

Les alertes TLS peuvent être très informatives :

• autorité de certification inconnue
• mauvais certificat
• échec de la poignée de main
• version du protocole
• paramètre illégal
• fermer notifier

Une alerte fatale du client après la livraison du certificat indique souvent une chaîne de confiance, une incompatibilité de nom d'hôte, un certificat expiré ou des propriétés de certificat non prises en charge. Une alerte fatale du serveur après « ClientHello » peut pointer vers un chiffrement, un protocole, un SNI, un certificat client ou une politique.

Ne supprimez pas les alertes lors du découpage d’une capture.

La place de la chirurgie PCAP

PCAP Surgery devrait aider les ingénieurs à isoler la conversation TLS et à préserver les preuves de poignée de main. Une capture dérivée utile pour la prise en charge de TLS comprend :

• Prise de contact TCP
• ClientHello
• ServeurBonjour si présent
• messages de certificat si présents
• Alertes TLS
• TCP réinitialise
• timing entre les messages

Si la capture doit être désinfectée, soyez prudent. La suppression des détails du certificat, du SNI ou des longueurs de charge utile peut également supprimer la raison de l'échec. La décision de désinfection doit correspondre à l’objectif de dépannage.

Pour les requêtes de recherche telles que « Échec de la négociation TLS pcap », « ClientHello no ServerHello » ou « Alerte SSL inconnue CA Wireshark », la réponse se trouve dans la limite de la négociation. Un bon flux de travail de chirurgie par paquets préserve cette limite au lieu de la cacher.