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: | filezilla | Assignee: | Nicolas Chauvet (kwizart) <kwizart> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | el6 | CC: | 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
Henning Norén
2013-11-12 13:13:13 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. 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. |