It may be a good idea to restrict the number of allowed FTP connections by default, similar to the way we restrict the number of allowed HTTP connections per server to 6, as per the default value of network.http.max-persistent-connections-per-server. Currently we do not set a default maximum allowed number of FTP connections per server.
Created attachment 784021 [details] Code used in demonstration at Black Hat 2013 At Black Hat 2013, Jeremiah Grossman and Matt Johansen gave a talk titled "Million Browser Botnet", and as part of the talk, pointed out that while Firefox limited the number of http connections per server to 6, the number of ftp connections was not, and they used the code in this photo to demonstrate that they could overwhelm an Apache server. This was not the main focus of the talk, but we should still consider restricting this number.
CC'ing some networking folks for their thoughts.
I'm not a networking person if I can avoid it. But I hear dougt knows something about ftp... ;)
We don't really want a separate pool for each protocol we support, we want a general limit on connections of any type to avoid swamping hosts.
Summary: Set a default maximum allowed number of FTP connections per server → Enforce a maximum allowed number of connections per server regardless of protocol
dveditz, this isn't the same bug. I am a lot more concerned about making that sort of change.
Assignee: doug.turner → nobody
Summary: Enforce a maximum allowed number of connections per server regardless of protocol → Set a default maximum allowed number of FTP connections per server
jason, I am not convinced on some arbitrary limited for the number of total socket connections per host. But restricting ftp feels like a win. Thoughts?
can anyone think of a non ftp protocol? WS has a mechanism.. rtc iirc too, we killed gopher.. and sysapps have chrome privs. http limits are pretty complicated (6 is really not a hard limit).. I'd like to see a separate patch for .. as WS vs http sharding shows often this is something not necessarily meant to be shared logic.
all of the webrtc stuff. no idea how that would interact with some global limit. i'd much rather restrict ftp, than try to figure out the *right* global limit across ff.
in comment 7 I meant to say I'd like to see a patch specific to ftp (as would dougt).. the limits of a soft keyboard defeated my clarity.
I agree an FTP-specific patch is probably a good idea.
Not sure if we should track this, nominating anyway. It'll be good to have a quick follow-up post-Black Hat, and also nice to have this in the next ESR, version 24.
status-firefox23: --- → affected
status-firefox24: --- → affected
status-firefox25: --- → affected
status-firefox26: --- → affected
tracking-firefox24: --- → ?
tracking-firefox25: --- → ?
tracking-firefox26: --- → ?
non-critical security fixes shouldn't end up on the tracking list. please re-nominate if this gets a sec-high/sec-critical rating.
tracking-firefox24: ? → -
tracking-firefox25: ? → -
tracking-firefox26: ? → -
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: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.