it-swarm.com.de

SSL-Handshake fehlgeschlagen

Ich arbeite an einer Windows-Desktopanwendung, die mit C++ (IDE: Qt Creator) erstellt wurde. Es hat Login-Bereich, wo ich Benutzerüberprüfung über https-Verbindung mit openssl 1.0 Bibliothek durchführen. Die Anwendung funktioniert auf den meisten Computern, aber es tritt auch der Fehler "SSL-Handshake fehlgeschlagen" auf, während eine https-Verbindung von wenigen Computern hergestellt wird.

Ich habe versucht, den Fehler mit Wireshark zu debuggen. Meine Beobachtung ist wie folgt:

1) Der Client sendet [SYN] an den Server.
2) Der Server sendet [SYN, ACK] an den Client.
3) Der Client sendet [ACK] an den Server.
4) Der Client sendet die Nachricht "Client Hello" an den Server.
5) Der Server sendet seinen öffentlichen Schlüssel mit der Meldung "Server Hallo, Zertifikat, Server Hallo fertig".
6) Der Client sendet seinen öffentlichen Schlüssel mit der Nachricht "Client-Schlüsselaustausch, Verschlüsselungsspezifikation ändern, verschlüsselte Handshake-Nachricht".
7) Der Server sendet eine verschlüsselte Handshake-Nachricht mit der Meldung "Verschlüsselungsspezifikation ändern, verschlüsselte Handshake-Nachricht".
8) Client sendet [FIN, ACK]
9) Server sendet [FIN, ACK]
10) Client sendet [FIN]

Im siebten Schritt initiiert der Client die Beendigung des Handshakes durch das FIN-Signal, sobald der Client eine verschlüsselte Nachricht vom Server empfängt. Irgendeine Idee, warum der Client die SSL-Verbindung mit "SSL-Handshake-Fehler" abbricht, nachdem beide Parteien die Schlüssel ausgetauscht haben?

5
ram

Ihre Beschreibung des Handshakes scheint darauf hinzudeuten, dass der Client und der Server den Handshake vollständig durchgeführt haben und der Client dann die Verbindung getrennt hat. Dies bedeutet, dass "etwas" aus Sicht des Kunden nicht richtig war. Es gibt meist zwei mögliche Kandidaten:

  1. Das vom Server gesendete Zertifikat ist nicht "ordnungsgemäß". Der Client entschied, dass eine Benutzerüberprüfung erforderlich ist. Der Client hat den Handshake abgeschlossen, damit er die SSL-Sitzung mit einem schnelleren "abgekürzten Handshake" (Wiederverwendung des ausgehandelten "Hauptgeheimnisses", ohne erneut auf die asymmetrische Krypto zugreifen zu müssen) erneut öffnen kann, die Verbindung jedoch geschlossen, um die Ressourcen nicht offen zu halten der Server, während sich der menschliche Benutzer entscheidet (der Fleischsack ist langsam).

  2. Die vom Server gesendete Finished -Nachricht (das ist die "verschlüsselte Handshake-Nachricht") enthält aufgrund eines Fehlers (wahrscheinlich im Client) einen falschen Wert (aus Sicht des Clients). Dies ist kein sehr wahrscheinliches Ereignis.

Ich vermute, dass Sie sich im ersten Fall befinden: Der Server verwendet eine Zertifikatkette, die für den Client "nicht gut" ist. Übliche Schuldige:

  • Die Serverzertifikatskette ist nicht mit einem der "vertrauenswürdigen Roots" des Clients verknüpft (abhängig von der auf dem Client verwendeten Bibliothek kann sich die Liste der Roots an mehreren Stellen befinden).
  • Der vom Client erwartete Server Name (der in seiner URL) wird nicht mit den Namen im Serverzertifikat abgeglichen.
  • Die Client-Uhr ist wild ausgeschaltet, daher lehnt sie ein Zertifikat ab, das aus ihrer Sicht entweder "in der Zukunft" ausgestellt wurde oder lange abgelaufen ist.
7
Tom Leek

exportieren Sie das Zertifikat des Servers auf den Clientcomputer in eine Datei wie servercert.crt. Führen Sie auf dem Client Folgendes aus: certutil -verify -urlfetch servercert.crt

Es wird Ihnen mit ziemlicher Sicherheit sagen, warum die Serverzertifikatskette nicht als gültig angesehen wurde. Grüße

4
lsousa