ftp over http...?

[johan.lindgren]

I need to be able to share a large bunch of files with a friend and so far the option was ftp.

Now I'm not that happy with ftp since I never ever make it work, since I want a connection over TLS and the ftp server is on my local network and so needs to be reverse proxied some how.
Next is that I would rather not really open yet another port to my system so the best deal I know of would be to transfer files over http(s) somehow.

I now wonder:

If I set up a ftp (non TLS) with an anonymous account, and then have my allready reverse-proxied webserver (apache or nginx) to somehow open it.
The webserver is restricted so none of it's pages are available without user/pass and it connects through https exclusevly.
Now, would this work to gain access to the ftp fairly securely?

I read somewhere about web based ftp clients, might that be a way?

[Hu]

Are you providing the files to the friend or is the friend providing the files to you? If you have the files and want the friend to receive them, there is no need to involve an ftp server at all. Make the files accessible to the web server, and let the friend download the files over https from the webserver. If your friend has the files and you want them, that gets a bit more complicated.

[alamahant]

If you need two-way sharing maybe use scp sftp or sshfs
It is fairly simple actually.
Also you can use NextCloud...
Use it over Docker.
It is really cool.
Plz let me know if you need help configuring any of the them.
Ah by the way ftp CAN be used nicely over ssl but since you are behind a firewall it would need opening a few ports on your router for ftp connections.
But you say you do NOT want to open any new ports to your firewall..
Ssh sftp and sshfs need at least an extra port opened(default 22),NextCloud uses 80 or 443

[szatox]

ftp over http

Isn't it called "webdav"?

Anyway, sftp seems to be the way to go for you. It can use a regular SSH, or you can even force-command sftp server (so nobody would be able to run any other command than file sharing stuff on that account), and whatever client you like. There is sftp command line client for linux, DEs like gnome come with an automagic mount daemon, winscp and filezilla on windows.

Easy to setup, uses only a single port in one direction (no need to "pierce firewalls") and your session is always encrypted.

[1clue]

ftp over http

Isn't it called "webdav"?

Anyway, sftp seems to be the way to go for you. It can use a regular SSH, or you can even force-command sftp server (so nobody would be able to run any other command than file sharing stuff on that account), and whatever client you like. There is sftp command line client for linux, DEs like gnome come with an automagic mount daemon, winscp and filezilla on windows.

Easy to setup, uses only a single port in one direction (no need to "pierce firewalls") and your session is always encrypted.

The server end needs to have a port open on the firewall. Both ways.

+1 for sftp. You only need to open port 22/tcp on your firewall, share your public ip address with your friend, create an unprivileged account for them and put the files in their $HOME. If they use Linux or Mac OS then they already have an sftp client (or scp which is the same thing). If they use Windows then you need something, usually people do something like FileZilla or putty.

Plain-old ftp is a dinosaur. It was made when the Internet was all in the USA, and only in government/educational sector/military. Firewalls existed but weren't widespread. FTP is NOT nat-friendly and has so many security holes you don't want to use it in any scenario at all anymore. Login information is passed in clear text, so anyone who is curious and has access to the path between source and destination can sniff your login information.

Any organization that wants to have some sort of security rating will not put ftp on their network, because it's an automatic fail -- for the entire network -- for any rating I've ever had anything to do with. If they must have an ftp server, then they'll usually host it on the cloud, or something like that.

[szatox]

sftp client (or scp which is the same thing)

Actually they aren't. The protocols differ, even though they both use ssh transport.
You can't scp files to a server with a force-command sftp-server.

Not a big difference from the end-user's perspective, but it can result in a "wtf is wrong with this thing" on the admin's end, so it's better to be aware of that.

[1clue]

sftp client (or scp which is the same thing)

Actually they aren't. The protocols differ, even though they both use ssh transport.
You can't scp files to a server with a force-command sftp-server.

Not a big difference from the end-user's perspective, but it can result in a "wtf is wrong with this thing" on the admin's end, so it's better to be aware of that.

Edit: I posted incorrect information and not much else in this post. Rather than try to fix it, I am replacing all of my text with this retraction. You can see the misinformation I provided in a post below if you want.

[alamahant]

I see a lot of ftp:// in distro mirrors..
But maybe everyone is right.
Ftp is obsolete.....
BUT for the shake of argument would

Code: Select all

force_local_logins_ssl=YES

enforce also logins to be encrypted?

[1clue]

I see a lot of ftp:// in distro mirrors..
But maybe everyone is right.
Ftp is obsolete.....
BUT for the shake of argument would

Code: Select all

force_local_logins_ssl=YES

enforce also logins to be encrypted?

Distro mirrors are unauthenticated and likely hosted on a public cloud somewhere.

In my opinion, ftp should cease to be distributed without warnings.

If you want the technical details of why ftp can't be used behind a firewall without a special hack, then you can google that and get a much better explanation than anyone here is likely to provide.

If you want security reasons then google can tell you endless information about that too.

Most people who set up file sharing want to keep their files private. This thread, talking about ftp and TLS in the same sentence, wants an encrypted transfer, which means they want security. In those cases, depending on the scenario expected, you might want any number of protocols, but most likely plain-old ftp is not going to work for you. The OP also mentioned a firewall, which pretty much eliminates FTP from the picture altogether unless you have an ftp server specifically hacked to work with a firewall which also must be specifically hacked to work with an ftp server. Now re-read that last sentence, and imagine a network security department head or maybe a third-party team reviewing the security of your site for some certification listening to it.

FTP protocol is extremely unfriendly toward firewalls, and it's extremely unfriendly toward any sort of secure environment. It does not work the way normal client/server code works. By default, the client opens a socket to the server (what you would expect) and does the authentication part, but then the server opens a separate (non-response) socket back to the client again. So your ftp client is a server as well as a client, and the server is a client as well as a server. Are you confused yet?

There have been a large number of hacks to clean things up since the protocol was first developed, including the PASV command which theoretically solves the double socket issue. The truth is though that ftp is so old and so full of vulnerabilities and patches for those vulnerabilities that you'd just as well start over with modern code because the entire protocol is broken and always has been.

[Hu]

Well, if you're going to be that specific about it, sftp is less secure than scp and will be phased out at some point soon.

The issue is that the sftp command doesn't verify the name of the file being transferred, so a hostile server can compromise the client system.

Do you have a source for this? I recall reading something similar on LWN, except that everywhere you wrote sftp, that article wrote scp, and vice versa.

[1clue]

Well, if you're going to be that specific about it, sftp is less secure than scp and will be phased out at some point soon.

The issue is that the sftp command doesn't verify the name of the file being transferred, so a hostile server can compromise the client system.

Do you have a source for this? I recall reading something similar on LWN, except that everywhere you wrote sftp, that article wrote scp, and vice versa.

That's disturbing. Googling it, I see you're right. I'll edit my message to prevent anyone from getting it wrong.