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
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.
Thx for reporting this issue. I cannot expect to work on this anytime soon. If you can suguest a patch, that would be welcomed.
Can you reproduce the issue with the recent gnutls/openssl updates ?
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 !
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.
Created attachment 864289 [details] crude patch, accept all "NORMAL" ciphers
(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)
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.
(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.
I believe the patch in comment #6 is a pretty reasonable fix.
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
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
(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.
(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.
(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?
(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?
Or better just send the host which has the issue.
(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.
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 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
(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
(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.
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
(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.
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
This testing version works for me too for FTPS server (port 1400)
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.