Closed
Bug 478322
Opened 15 years ago
Closed 5 years ago
fireftp doesn't properly shut down TLS / SSL connections
Categories
(Core Graveyard :: Networking: FTP, defect, P3)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: quendi, Unassigned)
References
Details
(Whiteboard: [necko-backlog])
Attachments
(1 file)
260.73 KB,
image/png
|
Details |
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
Comment 2•15 years ago
|
||
Does this happen without Fireftp ? If not: what is Fireftp doing different from the Mozilla ftp implementation ? Example FTP URL ?
(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.
Comment 4•15 years ago
|
||
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•15 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.
Updated•15 years ago
|
Component: General → Networking
Product: Firefox → Core
QA Contact: general → networking
Version: unspecified → 1.9.0 Branch
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....
(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 9•15 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•14 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•14 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•12 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?
See Also: → https://launchpad.net/bugs/308952
Comment 13•10 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•9 years ago
|
||
This annoying problem still exists
Updated•8 years ago
|
Component: Networking → Networking: FTP
Whiteboard: [necko-backlog]
Comment 15•8 years ago
|
||
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
Closed: 8 years ago
Resolution: --- → WONTFIX
Comment 16•8 years ago
|
||
ignore comment 15 - this bug wasn't supposed to be in that list
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WONTFIX → ---
Comment 17•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Comment 18•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
Comment 19•5 years ago
|
||
FireFTP is no longer supported.
Status: REOPENED → RESOLVED
Closed: 8 years ago → 5 years ago
Resolution: --- → INVALID
Updated•2 months ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•