☰

Warum ist der Server nach dem Starten einer TLS-Sitzung beendet?

tag-icon • tag-icon tls
Warum ist der Server nach dem Starten einer TLS-Sitzung beendet?

Der TLS-Server macht etwas, das ich nicht verstehe.

  1. Der TCP-Handshake wird normal ausgeführt.
  2. SSL-Client Hello wird normal ausgeführt.
  3. SSL-Server-Hello scheint normal. Stellt Zertifikat bereit, sagt Server Hello Done.
  4. Analyse zeigt Client-Probleme „Client-Schlüsselaustausch, Änderung der Verschlüsselungsspezifikation, verschlüsselte Handshake-Nachricht“
  5. Analyse zeigt Serverprobleme „Change Cipher Spec“ und dann „Encrypted Handshake Message“

Der Client sendet jetzt ACKs und beginnt mit dem Senden von Daten. Aber der Server sendet ACKs und dann einen „verschlüsselten Alarm“ und FIN ist raus.

Dies geschah unmittelbar nach dem Austausch der Zertifikate. Das im SSL-Handshake präsentierte Zertifikat ist der neue Schlüssel.

Hat irgendjemand eine Ahnung?

Antwort1

Es liegt wahrscheinlich an einem SNI-Problem mit dem Client oder einem dazwischen liegenden Gerät, wie z. B. einem Lastenausgleichsgerät. Das Lastenausgleichsgerät muss in der Lage sein, dem Backend-Host den Servernamen als Teil des anfänglichen Client Hello anzuzeigen. siehehttps://en.m.wikipedia.org/wiki/Server_Name_Indication

Antwort2

Das wichtigste Paket ist der „Verschlüsselte Alarm“, da es den Grund enthält, warum die Verbindung geschlossen wird.

Es scheint sich um einen Validierungsfehler zu handeln. Dies bedeutet, dass das Zertifikat nicht vertrauenswürdig oder ungültig ist. Der wahre Grund ist jedoch, dass es über dasTLS-Alarmprotokoll

Antwort3

pure-ftpdIch bin im expliziten TLS-Modus (FTPS-Server) auf ein ähnliches Problem gestoßen .

In meinem Fall gab es jedochNEIN Encrypted Alertvom Server gesendet; es endete sofort nach dem Schlüsselaustausch ( Change Cipher Spec, FinishedNachricht vom Server → FIN vom Server). Als nächstesder Kundehat den Encrypted alertLevel-1-Code 0 gesendet Close Notify(was im Gegensatz zum Server-FIN erwartet wurde).

Dies geschah nur bei einem einzigen bestimmten Client (einer Geräte-Firmware) und ließ sich bei anderen FTP-Clients nicht reproduzieren.

Ich habe die Ursache des Problems noch nicht herausgefunden, aber ich vermute, wir sind auf einenServerfehler. pure-ftpdverwendet ein Apache-ähnliches Fork-per-Connection-Modell; und ich habe beobachtetder Kindprozess stürzt abin gdb (Beenden mit Code -1) – was natürlich dazu führt, dass das Betriebssystem den Socket FD schließt und FIN sendet.

Ein weiterer Grund, in meinem Fall von einem Serverfehler zu sprechen: Das Verhalten trat nicht mehr auf, sobald wir den FTP-Server gegen eine andere Implementierung ausgetauscht hatten proftpd.

Ich glaube nicht, dass dies auf den Fall des OP zutrifft – dort beendet der Server die Verbindung auf TLS-gerechte Weise mit einer verschlüsselten Warnung – aber es ist trotzdem etwas, das jeder bedenken sollte, der auf diese Seite stößt.

verwandte Informationen