Bug 1029485

Summary: Filezilla 3.7.3 is unable to connect to FTP over explicit SSL
Product: [Fedora] Fedora EPEL Reporter: Henning Norén <henning.noren>
Component: filezillaAssignee: Nicolas Chauvet (kwizart) <kwizart>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: el6CC: jordi, kwizart, martin.kopal, nicolas.thierry-mieg, nils.henkel, nmavrogi, ubellavance
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
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 14:52:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
crude patch, accept all "NORMAL" ciphers none

Description Henning Norén 2013-11-12 13:13:13 UTC
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-13 01:15:33 UTC
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 23:37:34 UTC
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 13:19:36 UTC
Can you reproduce the issue with the recent gnutls/openssl updates ?

Comment 4 AZ 2014-02-03 15:17:04 UTC
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 21:13:41 UTC
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 21:15:06 UTC
Created attachment 864289 [details]
crude patch, accept all "NORMAL" ciphers

Comment 7 Jordi Sanfeliu 2014-07-28 13:37:19 UTC
(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 10:30:26 UTC
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 13:16:55 UTC
(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 14:11:00 UTC
I believe the patch in comment #6 is a pretty reasonable fix.

Comment 11 Fedora Update System 2015-10-14 20:17:41 UTC
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 15:47:37 UTC
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 14:58:31 UTC
(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 15:07:34 UTC
(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 15:59:51 UTC
(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 09:41:03 UTC
(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 09:41:35 UTC
Or better just send the host which has the issue.

Comment 18 Jordi Sanfeliu 2015-11-05 09:00:03 UTC
(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 10:16:16 UTC
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 11:12:48 UTC
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 11:32:40 UTC
(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 15:20:43 UTC
(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 13:08:53 UTC
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 15:19:50 UTC
(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 18:47:46 UTC
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-09 02:27:35 UTC
This testing version works for me too for FTPS server (port 1400)

Comment 27 Fedora Update System 2015-12-14 14:52:13 UTC
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.