File transfer secure from a network security perspective

Question

Let's assume a simple network with a (Windows) server and a (Windows) workstation. Turns out the question of how to securely transfer files between the two isn't obvious considering:

1. I define secure in this context as preventing an attacker with control of any of the two devices to propagate his control to the second. Confidentiality and integrity of the data transmitted is secondary.
2. We want to set up a strict filtering between the two devices, using a L4 firewall. By strict I mean that we want to prevent any other use than file transfer, enforced by the firewall. Thinks of it as if I had only a firewall between 2 companies, and I was responsible for the security of the link between the two. Except, a hacker has control of one of the two companies, and try to get a hold on the second. Now, I can enforce the protocol used as the other company will comply and limit the use of the network ports that will be opened to only the agreed protocol, so that for example it will only use a HTTPS client to connect to port 443.
3. The protocol would be better based on open standards, and not have any internet dependency; also, bonus points if the solution has available implementation on Windows.
4. I am not considering the risk of vulnerability in either the client or the server.

2. prevents us from using a few classical protocols such as SMB, as this protocol is not dedicated to be a file transfer protocol but also resource sharing, control, etc. It also prevents us from using SFTP/SCP/rsync over SSH, as these are encapsulated over SSH, and we would not be able to distinguish between the two on a network level. Also, FTPS is awful in terms of firewall opening requests as it takes all the firewall unfriendliness of FTP.

I was thinking about a HTTPS server, because we could create a server that is purpose-specific so propagation of a threat would be made harder. But I would like the client to be able to remove files as well so some logic will be required and a specific app will probably need to be maintained. Would WebDAV over SSL with Digest authentication match the security requirements?

I am starting to feel like there is no easy answer except saying: we need to limit the emphasis on the network security, as there is no protocol that would allow us to ensure the level of security we want without imposing security requirements on the machines, and for example making sure a SSH server is properly configured to only allow SFTP. This is a shame as the original question is pretty simple.

Answer 1

From an L4 Firewall perspective, FTPS, HTTPS, and WebDAVS are indistinguishable from each other; SSH, SFTP, SCP, and RScync+SSH are also indistinguishable from each other. Additionally, from an L4 Firewall perspective, the TLS protocols are essentially the same as SSH based protocols, they're both tunneling protocol that can carry anything you put into them. In other words, yes, L4 Firewall is the wrong tool for the job.

What I would do if I were in your situation is to run a git server, over https, using Git SmartHttp/git-http-backend protocol. It ticks all the boxes:

1. Open protocol, open source implementation
2. It keeps history. You can choose to allow actual deletion, by allowing force push, or to disable force push and thus require explicit consent from both sides to actually delete from the commit history
3. Efficient transfer if most updates are diffable, and efficient enough even if the files are always completely different
4. Secured with TLS, and as it runs over HTTPS, and you can reverse proxy it with a webserver (e.g. Apache) if you want to. You can add any authentication you want that can be done over HTTPS using the webserver.
5. You can write a pre-receive or post-receive hooks to add any custom checking and additional behavior.

My second choices would be git over ssh, then rsync over ssh.

for example making sure a SSH server is properly configured to only allow SFTP.

This may be easier than you think. There are a number of FTP server software that only supports SFTP without SSH shell support, so you'd reduce the chance of misconfiguring them.