fireftp doesn't properly shut down TLS / SSL connections

REOPENED
Unassigned

Status

()

Core
Networking: FTP
P3
normal
REOPENED
9 years ago
2 months ago

People

(Reporter: quendi, Unassigned)

Tracking

1.9.0 Branch
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-backlog])

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.6) Gecko/2009020911 Ubuntu/8.04 (hardy) Firefox/3.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.6) Gecko/2009020911 Ubuntu/8.04 (hardy) Firefox/3.0.6

during the past months various FTP servers have changed their behavior how to shut down encrypted connections. this has been inspired by a change in the filezilla ftp client implementation, see http://forum.filezilla-project.org/viewtopic.php?f=2&t=7688

vsftpd since version 2.0.7 also changed the way tls connections are closed. since then fireftp, a popular ftp addon for firefox, is awfully slow. this has been reported here: https://www.mozdev.org/bugs/show_bug.cgi?id=20043
since fireftp uses the mozilla framework for ssl bugzilla.mozilla.org is the right place to report the bug.

from what i've seen the problem is as follows:
# fireftp opens an encrypted connection
# command channel (e.g. authentication or noop) works fine
# when you do a directory listing or file transfer it opens a new data connection using passive ftp
# the server replies with the requested data on the new conncetion and sends a tls close notify
# fireftp simply acks this and waits for more data
# after 5 minutes the server times out and sends a fin/ack packet
# fireftp closes the connection using fin/ack and finally displays the directory / dowloads the file

this means you have to wait 5 minutes for each directory listing or file transfer!

i'll attach an decrypted wireshark screenshot of the data connection

Reproducible: Always
(Reporter)

Comment 1

9 years ago
Created attachment 362167 [details]
wireshark screenshot of the data connection
Does this happen without Fireftp ?
If not: what is Fireftp doing different from the Mozilla ftp implementation ?
Example FTP URL ?
(Reporter)

Comment 3

9 years ago
(In reply to comment #2)
> Does this happen without Fireftp ?

it can't happen without fireftp since firefox only offers a standard (non ftps) client.

> If not: what is Fireftp doing different from the Mozilla ftp implementation ?

don't know, this is what the fireftp maintainer says at https://www.mozdev.org/bugs/show_bug.cgi?id=20043
"FireFTP just runs off of the Mozilla APIs as far as sockets and SSL and the
like is concerned.  This sounds like something that should be handled at that
level."

> Example FTP URL ?

you could try lnxnt.org, it runs vsftpd 2.0.7 and currently has tls for anonymous users enabled.
We don't accept extension bugs in bugzilla unless the developer of that addon explains what he is doing. Only with this information a Gecko developer can deceide if the bug is valid. You can't expect that our developers waste their time with digging through every addon that gets reported here and 90% of such issues are bugs in the addon itself.

Comment 5

9 years ago
Matthias,
I'm the developer of FireFTP.  Sorry for not weighing in earlier.

The code in question is here:
http://www.mozdev.org/source/browse/fireftp/src/content/js/connection/dataSocket.js?rev=1.52

Basically, all FireFTP does is, when it comes to SSL sockets:
this.dataTransport = this.transportService.createTransport(["ssl"], 1, this.host, this.port, proxyInfo);

There isn't anything that the extension does beyond that in messing around with the socket.  It seems that something underlying in Mozilla's socket code is conflicting with vsftpd patched code.

Is vsftpd at fault or is Mozilla code at fault?  I'm not sure - I think a networking engineer at Mozilla might need to take a look.

FWIW, my guess is this bug should be filed under Core->Networking.
Component: General → Networking
Product: Firefox → Core
QA Contact: general → networking
Version: unspecified → 1.9.0 Branch

Comment 6

9 years ago
Any new about that bug? I have setup a hosting server based on vsftp and I allow only TLS connections to it. So none of my clients can use fireftp....

Filezilla works nice with it....

Comment 7

8 years ago
(In reply to comment #5)
> Basically, all FireFTP does is, when it comes to SSL sockets:
> this.dataTransport = this.transportService.createTransport(["ssl"], 1,
> this.host, this.port, proxyInfo);

Why do you force passive mode for TLS/SSL connections? 

I think it may work without passive mode, may you have a try?

Comment 8

8 years ago
Anybody watching bugs here?

Comment 9

8 years ago
I'm watching this bug but I'm not one who could fix this.  Somebody from Mozilla needs to look into it.

Comment 10

8 years ago
Hi, I have also problem with FireFtp connecting to FTP+TLS server. I can provide Mozilla team with FTP+TLS testing account and extensive debugging outputs if required.

Comment 11

7 years ago
A year ago that bug was reported and documented but:

1- it is still at the UNCONFIRMED state

2- nobody at Mozilla seems to have had a look at it

When will firefox properly implement ftp over ssl/tls? Is it planned?

Comment 12

5 years ago
November 2012 and this problem is still there with fireftp when using "Auth TLS(Best)"

After the 5min timeout, vsftpd outputs the following error:

522 SSL connection failed; session reuse required: see require_ssl_reuse option in vsftpd.conf man page
421 Data timeout. Reconnect. Sorry.

But I have require_ssl_reuse=YES and tried NO in my vsftpd.conf file, but it doesn't seem to matter for fireftp. FileZilla works great either way.

Almost a year since the last post on this bug, is there any hope of it getting fixed?

Updated

5 years ago

Comment 13

4 years ago
mmalmeida added the following comment to Launchpad bug report 308952:

My team is experiencing the same problem, which seems to render fireFTP useless.

Any idea what is keeping this from being fixed?

-- 
http://launchpad.net/bugs/308952

Comment 14

3 years ago
This annoying problem still exists
Component: Networking → Networking: FTP
Whiteboard: [necko-backlog]
We are in a period where ftp is clearly deprecated and in general, making changes to the code is riskier than letting it ride unless there is a patch and reviewer available to make a good judgment about it. So I'm going to wontfix ftp bugs related to enhancements, interop errors, etc.. We will be better off putting our energy into including a different js based ftp stack.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
ignore comment 15 - this bug wasn't supposed to be in that list
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WONTFIX → ---
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
You need to log in before you can comment on or make changes to this bug.