filezilla 3.42.1 TLS connection problem
Moderator: Project members
filezilla 3.42.1 TLS connection problem
Hello
I have some issues with filezilla 3.42.1 on windows when using TLS
The user logs in fine then I get 150 Accepted data connection, but afterwards
error: GnuTLS error - 58: An illegal TLS extension was received
The data connection could not be established: ECONNABORTED
The client correctly logged in with TLS: Enabled TLSv1/SSLv3 with ECDHE-ECDSA-CHACHA20-POLY1305, 256 secret bits cipher
Changing the supported encryption to AES256 or AES128 gives the same issue
The server certificate is generated with a 384 bits ECDSA key.
The ftp server is pure-ftpd 1.0.47
I am able to connect just fine with filezilla 3.28 linux (gnutls 3.5.18)
I have some issues with filezilla 3.42.1 on windows when using TLS
The user logs in fine then I get 150 Accepted data connection, but afterwards
error: GnuTLS error - 58: An illegal TLS extension was received
The data connection could not be established: ECONNABORTED
The client correctly logged in with TLS: Enabled TLSv1/SSLv3 with ECDHE-ECDSA-CHACHA20-POLY1305, 256 secret bits cipher
Changing the supported encryption to AES256 or AES128 gives the same issue
The server certificate is generated with a 384 bits ECDSA key.
The ftp server is pure-ftpd 1.0.47
I am able to connect just fine with filezilla 3.28 linux (gnutls 3.5.18)
Re: filezilla 3.42.1 TLS connection problem
I just tested with a portable version of 3.39.0 on windows 2008R2 and it works just fine, so the issue might be in the version of GNUtls bundled with 3.42.1.
Re: filezilla 3.42.1 TLS connection problem
I offer an alternative hypothesis: The TLS library used by the server isn't working correctly.
Re: filezilla 3.42.1 TLS connection problem
The server is using the latest version of libressl (2.9.1).
Filezilla 3.40 on windows is also working fine.
So, yes, it might be server TLS version which is not working correctly, but only filezilla 3.42 has problems with it. Given that the smtp server, imap server, http server are all using the same libressl version with the same crypto suites and no issue has been reported, you can make your guess.
Filezilla 3.40 on windows is also working fine.
So, yes, it might be server TLS version which is not working correctly, but only filezilla 3.42 has problems with it. Given that the smtp server, imap server, http server are all using the same libressl version with the same crypto suites and no issue has been reported, you can make your guess.
Re: filezilla 3.42.1 TLS connection problem
Would it be possible to get a temporary guest account on your server so that I can analyze this in detail?
Re: filezilla 3.42.1 TLS connection problem
I have the exact same problem after upgrading to the latest FileZilla version on both Windows and MacOS. I assume renaud101 is using OpenBSD as his server OS? Which means we might have the same set up and the same version of pure-ftpd running. I did a quick FTP over TLS test via ftptest.net which resulted in a successful TLS connection. I'm willing to PM the log message from ftptest.net if need be.
Re: filezilla 3.42.1 TLS connection problem
Yes, I am using OpenBSD.
I have sent created a test account for botg, details are in PM.
I have sent created a test account for botg, details are in PM.
Re: filezilla 3.42.1 TLS connection problem
On a side note, ftptest.net gives a non TLS related error:
Error: Carriage return without line feed received
Error: Carriage return without line feed received
Re: filezilla 3.42.1 TLS connection problem
Yes, this is a bug in the TLS library used by the server.
On the data connection, these are the contents of the Client Hello and Server Hello packages:
The Server Hello is followed by the server sending Change Cipher Spec, which means a session is resumed.
As you can see, the Client Hello does not contain a server_name extension, whereas the Server Hello does contain a server_name extension.
From RFC 5246: "An extension type MUST NOT appear in the ServerHello unless the same extension type appeared in the corresponding ClientHello. If a client receives an extension type in ServerHello that it did not request in the associated ClientHello, it MUST abort the handshake with an unsupported_extension fatal alert."
From RFC 6066: "When resuming a session, the server MUST NOT include a server_name extension in the server hello."
Note the very strict MUST / MUST NOT wording. It's not a recommendation, it's a hard requirement.
Please contact your TLS library vendor for assistance.
On the data connection, these are the contents of the Client Hello and Server Hello packages:
Code: Select all
TLSv1.2 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 572
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 568
Version: TLS 1.2 (0x0303)
Random: c0be53119d5abfe814b7b5068d826f70a41ffdb300caf63b…
Session ID Length: 32
Session ID: 11b568ebf6716b24b778bbc0084849fcfa5cba0fd350af04…
Cipher Suites Length: 58
Cipher Suites (29 suites)
Compression Methods Length: 1
Compression Methods (1 method)
Extensions Length: 437
Extension: status_request (len=5)
Extension: supported_groups (len=20)
Extension: ec_point_formats (len=2)
Extension: signature_algorithms (len=32)
Extension: encrypt_then_mac (len=0)
Extension: extended_master_secret (len=0)
Extension: session_ticket (len=176)
Extension: key_share (len=139)
Extension: supported_versions (len=9)
Extension: renegotiation_info (len=1)
Extension: psk_key_exchange_modes (len=3)
Extension: record_size_limit (len=2)
TLSv1.2 Record Layer: Handshake Protocol: Server Hello
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 85
Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 81
Version: TLS 1.2 (0x0303)
Random: 24abe46e0efa62348735215d623dd36006f9a79fce7402a9…
Session ID Length: 32
Session ID: 11b568ebf6716b24b778bbc0084849fcfa5cba0fd350af04…
Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
Compression Method: null (0)
Extensions Length: 9
Extension: server_name (len=0)
Extension: renegotiation_info (len=1)
As you can see, the Client Hello does not contain a server_name extension, whereas the Server Hello does contain a server_name extension.
From RFC 5246: "An extension type MUST NOT appear in the ServerHello unless the same extension type appeared in the corresponding ClientHello. If a client receives an extension type in ServerHello that it did not request in the associated ClientHello, it MUST abort the handshake with an unsupported_extension fatal alert."
From RFC 6066: "When resuming a session, the server MUST NOT include a server_name extension in the server hello."
Note the very strict MUST / MUST NOT wording. It's not a recommendation, it's a hard requirement.
Please contact your TLS library vendor for assistance.
Re: filezilla 3.42.1 TLS connection problem
I sent a mail to the openbsd mailing list about this:
https://marc.info/?l=openbsd-tech&m=155894576831612&w=2
https://marc.info/?l=openbsd-tech&m=155894576831612&w=2
-
- 500 Command not understood
- Posts: 1
- Joined: 2019-05-28 04:27
- First name: Hai
- Last name: Nguyen Vu
- Location: Hải Phòng
Re: filezilla 3.42.1 TLS connection problem
I have the same problem after upgrading to the FileZilla version 3.42.1 on Windows 10. Has anyone had a solution ???
<Signature removed: You are not allowed to put spam into the signature, posts, or profile! You've been warned, next time ban.>
Re: filezilla 3.42.1 TLS connection problem
I am wondering why the server_name is not sent in the Client Hello since the certificate can be valid for multiple domains and thus the server must be able to send the correct one based on the name.
Re: filezilla 3.42.1 TLS connection problem
Seems to working fine with the current 3.45.1 release on Windows 10 1809.
Server OS is running OpenBSD 6.5 with LibreSSL 2.9.1.
Server OS is running OpenBSD 6.5 with LibreSSL 2.9.1.