GNOME Bugzilla – Bug 738948
gvfs-ftpd cannot connect to servers that require TLS protected control connection.
Last modified: 2014-10-22 21:17:31 UTC
Test plateform are: #1 Server: QNAP NAS with ProFTPD 1.3.2e Client: Debian SID with latest gnome packages (gvfs 1.22.1) #2 Server: Debian SID with latest ProFTPD package (1.3.5) Client: same as #1 Both platform uses the same SSL/TLS configuration (but for the keys and certs): Steps to reproduce: 1. Open nautilus (Files) 2. Select the "Browse network" option on the left panel 3. Click on the FTP server icon (advertised through UPnP) to browse its content. Expected result: Being able to actually browse the server content. Actual result: After a few seconds, a dialog appears with the messages: "Unable to access location" (nautilus message) "Operation failed" (gvfs message) (Approximate translation could not find the relevant messages in the source po files [neither in gvfs nor glib]) Alternate steps way to reproduce: 1. Open nautilus (Files) 2. Select the "Connect to a server" option on the left panel 3. in the dialog that opens, type in a valid url on the server (used ftp://<server>/<path>) and validate 4. in the next dialog, fill in authentication information and validate Expected result: Being able to actually browse the server content. Actual result: After a few seconds, a dialog appears with the messages: Oops! Something went wrong. Unhandled error message: %s (w. %s == "Operation failed" .) There are two failure modes here: - with ProFTPd 1.3.2e, the error occurs while trying to retrieve the server's features (FEAT command). Server will accept no commands at all before a AUTH command is issued. - with ProFTPd 1.3.5, while successfully answering to the FEAT feature the server will reject the next USER command, no AUTH command having been previously issued.
Dear gvfs developers, I am willing to provide a patch for this, but before starting to do some actual work on this, I would like to discuss what would be a proper solution. As a matter of fact some of the behaviour above might be regarded as ProFTPd defects. I don't think they are and reviewing the FTP and FTPS RFCs (2228 and 4217) I feel like there is room for interpretation there. Looking at http://tools.ietf.org/html/rfc4217#section-4.2, having a server enforcing an all encrypted connection is a scenario envisionned but the remainder of the rfc is not very clear on how. Notably with respect to answering to the FEAT command which the gvfs-ftp backend always issues right after connection (see https://git.gnome.org/browse/gvfs/tree/daemon/gvfsbackendftp.c?id=1.22.1#n114 ). Thus both ftp behaviour seems valid to me (by lack of spec). Currently if the FEAT command fails, the ftp backend aborts, plain and simple. I guess a fix could be: if the FEAT command fails try AUTH SSL and/or AUTH TLS if either or both AUTH SSL/TLS fail, then abort. This would solve the first failure mode. if the FEAT command succeeds and the AUTH is advertised in the features use it regardless of whether the user requested a secured connection or not This would improve privacy/security by default and remove the second failure mode. Question is: would this be a viable solution for you ? Regards, Nicolas.
Marking as a duplicate of bug 526582 (implement AUTH TLS support)... Also see https://bugzilla.gnome.org/show_bug.cgi?id=526582#c21 *** This bug has been marked as a duplicate of bug 526582 ***
Hey, would be good to have this feature. The suggested solution has to be tested, we can't tell whether the solution is viable or not yet. We have to be sure that we don't break access to servers which are currently supported. More in duplicated bug...
I guess, we should continue the discussion in bug 526582 (this bug falls in the problems pointed out in bug 526582 comment 21).