filezilla 3.42.1 TLS connection problem

Need help with FileZilla Client? Something does not work as expected? In this forum you may find an answer.

Moderator: Project members

Post Reply
Message
Author
renaud101
504 Command not implemented
Posts: 10
Joined: 2019-05-24 07:32

filezilla 3.42.1 TLS connection problem

#1 Post by renaud101 » 2019-05-24 07:37

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)

renaud101
504 Command not implemented
Posts: 10
Joined: 2019-05-24 07:32

Re: filezilla 3.42.1 TLS connection problem

#2 Post by renaud101 » 2019-05-24 07:59

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.

User avatar
botg
Site Admin
Posts: 33037
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse
Contact:

Re: filezilla 3.42.1 TLS connection problem

#3 Post by botg » 2019-05-24 09:40

I offer an alternative hypothesis: The TLS library used by the server isn't working correctly.

renaud101
504 Command not implemented
Posts: 10
Joined: 2019-05-24 07:32

Re: filezilla 3.42.1 TLS connection problem

#4 Post by renaud101 » 2019-05-24 21:40

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.

User avatar
botg
Site Admin
Posts: 33037
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse
Contact:

Re: filezilla 3.42.1 TLS connection problem

#5 Post by botg » 2019-05-24 21:59

Would it be possible to get a temporary guest account on your server so that I can analyze this in detail?

anigma
500 Command not understood
Posts: 2
Joined: 2019-05-27 05:20

Re: filezilla 3.42.1 TLS connection problem

#6 Post by anigma » 2019-05-27 06:40

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.

renaud101
504 Command not implemented
Posts: 10
Joined: 2019-05-24 07:32

Re: filezilla 3.42.1 TLS connection problem

#7 Post by renaud101 » 2019-05-27 06:44

Yes, I am using OpenBSD.
I have sent created a test account for botg, details are in PM.

renaud101
504 Command not implemented
Posts: 10
Joined: 2019-05-24 07:32

Re: filezilla 3.42.1 TLS connection problem

#8 Post by renaud101 » 2019-05-27 06:51

On a side note, ftptest.net gives a non TLS related error:
Error: Carriage return without line feed received

User avatar
botg
Site Admin
Posts: 33037
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse
Contact:

Re: filezilla 3.42.1 TLS connection problem

#9 Post by botg » 2019-05-27 08:01

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:

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)
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.

renaud101
504 Command not implemented
Posts: 10
Joined: 2019-05-24 07:32

Re: filezilla 3.42.1 TLS connection problem

#10 Post by renaud101 » 2019-05-27 08:31

I sent a mail to the openbsd mailing list about this:
https://marc.info/?l=openbsd-tech&m=155894576831612&w=2

nguyenvuhai
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

#11 Post by nguyenvuhai » 2019-05-28 04:34

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.>

renaud101
504 Command not implemented
Posts: 10
Joined: 2019-05-24 07:32

Re: filezilla 3.42.1 TLS connection problem

#12 Post by renaud101 » 2019-05-28 05:35

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.

anigma
500 Command not understood
Posts: 2
Joined: 2019-05-27 05:20

Re: filezilla 3.42.1 TLS connection problem

#13 Post by anigma » 2019-09-28 19:26

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.

Post Reply