TLS-Warnung vom Server empfangen: Handshake fehlgeschlagen (40)

2688
user619271

Ich habe einen neuen Webserver mit proftpdOnboard. Das Problem ist, dass ich keine Verbindung über filezillaFTP-Client herstellen kann, da es einen Fehler gibt

Status: Connection established, waiting for welcome message... Response: 220 FTP Server ready. Command: AUTH TLS Response: 234 AUTH TLS successful Status: Initializing TLS... Error: Received TLS alert from the server: Handshake failed (40) Error: Could not connect to server 

Ich habe festgestellt, dass der Fehler dem Protokollsatz von Proftpd entspricht /var/log/proftpd/tls.log/var/log/proftpd/tls.log:

Jul 24 13:50:47 mod_tls/2.4.2[1572]: unable to accept TLS connection: protocol error:  (1) error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher 

Dies bedeutet, dass der FTP-Client keine der vom Server vorgeschlagenen Verschlüsselungsalgorithmen unterstützt. Daher schlägt die Verbindung fehl.

Ich habe auch eine TLSCipherSuiteRichtlinie, /etc/proftpd.confdass deaktiviert ADH, DES, SSLv2und SSLv3Chiffren.

TLSCipherSuite ALL:!ADH:!DES:!SSLv2:!SSLv3 

Wenn ich :!SSLv3den Server aus der Direktive entferne und den Server neu starte, stellt filezilla eine Verbindung ohne Probleme her. Das Aktivieren SSLv3scheint jedoch eine schlechte Idee zu sein, da es laut http://disablessl3.com/ anfällig und unsicher ist.

Frage

Meine Frage ist also: Was kann ich tun, um proftpdmindestens eine sichere Chiffre für erfolgreiche Verhandlungen mit einem filezillaFTP-Client bereitzustellen ?

Zusätzliche Anmerkung

Es gibt eine ähnliche Frage Recieved TLS - Benachrichtigung vom Server: Handshake fehlgeschlagen (40) das sagt

Verwenden Sie nur normales FTP (unsicher)

Aber ich möchte, dass die Verbindung sicher ist, daher ist die Antwort für mich ungeeignet.

Zusätzliche Anmerkung # 2

Liste der verfügbaren Chiffren:

[root@server ~]# openssl ciphers -v 'ALL:!ADH:!DES:!SSLv2:!SSLv3' ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256 ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA384 ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384 AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128) Mac=SHA256 ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA256 ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA256 AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 
1

2 Antworten auf die Frage

3
user619271

Die Wurzel des Problems war das Fehlen einer TLSProtocolRichtlinie in /etc/proftpd.conf. Der Standardwert ist TLSv1und verhindert die Verwendung von TLSv1.2.

Ich habe hinzugefügt

 TLSProtocol TLSv1.2 

auf /etc/proftpd.conf, neu gestartet wurde den Server und das Problem ist gelöst.

https://forum.filezilla-project.org/viewtopic.php?f=2&t=45829&p=157134#p157134 http://www.proftpd.org/docs/contrib/mod_tls.html#TLSProtocol

Obwohl es meinen Fall gelöst hat, wird es auch empfohlen zu verwenden

 TLSProtocol ALL -SSLv3 

stattdessen.

https://forum.filezilla-project.org/viewtopic.php?p=157135#p157135

2
Liam Dennehy

Wenn Sie die vom System installierten OpenSSL-Bibliotheken verwenden (z. B. Ihre RedHat RPM-Installation), können Sie die verfügbaren Verschlüsselungen anzeigen, indem Sie Folgendes ausführen:

openssl ciphers -v 'ALL:!ADH:!DES:!SSLv2:!SSLv3'

Wenn filezilla einfach nicht SSLv3 / TLSv1 spricht (ungefähr gleichwertig), haben Sie kein Glück und sollten prüfen, ob eine aktualisierte Version verfügbar ist, die dies tut.

Möglicherweise gibt es eine andere Konfiguration / Ciphersuite-Einstellung, die für Ihre Arbeitslast geeignet ist. Es ist jedoch nicht ratsam, die Informationen in diesem Forum zu erhalten, ohne die Anforderungen Ihrer Situation richtig zu analysieren.

Nun müssen Sie sehen, welche Verschlüsselungen und SSL / TLS-Versionen von Ihrem FileZilla-Client unterstützt werden. Wenn es nicht mindestens eine gibt, die sich überschneidet, wird dies niemals funktionieren. Liam Dennehy vor 7 Jahren 1