3 ms·

You have strong opinions about this, which makes me think maybe you can tell me details I didn't know about FTP. > It's an archaic protocol built around the li

You have strong opinions about this, which makes me think maybe you can tell me details I didn't know about FTP. > It's an archaic protocol built around the limitations of early-1980s systems. What were the limitations, and how did they shape the protocol? > protocol "feature" of having server responses be human-readable (and not machine-parseable) The responses are successfully parsed by quite a few clients, no? The fact that I as a person can easily read the output would seem in and of itself to be a positive quality. > control and data connections ... caused something like 2 decades of security problems, also makes it a nightmare to provision in modern networks I know little about configuring network security, can you tell me more here? The idea is that in passive mode the server has to pick and listen on a bunch of random ports and so the firewall can't unconditionally block them? Also you mention "modern networks" -- did it used to be easier to provision networks in the past and something has changed recently?

tptacek 8y ago
Someone else on HN probably has firsthand experience with the systems that birthed FTP, and I will be speculating a bit. But here's an example, and it's an interesting one because it infects TCP to this day: presumably because systems at the time didn't have workable socket multiplexing, FTP (and TCP) supports an "URGent pointer" that allows one TCP to flag another that important command-and-control data needs to be read during a file transfer --- this despite the fact that FTP is already (pointlessly) allocating an additional socket connection for each data transfer. The URG wart lives on in TCP to this day, unused by any modern protocol. FTP LIST responses are "successfully parsed" by predicting that servers will return a circa-1991 ftpd "ls" listing. Which means that to be parsed by those clients, you need to be bug-compatible with those servers. That was the point DJB was making with his (parsable) publicfile output. For a good starting point on FTP's security design, read up on [FTP bounce attacks]. But the key thing to remember is: this design is pointless. There is no reason for a file transfer protocol to be allocating new connections like this.

tptacek 8y ago

Someone else on HN probably has firsthand experience with the systems that birthed FTP, and I will be speculating a bit. But here's an example, and it's an interesting one because it infects TCP to this day: presumably because systems at the time didn't have workable socket multiplexing, FTP (and TCP) supports an "URGent pointer" that allows one TCP to flag another that important command-and-control data needs to be read during a file transfer --- this despite the fact that FTP is already (pointlessly) allocating an additional socket connection for each data transfer. The URG wart lives on in TCP to this day, unused by any modern protocol. FTP LIST responses are "successfully parsed" by predicting that servers will return a circa-1991 ftpd "ls" listing. Which means that to be parsed by those clients, you need to be bug-compatible with those servers. That was the point DJB was making with his (parsable) publicfile output. For a good starting point on FTP's security design, read up on [FTP bounce attacks]. But the key thing to remember is: this design is pointless. There is no reason for a file transfer protocol to be allocating new connections like this.