Bug 1029485 - Filezilla 3.7.3 is unable to connect to FTP over explicit SSL
Filezilla 3.7.3 is unable to connect to FTP over explicit SSL
Status: CLOSED ERRATA
Product: Fedora EPEL
Classification: Fedora
Component: filezilla (Show other bugs)
el6
Unspecified Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Nicolas Chauvet (kwizart)
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-12 08:13 EST by Henning Norén
Modified: 2015-12-14 09:52 EST (History)
7 users (show)

See Also:
Fixed In Version: filezilla-3.7.3-3.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-14 09:52:16 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
crude patch, accept all "NORMAL" ciphers (672 bytes, patch)
2014-02-17 16:15 EST, Nicolas Thierry-Mieg
no flags Details | Diff

  None (edit)
Description Henning Norén 2013-11-12 08:13:13 EST
Description of problem:
When trying to connect with Filezilla 3.7.3 to a FTP server with explicit SSL I get the following error:
2013-11-12 13:48:12 9093 3 Response: 234 AUTH TLS OK.
2013-11-12 13:48:12 9093 3 Status: Initializing TLS...
2013-11-12 13:48:12 9093 3 Error: GnuTLS error -50 in gnutls_priority_set_direct: The request is invalid.
2013-11-12 13:48:12 9093 3 Error: Failed to initialize TLS.
2013-11-12 13:48:12 9093 3 Error: Could not connect to server
By downgrading Filezilla to 3.3.5, but keeping gnutls version it works fine.


Version-Release number of selected component (if applicable):
gnutls-2.8.5-10.el6_4.2.i686
gnutls-utils-2.8.5-10.el6_4.2.i686
gnutls-devel-2.8.5-10.el6_4.2.i686
filezilla-3.7.3-1.el6.i686
$ cat /etc/redhat-release 
Red Hat Enterprise Linux Workstation release 6.4 (Santiago)
$ uname -a
Linux eris 2.6.32-358.23.2.el6.i686 #1 SMP Sat Sep 14 05:33:24 EDT 2013 i686 i686 i386 GNU/Linux


How reproducible:
Always


Steps to Reproduce:
1. Try to connect to a FTP Server with explicit SSL
2. Observe the error and immediate disconnect


Actual results:
Unable to log in on the FTP server


Expected results:
Able to log in on the FTP server


Additional info:

With the following packages it does not work:
gnutls-2.8.5-10.el6_4.2.i686
gnutls-utils-2.8.5-10.el6_4.2.i686
gnutls-devel-2.8.5-10.el6_4.2.i686
filezilla-3.7.3-1.el6.i686

By downgrading filezilla but keeping gnutls version, it works fine:
gnutls-2.8.5-10.el6_4.2.i686
gnutls-utils-2.8.5-10.el6_4.2.i686
gnutls-devel-2.8.5-10.el6_4.2.i686
filezilla-3.3.5.1-2.el6.i686


In both cases I have the same setup of filezilla, no changes made and connecting to a server with the following setip in sitemanager.xml:
        <Server>
            <Host>************</Host>
            <Port>21</Port>
            <Protocol>4</Protocol>
            <Type>0</Type>
            <User>************</User>
            <Pass>************</Pass>
            <Logontype>1</Logontype>
            <TimezoneOffset>0</TimezoneOffset>
            <PasvMode>MODE_PASSIVE</PasvMode>
            <MaximumMultipleConnections>0</MaximumMultipleConnections>
            <EncodingType>Auto</EncodingType>
            <BypassProxy>0</BypassProxy>
            <Name>************</Name>
            <Comments></Comments>
            <LocalDir></LocalDir>
            <RemoteDir></RemoteDir>
            <SyncBrowsing>0</SyncBrowsing>************
        </Server>


$ gnutls-cli -l
Cipher suites:
TLS_ANON_DH_ARCFOUR_MD5                           	0x00, 0x18	SSL3.0
TLS_ANON_DH_3DES_EDE_CBC_SHA1                     	0x00, 0x1b	SSL3.0
TLS_ANON_DH_AES_128_CBC_SHA1                      	0x00, 0x34	SSL3.0
TLS_ANON_DH_AES_256_CBC_SHA1                      	0x00, 0x3a	SSL3.0
TLS_ANON_DH_CAMELLIA_128_CBC_SHA1                 	0x00, 0x46	TLS1.0
TLS_ANON_DH_CAMELLIA_256_CBC_SHA1                 	0x00, 0x89	TLS1.0
TLS_ANON_DH_AES_128_CBC_SHA256                    	0x00, 0x6c	TLS1.2
TLS_ANON_DH_AES_256_CBC_SHA256                    	0x00, 0x6d	TLS1.2
TLS_PSK_SHA_ARCFOUR_SHA1                          	0x00, 0x8a	TLS1.0
TLS_PSK_SHA_3DES_EDE_CBC_SHA1                     	0x00, 0x8b	TLS1.0
TLS_PSK_SHA_AES_128_CBC_SHA1                      	0x00, 0x8c	TLS1.0
TLS_PSK_SHA_AES_256_CBC_SHA1                      	0x00, 0x8d	TLS1.0
TLS_DHE_PSK_SHA_ARCFOUR_SHA1                      	0x00, 0x8e	TLS1.0
TLS_DHE_PSK_SHA_3DES_EDE_CBC_SHA1                 	0x00, 0x8f	TLS1.0
TLS_DHE_PSK_SHA_AES_128_CBC_SHA1                  	0x00, 0x90	TLS1.0
TLS_DHE_PSK_SHA_AES_256_CBC_SHA1                  	0x00, 0x91	TLS1.0
TLS_SRP_SHA_3DES_EDE_CBC_SHA1                     	0xc0, 0x1a	TLS1.0
TLS_SRP_SHA_AES_128_CBC_SHA1                      	0xc0, 0x1d	TLS1.0
TLS_SRP_SHA_AES_256_CBC_SHA1                      	0xc0, 0x20	TLS1.0
TLS_SRP_SHA_DSS_3DES_EDE_CBC_SHA1                 	0xc0, 0x1c	TLS1.0
TLS_SRP_SHA_RSA_3DES_EDE_CBC_SHA1                 	0xc0, 0x1b	TLS1.0
TLS_SRP_SHA_DSS_AES_128_CBC_SHA1                  	0xc0, 0x1f	TLS1.0
TLS_SRP_SHA_RSA_AES_128_CBC_SHA1                  	0xc0, 0x1e	TLS1.0
TLS_SRP_SHA_DSS_AES_256_CBC_SHA1                  	0xc0, 0x22	TLS1.0
TLS_SRP_SHA_RSA_AES_256_CBC_SHA1                  	0xc0, 0x21	TLS1.0
TLS_DHE_DSS_ARCFOUR_SHA1                          	0x00, 0x66	TLS1.0
TLS_DHE_DSS_3DES_EDE_CBC_SHA1                     	0x00, 0x13	SSL3.0
TLS_DHE_DSS_AES_128_CBC_SHA1                      	0x00, 0x32	SSL3.0
TLS_DHE_DSS_AES_256_CBC_SHA1                      	0x00, 0x38	SSL3.0
TLS_DHE_DSS_CAMELLIA_128_CBC_SHA1                 	0x00, 0x44	TLS1.0
TLS_DHE_DSS_CAMELLIA_256_CBC_SHA1                 	0x00, 0x87	TLS1.0
TLS_DHE_DSS_AES_128_CBC_SHA256                    	0x00, 0x40	TLS1.2
TLS_DHE_DSS_AES_256_CBC_SHA256                    	0x00, 0x6a	TLS1.2
TLS_DHE_RSA_3DES_EDE_CBC_SHA1                     	0x00, 0x16	SSL3.0
TLS_DHE_RSA_AES_128_CBC_SHA1                      	0x00, 0x33	SSL3.0
TLS_DHE_RSA_AES_256_CBC_SHA1                      	0x00, 0x39	SSL3.0
TLS_DHE_RSA_CAMELLIA_128_CBC_SHA1                 	0x00, 0x45	TLS1.0
TLS_DHE_RSA_CAMELLIA_256_CBC_SHA1                 	0x00, 0x88	TLS1.0
TLS_DHE_RSA_AES_128_CBC_SHA256                    	0x00, 0x67	TLS1.2
TLS_DHE_RSA_AES_256_CBC_SHA256                    	0x00, 0x6b	TLS1.2
TLS_RSA_NULL_MD5                                  	0x00, 0x01	SSL3.0
TLS_RSA_EXPORT_ARCFOUR_40_MD5                     	0x00, 0x03	SSL3.0
TLS_RSA_ARCFOUR_SHA1                              	0x00, 0x05	SSL3.0
TLS_RSA_ARCFOUR_MD5                               	0x00, 0x04	SSL3.0
TLS_RSA_3DES_EDE_CBC_SHA1                         	0x00, 0x0a	SSL3.0
TLS_RSA_AES_128_CBC_SHA1                          	0x00, 0x2f	SSL3.0
TLS_RSA_AES_256_CBC_SHA1                          	0x00, 0x35	SSL3.0
TLS_RSA_CAMELLIA_128_CBC_SHA1                     	0x00, 0x41	TLS1.0
TLS_RSA_CAMELLIA_256_CBC_SHA1                     	0x00, 0x84	TLS1.0
TLS_RSA_AES_128_CBC_SHA256                        	0x00, 0x3c	TLS1.2
TLS_RSA_AES_256_CBC_SHA256                        	0x00, 0x3d	TLS1.2
TLS_RENEGO_PROTECTION_REQUEST                     	0x00, 0xff	SSL3.0
Certificate types: X.509, OPENPGP
Protocols: SSL3.0, TLS1.0, TLS1.1, TLS1.2
Ciphers: AES-256-CBC, AES-128-CBC, 3DES-CBC, DES-CBC, ARCFOUR-128, ARCFOUR-40, RC2-40, CAMELLIA-256-CBC, CAMELLIA-128-CBC, NULL
MACs: SHA1, MD5, SHA256, SHA384, SHA512, MD2, RIPEMD160, MAC-NULL
Key exchange algorithms: ANON-DH, RSA, RSA-EXPORT, DHE-RSA, DHE-DSS, PSK, DHE-PSK
Compression: DEFLATE, NULL
Public Key Systems: RSA, DSA
PK-signatures: RSA-SHA, RSA-SHA256, RSA-SHA384, RSA-SHA512, RSA-RMD160, DSA-SHA, RSA-MD5, RSA-MD2
Comment 1 Henning Norén 2013-11-12 20:15:33 EST
I found this blog entry about the problem:
http://wp.xin.at/archives/1269

It seems like the issue will be hard to solve without Red Hat fixing the GnuTLS issue (apparently GnuTLS 2.12 or 3+ does resolve it but that means ABI/API changes). The only other option I see is patching Filezilla to allow lower grade ciphers again until the library can properly handle this.
Comment 2 Nicolas Chauvet (kwizart) 2013-11-14 18:37:34 EST
Thx for reporting this issue.
I cannot expect to work on this anytime soon. If you can suguest a patch, that would be welcomed.
Comment 3 Nicolas Chauvet (kwizart) 2014-01-06 08:19:36 EST
Can you reproduce the issue with the recent gnutls/openssl updates ?
Comment 4 AZ 2014-02-03 10:17:04 EST
Hello,

I have exactly the same issue.

Red Hat Enterprise Linux Workstation release 6.4 (Santiago)
filezilla 3.7.3
gnutls 10.el6_4.2

Connecting to a FTP over explicit TLS server :
"GnuTLS error -50 in gnutls_priority_set_direct: The request is invalid."

Any upgrade / patch planned ?

Thank you very much !
Comment 5 Nicolas Thierry-Mieg 2014-02-17 16:13:41 EST
Hi,

same issue here on a centos6 system, all updates applied.
The issue seems to be that filezilla maintainers have disabled some ciphers that they consider not very secure (probably rightly so, I have no idea).
AFAICT, the problem is that the list of accepted or rejected ciphers is specified in a string that is not understood by our gnutls version.
In any case, the attached patch solves the issue in a crude way, by accepting all ciphers that our gnutls version considers ok ("NORMAL"). I applied it with %patch0 -p0 in the SPEC. Works for me.
A better patch would probably be to build a ciphers[] string that is acceptable for our gnutls version, and that still rejects some of the low-quality ciphers that the filezilla devs wanted to reject... If someone is knowledgable in TLS ciphers and gnutls, feel free to improve the patch.
Comment 6 Nicolas Thierry-Mieg 2014-02-17 16:15:06 EST
Created attachment 864289 [details]
crude patch, accept all "NORMAL" ciphers
Comment 7 Jordi Sanfeliu 2014-07-28 09:37:19 EDT
(In reply to Nicolas Thierry-Mieg from comment #6)

Nicolas, your patch worked perfectly on a CentOS 6.5 fully updated.
Thanks a lot.

For anyone wanting to apply the same patch, here are the steps I followed:

1. Download 'filezilla-3.7.3-1.el6.src.rpm' from EPEL.

2. Create the file 'tls_allow_more_cyphers.patch' in '~/rpmbuild/SOURCES/' with the contents of the patch in comment #6 (click in 'View' to see the original).

3. Edit '~/rpmbuild/SPECS/filezilla.spec' adding the following line just below the 'Source0' line:
Patch0:         tls_allow_more_cyphers.patch

4. Edit '~/rpmbuild/SPECS/filezilla.spec' adding the following line just below the '%setup' line:
%patch0 -p0

5. Build the RPM with:
# cd ~/rpmbuild/SPECS ; rpmbuild -ba filezilla.spec

(You might need to satisfy some dependencies)
Comment 8 Nicolas Chauvet (kwizart) 2014-07-29 06:30:26 EDT
Can anyone accessing a tls ftp server test this build ?
http://koji.fedoraproject.org/koji/taskinfo?taskID=7206774

It fix the name of the X509/OPENPGP kind of keys, so it should keep discarding archaic ciphers.
Comment 9 Jordi Sanfeliu 2014-07-29 09:16:55 EDT
(In reply to Nicolas Chauvet (kwizart) from comment #8)

Nicolas, tested it here (CentOS 6.5 x86_64) and it doesn't works:

Status:	Initializing TLS...
Error:	GnuTLS error -50 in gnutls_priority_set_direct: The request is invalid.
Error:	Failed to initialize TLS.
Error:	Could not connect to server

Thanks.
Comment 10 Nikos Mavrogiannopoulos 2015-01-29 09:11:00 EST
I believe the patch in comment #6 is a pretty reasonable fix.
Comment 11 Fedora Update System 2015-10-14 16:17:41 EDT
filezilla-3.7.3-2.el6 has been submitted as an update to Fedora EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-4f8413cc12
Comment 12 Fedora Update System 2015-10-15 11:47:37 EDT
filezilla-3.7.3-2.el6 has been pushed to the Fedora EPEL 6 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'yum --enablerepo=epel-testing update filezilla'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-4f8413cc12
Comment 13 Jordi Sanfeliu 2015-10-29 10:58:31 EDT
(In reply to Fedora Update System from comment #12)

Following the kwizart's request:
<https://bodhi.fedoraproject.org/updates/filezilla-3.7.3-2.el6#comment-344688>

>  kwizart - 2015-10-28 20:41:17.706595 (karma 0)
>  Can you reproduce using gnutls-cli and report on the
>  related bugreport.

$ gnutls-cli -d 5 <remotehost> -p 21
Resolving '<remotehost>'...
Connecting to '<remoteIP>'...
|<3>| HSK[0x202fa00]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x202fa00]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x202fa00]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[0x202fa00]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x202fa00]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x202fa00]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[0x202fa00]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x202fa00]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[0x202fa00]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x202fa00]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[0x202fa00]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[0x202fa00]: Keeping ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[0x202fa00]: Keeping ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[0x202fa00]: Keeping ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x202fa00]: Keeping ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[0x202fa00]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x202fa00]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
|<3>| HSK[0x202fa00]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x202fa00]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
|<3>| HSK[0x202fa00]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
|<3>| HSK[0x202fa00]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[0x202fa00]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[0x202fa00]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x202fa00]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[0x202fa00]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x202fa00]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x202fa00]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[0x202fa00]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<3>| HSK[0x202fa00]: Keeping ciphersuite: PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[0x202fa00]: Keeping ciphersuite: PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[0x202fa00]: Keeping ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x202fa00]: Keeping ciphersuite: PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[0x202fa00]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
|<3>| HSK[0x202fa00]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1
|<3>| HSK[0x202fa00]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
|<2>| EXT[0x202fa00]: Sending extension CERT_TYPE
|<2>| EXT[0x202fa00]: Sending extension SERVER_NAME
|<2>| EXT[0x202fa00]: Sending extension SAFE_RENEGOTIATION
|<3>| HSK[0x202fa00]: CLIENT HELLO was sent [134 bytes]
|<4>| REC[0x202fa00]: Sending Packet[0] Handshake(22) with length: 134
|<4>| REC[0x202fa00]: Sent Packet[1] Handshake(22) with length: 139
|<2>| ASSERT: gnutls_record.c:507
|<4>| REC[0x202fa00]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[0x202fa00]: Received Packet[0] Unknown Packet(50) with length: 11533
|<2>| ASSERT: gnutls_buffers.c:608
|<2>| ASSERT: gnutls_buffers.c:1032
*** Non fatal error: Resource temporarily unavailable, try again.
|<2>| ASSERT: gnutls_record.c:507
|<4>| REC[0x202fa00]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[0x202fa00]: Received Packet[0] Unknown Packet(50) with length: 11533
|<2>| ASSERT: gnutls_buffers.c:599
|<2>| ASSERT: gnutls_record.c:988
|<2>| ASSERT: gnutls_buffers.c:1032
|<2>| ASSERT: gnutls_handshake.c:2700
*** Fatal error: A TLS packet with unexpected length was received.
|<4>| REC: Sending Alert[2|22] - Record overflow
|<4>| REC[0x202fa00]: Sending Packet[1] Alert(21) with length: 2
|<4>| REC[0x202fa00]: Sent Packet[2] Alert(21) with length: 7
*** Handshake has failed
GNUTLS ERROR: A TLS packet with unexpected length was received.

I hope that helps.
Comment 14 Nikos Mavrogiannopoulos 2015-10-29 11:07:34 EDT
(In reply to Jordi Sanfeliu from comment #13)
> (In reply to Fedora Update System from comment #12)
> 
> Following the kwizart's request:
> <https://bodhi.fedoraproject.org/updates/filezilla-3.7.3-2.el6#comment-
> 344688>
> 
> >  kwizart - 2015-10-28 20:41:17.706595 (karma 0)
> >  Can you reproduce using gnutls-cli and report on the
> >  related bugreport.
> 
> $ gnutls-cli -d 5 <remotehost> -p 21
> Resolving '<remotehost>'...
> Connecting to '<remoteIP>'...

gnutls-cli cannot connect to port 21 as it doesn't run TLS. If you have fedora 23 you can run gnutls-cli --starttls-proto=ftp to force ftp starttls negotiation, or in order versions you have to use --starttls and do the FTP starttls negotiation manually.
Comment 15 Jordi Sanfeliu 2015-11-02 10:59:51 EST
(In reply to Nikos Mavrogiannopoulos from comment #14)
> 
> gnutls-cli cannot connect to port 21 as it doesn't run TLS. If you have
> fedora 23 you can run gnutls-cli --starttls-proto=ftp to force ftp starttls
> negotiation, or in order versions you have to use --starttls and do the FTP
> starttls negotiation manually.

OK, I've downloaded a F23 and here are the results.

First test without '--starttls-proto=ftp'
-----------------------------------------
# gnutls-cli -d 5 <remotehost> -p 21
|<2>| Initializing PKCS #11 modules
|<2>| p11: Initializing module: p11-kit-trust
|<3>| ASSERT: pkcs11.c:670
|<3>| p11 attrs: CKA_CLASS (CERT), CKA_CERTIFICATE_TYPE
|<3>| p11 attrs: CKA_TRUSTED
|<3>| p11 attrs: CKA_CERTIFICATE_CATEGORY=CA
|<3>| p11 attrs: CKA_CLASS (CERT), CKA_CERTIFICATE_TYPE
|<3>| p11 attrs: CKA_TRUSTED
|<3>| p11 attrs: CKA_CERTIFICATE_CATEGORY=CA
|<3>| ASSERT: pkcs11.c:2687
|<3>| ASSERT: pkcs11.c:2989
Processed 185 CA certificate(s).
Resolving '<remotehost>'...
Connecting to '<remoteIP>:21'...
|<5>| REC[0x5555ccefdd10]: Allocating epoch #0
|<2>| selected priority string: NONE:+VERS-TLS-ALL:-VERS-SSL3.0:+AEAD:+SHA1:+SHA256:+SHA384:+ECDHE-RSA:+ECDHE-ECDSA:+RSA:+DHE-RSA:+DHE-DSS:+AES-128-GCM:+AES-128-CBC:+CAMELLIA-128-GCM:+CAMELLIA-128-CBC:+AES-256-GCM:+AES-256-CBC:+CAMELLIA-256-GCM:+CAMELLIA-256-CBC:+3DES-CBC:+SIGN-ALL:-SIGN-RSA-MD5:+CURVE-ALL:+COMP-NULL:%PROFILE_LOW
|<3>| ASSERT: gnutls_constate.c:588
|<5>| REC[0x5555ccefdd10]: Allocating epoch #1
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_AES_128_GCM_SHA256 (C0.2F)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_AES_128_CBC_SHA1 (C0.13)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_AES_128_CBC_SHA256 (C0.27)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_CAMELLIA_128_GCM_SHA256 (C0.8A)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_CAMELLIA_128_CBC_SHA256 (C0.76)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_AES_256_GCM_SHA384 (C0.30)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_AES_256_CBC_SHA1 (C0.14)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_AES_256_CBC_SHA384 (C0.28)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_CAMELLIA_256_GCM_SHA384 (C0.8B)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_CAMELLIA_256_CBC_SHA384 (C0.77)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_ECDHE_RSA_3DES_EDE_CBC_SHA1 (C0.12)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_128_GCM_SHA256 (C0.2B)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_128_CBC_SHA1 (C0.09)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_128_CBC_SHA256 (C0.23)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_CAMELLIA_128_GCM_SHA256 (C0.86)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_CAMELLIA_128_CBC_SHA256 (C0.72)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_256_GCM_SHA384 (C0.2C)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_256_CBC_SHA1 (C0.0A)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_AES_256_CBC_SHA384 (C0.24)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_CAMELLIA_256_GCM_SHA384 (C0.87)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_CAMELLIA_256_CBC_SHA384 (C0.73)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_ECDHE_ECDSA_3DES_EDE_CBC_SHA1 (C0.08)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_RSA_AES_128_GCM_SHA256 (00.9C)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_RSA_AES_128_CBC_SHA1 (00.2F)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_RSA_AES_128_CBC_SHA256 (00.3C)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_128_GCM_SHA256 (C0.7A)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_128_CBC_SHA1 (00.41)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_128_CBC_SHA256 (00.BA)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_RSA_AES_256_GCM_SHA384 (00.9D)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_RSA_AES_256_CBC_SHA1 (00.35)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_RSA_AES_256_CBC_SHA256 (00.3D)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_256_GCM_SHA384 (C0.7B)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_256_CBC_SHA1 (00.84)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_256_CBC_SHA256 (00.C0)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_RSA_3DES_EDE_CBC_SHA1 (00.0A)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_128_GCM_SHA256 (00.9E)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_128_CBC_SHA1 (00.33)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_128_CBC_SHA256 (00.67)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_RSA_CAMELLIA_128_GCM_SHA256 (C0.7C)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_RSA_CAMELLIA_128_CBC_SHA1 (00.45)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_RSA_CAMELLIA_128_CBC_SHA256 (00.BE)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_256_GCM_SHA384 (00.9F)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_256_CBC_SHA1 (00.39)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_RSA_AES_256_CBC_SHA256 (00.6B)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_RSA_CAMELLIA_256_GCM_SHA384 (C0.7D)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_RSA_CAMELLIA_256_CBC_SHA1 (00.88)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_RSA_CAMELLIA_256_CBC_SHA256 (00.C4)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_RSA_3DES_EDE_CBC_SHA1 (00.16)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_DSS_AES_128_GCM_SHA256 (00.A2)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_DSS_AES_128_CBC_SHA1 (00.32)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_DSS_AES_128_CBC_SHA256 (00.40)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_DSS_CAMELLIA_128_GCM_SHA256 (C0.80)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_DSS_CAMELLIA_128_CBC_SHA1 (00.44)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_DSS_CAMELLIA_128_CBC_SHA256 (00.BD)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_DSS_AES_256_GCM_SHA384 (00.A3)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_DSS_AES_256_CBC_SHA1 (00.38)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_DSS_AES_256_CBC_SHA256 (00.6A)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_DSS_CAMELLIA_256_GCM_SHA384 (C0.81)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_DSS_CAMELLIA_256_CBC_SHA1 (00.87)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_DSS_CAMELLIA_256_CBC_SHA256 (00.C3)
|<4>| HSK[0x5555ccefdd10]: Keeping ciphersuite: GNUTLS_DHE_DSS_3DES_EDE_CBC_SHA1 (00.13)
|<4>| EXT[0x5555ccefdd10]: Sending extension EXT MASTER SECRET (0 bytes)
|<4>| EXT[0x5555ccefdd10]: Sending extension ENCRYPT THEN MAC (0 bytes)
|<4>| EXT[0x5555ccefdd10]: Sending extension STATUS REQUEST (5 bytes)
|<4>| EXT[0x5555ccefdd10]: Sending extension SERVER NAME (21 bytes)
|<4>| EXT[0x5555ccefdd10]: Sending extension SAFE RENEGOTIATION (1 bytes)
|<4>| EXT[0x5555ccefdd10]: Sending extension SESSION TICKET (0 bytes)
|<4>| EXT[0x5555ccefdd10]: Sending extension SUPPORTED ECC (8 bytes)
|<4>| EXT[0x5555ccefdd10]: Sending extension SUPPORTED ECC POINT FORMATS (2 bytes)
|<4>| EXT[0x5555ccefdd10]: sent signature algo (4.1) RSA-SHA256
|<4>| EXT[0x5555ccefdd10]: sent signature algo (4.3) ECDSA-SHA256
|<4>| EXT[0x5555ccefdd10]: sent signature algo (5.1) RSA-SHA384
|<4>| EXT[0x5555ccefdd10]: sent signature algo (5.3) ECDSA-SHA384
|<4>| EXT[0x5555ccefdd10]: sent signature algo (6.1) RSA-SHA512
|<4>| EXT[0x5555ccefdd10]: sent signature algo (6.3) ECDSA-SHA512
|<4>| EXT[0x5555ccefdd10]: sent signature algo (3.1) RSA-SHA224
|<4>| EXT[0x5555ccefdd10]: sent signature algo (3.3) ECDSA-SHA224
|<4>| EXT[0x5555ccefdd10]: sent signature algo (2.1) RSA-SHA1
|<4>| EXT[0x5555ccefdd10]: sent signature algo (2.3) ECDSA-SHA1
|<4>| EXT[0x5555ccefdd10]: Sending extension SIGNATURE ALGORITHMS (22 bytes)
|<4>| HSK[0x5555ccefdd10]: CLIENT HELLO was queued [262 bytes]
|<5>| REC[0x5555ccefdd10]: Preparing Packet Handshake(22) with length: 262 and min pad: 0
|<5>| REC[0x5555ccefdd10]: Sent Packet[1] Handshake(22) in epoch 0 and length: 267
|<3>| ASSERT: gnutls_buffers.c:1154
|<5>| REC[0x5555ccefdd10]: SSL 50.48 Unknown Packet packet received. Epoch 0, length: 11533
|<3>| ASSERT: gnutls_record.c:572
|<1>| Received record packet of unknown type 50
|<3>| ASSERT: gnutls_record.c:1076
|<3>| ASSERT: gnutls_record.c:1158
|<3>| ASSERT: gnutls_buffers.c:1409
|<3>| ASSERT: gnutls_handshake.c:1446
|<3>| ASSERT: gnutls_handshake.c:2752
*** Fatal error: An unexpected TLS packet was received.
|<5>| REC: Sending Alert[2|10] - Unexpected message
|<5>| REC[0x5555ccefdd10]: Preparing Packet Alert(21) with length: 2 and min pad: 0
|<5>| REC[0x5555ccefdd10]: Sent Packet[2] Alert(21) in epoch 0 and length: 7
*** Handshake has failed
GnuTLS error: An unexpected TLS packet was received.
|<5>| REC[0x5555ccefdd10]: Start of epoch cleanup
|<5>| REC[0x5555ccefdd10]: End of epoch cleanup
|<5>| REC[0x5555ccefdd10]: Epoch #0 freed
|<5>| REC[0x5555ccefdd10]: Epoch #1 freed


Second test with '--starttls-proto=ftp'
---------------------------------------
# gnutls-cli -d 5 <remotehost> -p 21 --starttls-proto=ftp
|<2>| Initializing PKCS #11 modules
|<2>| p11: Initializing module: p11-kit-trust
|<3>| ASSERT: pkcs11.c:670
|<3>| p11 attrs: CKA_CLASS (CERT), CKA_CERTIFICATE_TYPE
|<3>| p11 attrs: CKA_TRUSTED
|<3>| p11 attrs: CKA_CERTIFICATE_CATEGORY=CA
|<3>| p11 attrs: CKA_CLASS (CERT), CKA_CERTIFICATE_TYPE
|<3>| p11 attrs: CKA_TRUSTED
|<3>| p11 attrs: CKA_CERTIFICATE_CATEGORY=CA
|<3>| ASSERT: pkcs11.c:2687
|<3>| ASSERT: pkcs11.c:2989
Processed 185 CA certificate(s).
Resolving '<remotehost>'...
Connecting to '<remoteIP>'...
error receiving 211 End


Do you think I'm missing something?
Comment 16 Nikos Mavrogiannopoulos 2015-11-03 04:41:03 EST
(In reply to Jordi Sanfeliu from comment #15)
> Second test with '--starttls-proto=ftp'
> ---------------------------------------
> # gnutls-cli -d 5 <remotehost> -p 21 --starttls-proto=ftp
> |<2>| Initializing PKCS #11 modules
> |<2>| p11: Initializing module: p11-kit-trust
> |<3>| ASSERT: pkcs11.c:670
> |<3>| p11 attrs: CKA_CLASS (CERT), CKA_CERTIFICATE_TYPE
> |<3>| p11 attrs: CKA_TRUSTED
> |<3>| p11 attrs: CKA_CERTIFICATE_CATEGORY=CA
> |<3>| p11 attrs: CKA_CLASS (CERT), CKA_CERTIFICATE_TYPE
> |<3>| p11 attrs: CKA_TRUSTED
> |<3>| p11 attrs: CKA_CERTIFICATE_CATEGORY=CA
> |<3>| ASSERT: pkcs11.c:2687
> |<3>| ASSERT: pkcs11.c:2989
> Processed 185 CA certificate(s).
> Resolving '<remotehost>'...
> Connecting to '<remoteIP>'...
> error receiving 211 End

The server replies with something unexpected. Could you take a capture of the transaction?
Comment 17 Nikos Mavrogiannopoulos 2015-11-03 04:41:35 EST
Or better just send the host which has the issue.
Comment 18 Jordi Sanfeliu 2015-11-05 04:00:03 EST
(In reply to Nikos Mavrogiannopoulos from comment #17)
> Or better just send the host which has the issue.

You can test it on the host 'www.fibranet.cat' (82.98.146.100).

It's a _genuine_ CentOS 6.7 with 'proftpd-1.3.3g-6.el6.x86_64' using a self-signed certificate.

Thanks.
Comment 19 Nikos Mavrogiannopoulos 2015-11-05 05:16:16 EST
Trying gnutls-cli --starttls --crlf and doing the auth tls negotiation manually shows that this server doesn't do auth TLS (or does and hangs). Openssl s_client -starttls doesn't work either.

Most likely the server supports ftps using a separate port and is broken when attempted to use auth tls.
Comment 20 Nicolas Thierry-Mieg 2015-11-05 06:12:48 EST
The proposed update filezilla-3.7.3-2.el6 does not work, and that makes sense: looking at the SRPM [1] we can see that the patch is not actually applied, the SPEC is missing a "%patch0 -p0" line in the %prep section !

Just apply the patch and all will be fine.


[1] http://koji.fedoraproject.org/koji/buildinfo?buildID=691857
Comment 21 Jordi Sanfeliu 2015-11-05 06:32:40 EST
(In reply to Nikos Mavrogiannopoulos from comment #19)
> Trying gnutls-cli --starttls --crlf and doing the auth tls negotiation
> manually shows that this server doesn't do auth TLS (or does and hangs).
> Openssl s_client -starttls doesn't work either.
> 
> Most likely the server supports ftps using a separate port and is broken
> when attempted to use auth tls.

The same server works finely with the Nicolas Thierry-Mieg's patch applied as stated in https://bugzilla.redhat.com/show_bug.cgi?id=1029485#c7
Comment 22 Nicolas Chauvet (kwizart) 2015-11-05 10:20:43 EST
(In reply to Nicolas Thierry-Mieg from comment #20)
> The proposed update filezilla-3.7.3-2.el6 does not work, and that makes
> sense: looking at the SRPM [1] we can see that the patch is not actually
> applied, the SPEC is missing a "%patch0 -p0" line in the %prep section !
> 
> Just apply the patch and all will be fine.
Good catch, fixing that and a push will be submitted later tonight.
Comment 23 Fedora Update System 2015-11-09 08:08:53 EST
filezilla-3.7.3-3.el6 has been submitted as an update to Fedora EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e180c5b56d
Comment 24 Jordi Sanfeliu 2015-11-09 10:19:50 EST
(In reply to Fedora Update System from comment #23)
> filezilla-3.7.3-3.el6 has been submitted as an update to Fedora EPEL 6.
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e180c5b56d

Finally, this new version works as expected.
Thanks.
Comment 25 Fedora Update System 2015-11-09 13:47:46 EST
filezilla-3.7.3-3.el6 has been pushed to the Fedora EPEL 6 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'yum --enablerepo=epel-testing update filezilla'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e180c5b56d
Comment 26 Ugo Bellavance 2015-12-08 21:27:35 EST
This testing version works for me too for FTPS server (port 1400)
Comment 27 Fedora Update System 2015-12-14 09:52:13 EST
filezilla-3.7.3-3.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.