TLS-Handshake-Fehler in PCAP: ClientHello, ServerHello, Zertifikat, Warnung und Rücksetznachweis

So diagnostizieren Sie TLS-Handshake-Fehler bei Paketerfassungen durch Lesen von ClientHello-, ServerHello-, Zertifikat-, Warn- und TCP-Reset-Beweisen.

PCAP, TLS, SSL, Handshake, ClientHello

TLS-Handshake-Fehler werden oft als „SSL-Fehler“, „Zertifikatproblem“, „Handshake fehlgeschlagen“ oder „Verbindung zurückgesetzt“ gemeldet. Diese Nachrichten sind nützlich, aber ein PCAP kann zeigen, wo der Handshake aufgehört hat. Dieser Standort ist wichtig.

Ein TLS-Fehler vor „ServerHello“ unterscheidet sich von einer Zertifikatsvalidierungswarnung. Ein TCP-Reset nach „ClientHello“ unterscheidet sich von einer schwerwiegenden TLS-Warnung nach einem Zertifikatsaustausch. Die Paketerfassungszeitleiste kann die Grenze identifizieren.

Beginnen Sie mit der TCP-Verbindung

Bestätigen Sie vor dem Debuggen von TLS TCP:

  • SYN
  • SYN/ACK
  • ACK
  • Daten vom Kunden

Wenn sich TCP nie aufbaut, handelt es sich nicht um einen TLS-Handshake-Fehler. Dabei handelt es sich um Routing, Firewall, Port, Servererreichbarkeit oder TCP-Richtlinie.

Wenn TCP etabliert ist und der Client „ClientHello“ sendet, beginnt TLS.

ClientHello zeigt, was der Kunde angeboten hat

„ClientHello“ kann Folgendes enthüllen:

  • Unterstützte TLS-Versionen
  • Cipher-Suites angeboten
  • SNI-Hostname
  • ALPN-Protokolle
  • unterstützte Gruppen
  • Signaturalgorithmen

Wenn SNI fehlt, gibt der Server möglicherweise ein Standardzertifikat zurück oder lehnt den Handshake ab. Wenn der Client nur alte Protokolle oder Verschlüsselungen anbietet, antwortet der Server möglicherweise mit einem Handshake-Fehler oder einem Reset.

Aus diesem Grund sind Erfassungen für alte eingebettete Clients, Proxys und benutzerdefinierte Integrationen nützlich.

ServerHello oder Nein ServerHello

Wenn der Client „ClientHello“ sendet und nie „ServerHello“ eintrifft, überprüfen Sie Folgendes:

  • Firewall- oder Middlebox-Drop
  • Serverrichtlinie wird stillschweigend geschlossen
  • MTU-/Pfadproblem bei großen Handshake-Nachrichten
  • TCP vom Server zurückgesetzt
  • Load-Balancer-Verhalten

Wenn „ServerHello“ eintrifft, überprüfen Sie die ausgewählte Version und Verschlüsselung. Die Wahl des Servers kann einen späteren Ausfall erklären.

Warnungen sind Beweise, kein Lärm

TLS-Benachrichtigungen können sehr informativ sein:

  • unbekannte CA
  • schlechtes Zertifikat
  • Handshake-Fehler
  • Protokollversion
  • Unzulässiger Parameter
  • schließen benachrichtigen

Eine schwerwiegende Warnung des Clients nach der Zertifikatszustellung weist häufig auf eine Vertrauenskette, eine Nichtübereinstimmung des Hostnamens, ein abgelaufenes Zertifikat oder nicht unterstützte Zertifikatseigenschaften hin. Eine schwerwiegende Warnung vom Server nach „ClientHello“ kann auf eine Verschlüsselung, ein Protokoll, eine SNI, ein Client-Zertifikat oder eine Richtlinie hinweisen.

Verwerfen Sie keine Warnungen, wenn Sie eine Aufnahme zuschneiden.

Wo die PCAP-Chirurgie passt

PCAP Surgery soll Ingenieuren dabei helfen, das TLS-Gespräch zu isolieren und Handshake-Beweise zu sichern. Eine nützliche abgeleitete Erfassung für die TLS-Unterstützung umfasst:

  • TCP-Handshake
  • ClientHello
  • ServerHello, falls vorhanden
  • Zertifikatsmeldungen, falls vorhanden
  • TLS-Warnungen
  • TCP wird zurückgesetzt
  • Timing zwischen Nachrichten

Wenn die Aufnahme desinfiziert werden muss, seien Sie vorsichtig. Durch das Entfernen von Zertifikatsdetails, SNI oder Nutzlastlängen kann auch die Ursache des Fehlers beseitigt werden. Die Sanierungsentscheidung sollte mit dem Fehlerbehebungsziel übereinstimmen.

Bei Suchanfragen wie „TLS-Handshake-Fehler pcap“, „ClientHello no ServerHello“ oder „SSL-Warnung unbekannt CA Wireshark“ liegt die Antwort in der Handshake-Grenze. Ein guter Workflow für die Paketchirurgie wahrt diese Grenze, anstatt sie zu verbergen.