filezilla 3.42.1 TLS connection problem

[renaud101]

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]

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.

[botg]

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

[renaud101]

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.

[botg]

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

[anigma]

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]

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

[renaud101]

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

[botg]

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]

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

[nguyenvuhai]

I have the same problem after upgrading to the FileZilla version 3.42.1 on Windows 10. Has anyone had a solution ???

[renaud101]

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]

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.