Opened 11 years ago
Closed 10 years ago
#9441 closed Bug report (rejected)
Latest GnuTLS breaks compatibility with a number of servers
Reported by: | Drake D. Taylor | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | FileZilla Client |
Keywords: | GnuTLS | Cc: | dam012345@… |
Component version: | Operating system type: | Windows | |
Operating system version: | All Windows Versions |
Description
As of v3.8 FileZilla is not able to connect over SSL/TLS to a number of FTP servers; Tested against ZFTP Server and Syncplify.me Server, maybe there are others.
Older versions of FileZilla Client work perfectly. Servers have not been updated, therefore it must have been something in the FileZilla Client 3.8 update.
Change History (9)
comment:1 by , 11 years ago
Status: | new → moreinfo |
---|
comment:2 by , 10 years ago
Cc: | added |
---|
Same problem here :
We got a FileZilla server running version 0.9.43 requiring implicit FTP over TLS to connect.
From outside our business network we could connect to it with FileZilla client version up to 3.7.4.1 (GnuTLS v3.1.11).
With FileZilla client version 3.8 or 3.8.1 (GnuTLS v3.2.15) i got :
Status: Connecting to [hiding my ip]:990... Status: Connection established, initializing TLS... Error: Connection timed out Error: Could not connect to server
Popup "Unknown certificate" does not appear, unlike with version 3.7.4.1
Status: Verifying certificate...
No problem with any FileZilla Client version from inside our business network
Any clue ?
comment:3 by , 10 years ago
Status: | moreinfo → new |
---|
I have checked #7873, and although this submission seems somewhat related. But not necessarily. Here's the FileZilla client verbose log:
Status: Resolving address of [censored] Status: Connecting to 142.4.201.76:990... Status: Connection established, initializing TLS... Trace: CTlsSocket::Handshake() Trace: CTlsSocket::ContinueHandshake() Trace: CTlsSocket::OnSend() Trace: CTlsSocket::OnRead() Trace: CTlsSocket::ContinueHandshake() Trace: CTlsSocket::OnRead() Trace: CTlsSocket::ContinueHandshake() Trace: CTlsSocket::OnRead() Trace: CTlsSocket::ContinueHandshake() Trace: CTlsSocket::OnRead() Trace: CTlsSocket::ContinueHandshake() Trace: CTlsSocket::OnRead() Trace: CTlsSocket::ContinueHandshake() Trace: TLS Handshake successful Trace: Protocol: TLS1.2, Key exchange: ECDHE-RSA, Cipher: AES-256-GCM, MAC: AEAD Status: Verifying certificate... Trace: CTlsSocket::Failure(-24, 106) Error: GnuTLS error -24: Decryption has failed. Trace: CFtpControlSocket::SendNextCommand() Trace: CRealControlSocket::OnClose(106) Trace: CControlSocket::DoClose(64) Trace: CFtpControlSocket::ResetOperation(66) Trace: CControlSocket::ResetOperation(66) Error: Could not connect to server Trace: CFileZillaEnginePrivate::ResetOperation(66)
comment:4 by , 10 years ago
And if I deactivate (on the server side) TLS1.1 and TLS1.2, leaving only TLS1.0, then the session log becomes:
Status: Resolving address of [censored] Status: Connecting to 142.4.201.76:990... Status: Connection established, initializing TLS... Trace: CTlsSocket::Handshake() Trace: CTlsSocket::ContinueHandshake() Trace: CTlsSocket::OnSend() Trace: CTlsSocket::OnRead() Trace: CTlsSocket::ContinueHandshake() Trace: CTlsSocket::OnRead() Trace: CTlsSocket::ContinueHandshake() Trace: CTlsSocket::Failure(-21, 106) Error: GnuTLS error -21: Could not negotiate a supported cipher suite. Trace: CRealControlSocket::OnClose(106) Trace: CControlSocket::DoClose(64) Trace: CFtpControlSocket::ResetOperation(66) Trace: CControlSocket::ResetOperation(66) Error: Could not connect to server Trace: CFileZillaEnginePrivate::ResetOperation(66)
comment:5 by , 10 years ago
I've set up a test account for you to try yourself:
Server IP address: 198.50.154.42
Username: fztest
Password: fz123456
(obviously the account has read-only access, but - after all - you will see the issue even before getting to the authentication prompt)
comment:6 by , 10 years ago
Resolution: | → rejected |
---|---|
Status: | new → closed |
Error: GnuTLS error -24: Decryption has failed.
This is a bug in your particular server. The same decryption failure also happens with clients using OpenSSL as TLS library.
openssl s_client -starttls ftp -CAfile foo -crlf -connect 198.50.154.42:21 CONNECTED(00000003) depth=0 C = US, ST = DE, L = Wilmington, O = "Syncplify, Inc.", CN = backup.syncplify.me, emailAddress = info@syncplify.me verify return:1 140675337864848:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record mac:s3_pkt.c:1275:SSL alert number 20 140675337864848:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:
Contact your server administrator or server hosting provider for assistance so that they can upgrade or replace the server software with a working one.
comment:7 by , 10 years ago
Priority: | critical → normal |
---|
comment:8 by , 10 years ago
Resolution: | rejected |
---|---|
Status: | closed → reopened |
I wouldn't be so quick at rejecting this ticket:
FileZilla 3.7.4.1 works perfectly with that server
And so do FlashFXP, SmartFTP, CuteFTP, CoreFTP LE...
Only FileZilla as of v3.8 (and subsequent) fails.
Your test here above is wrong... you tried port 21, try port 990.
comment:9 by , 10 years ago
Resolution: | → rejected |
---|---|
Status: | reopened → closed |
"But it work in another program or older version, the new version must be broken" is a common and understandable fallacy. However it is the server causing your problems.
TLS supports many different cryptographic algorithms. Different clients, servers or versions thereof may use different algorithms.
When establishing a connection, client and server negotiate a common cipher. In any case, the cipher used is one the server has actively advertises support for. In your case the server advertises support for a particular cipher suite [*] but then does not implement it correctly.
[*] Key exchange: ECDHE-RSA, Cipher: AES-256-GCM, MAC: AEAD
Can you please provide logs? From which version of FileZilla did you update? Is this related to #7873?