4 ms·

I agree with your sentiment, but have found that enterprise partners are flabbergasted when I recommend using HTTPS for file exchanges, because they believe SFT

I agree with your sentiment, but have found that enterprise partners are flabbergasted when I recommend using HTTPS for file exchanges, because they believe SFTP is the only way to accomplish this. When we control both sides of the communication (via an on-premise virtual appliance) we always use HTTPS, and only support SFTP where a customer is wanting to push data to us and this is the only way they can do it (because there's usually an ops-adjacent team that manages all file exchanges and they use software that only does SFTP--as far as they know). In your (Matasano/Latacora) experience, does SFTP register as a security risk / exposure, or does it check the box as long as they aren't using FTP/FTPS?

tptacek 8y ago
Exposing SFTP is like exposing SSH. We're generally not happy about it.
- derefr 8y ago
  How about when SFTP is treated as an alternative exposed protocol for your existing daemon to speak, with your program embedding an "SFTP-app framework" and giving it a delegate router/handler module—much like you'd embed a web-app framework and give it a delegate router/handler module? I'm mostly thinking of Erlang's `ssh_sftpd` application here, where your application can "drive" it by exposing a "file server" for it to talk to as if it was the filesystem.
  - tptacek 8y ago
    That seems like the worst of both worlds: a custom application and an SFTP server exposed to the world. We would not be thrilled about this. We'd secure it if it had to exist and be secured (sometimes, financial providers use SFTP to do batch job submissions), but would never recommend it.
    - derefr 8y ago
      SSH is harder to secure than TLS, I admit. Sometimes security doesn't matter, though. Picture a "web-app" like an APT package repo host. (I know the reference impls of ALT hosts are essentially static-site-generators, but ignore that, and imagine an impl that's a web-app with dynamic business logic to expose the relevant routes.) Such a web-app can be served over plain HTTP. Not even an MITM can exploit an APT client, since it looks for specific files on the server and then checks those files' signatures against a local GPG database. What would be wrong with having this web-app also be an "SFTP-app"? Or an "FTP-app"? Or even a "telnet-app"? In all these cases, it'd just be a virtual filesystem being exposed over a wire protocol where the security of the wire protocol is immaterial. That's more in line with what I was picturing, here. You know how (public) S3 files can be retrieved over HTTP, but also over BitTorrent? Picture adding SFTP to that, as another option. That kind of API. --- For the situations where the service would benefit from security, though, you can still just obviate the need for relying on SSH's security specifically. For example, you can expose your SSH server only over a VPN. (I know a lot of people do this, though I personally find it to be more of a hassle than just correctly configuring SSH.) Or you can expose your SSH server behind an stunnel instance, thereby reducing your configuration work down to just "setting up a TLS-terminating load-balancer", that can then be shared between HTTPS and SSH traffic. --- Or, if it's just that you don't trust the Erlang SSH impl, you could just hack up OpenSSH to act as an "SSH terminator", forwarding the SSH-channel flows out of each SSH connection, as regular (auth-headered) TCP connections to your backend. Sort of like an fCGI server for SSH. I'm pretty sure the only reason nobody has done this yet is that no language (other than Erlang) has batteries-included support for speaking the server-side of SFTP.
    - helper 8y ago
      We have customers that batch upload data to our cloud service. We originally only offered HTTPS uploads but found a significant number of our customers really preferred SFTP workflows. My best guess as to why is that WinSCP provides a comfortable UI paradigm and there isn't an equivalent (well known) windows GUI for doing HTTPS uploads. Our SFTP server is written in go and exposes a VFS that has nothing to do with anything on the local file system. It doesn't even allow you to download the files you just uploaded in the same session. Of course things like the recent libssh CVEs should make anyone exposing non-standard ssh services to the internet a bit nervous.

tptacek 8y ago

Exposing SFTP is like exposing SSH. We're generally not happy about it.

derefr 8y ago
How about when SFTP is treated as an alternative exposed protocol for your existing daemon to speak, with your program embedding an "SFTP-app framework" and giving it a delegate router/handler module—much like you'd embed a web-app framework and give it a delegate router/handler module? I'm mostly thinking of Erlang's `ssh_sftpd` application here, where your application can "drive" it by exposing a "file server" for it to talk to as if it was the filesystem.
- tptacek 8y ago
  That seems like the worst of both worlds: a custom application and an SFTP server exposed to the world. We would not be thrilled about this. We'd secure it if it had to exist and be secured (sometimes, financial providers use SFTP to do batch job submissions), but would never recommend it.
  - derefr 8y ago
    SSH is harder to secure than TLS, I admit. Sometimes security doesn't matter, though. Picture a "web-app" like an APT package repo host. (I know the reference impls of ALT hosts are essentially static-site-generators, but ignore that, and imagine an impl that's a web-app with dynamic business logic to expose the relevant routes.) Such a web-app can be served over plain HTTP. Not even an MITM can exploit an APT client, since it looks for specific files on the server and then checks those files' signatures against a local GPG database. What would be wrong with having this web-app also be an "SFTP-app"? Or an "FTP-app"? Or even a "telnet-app"? In all these cases, it'd just be a virtual filesystem being exposed over a wire protocol where the security of the wire protocol is immaterial. That's more in line with what I was picturing, here. You know how (public) S3 files can be retrieved over HTTP, but also over BitTorrent? Picture adding SFTP to that, as another option. That kind of API. --- For the situations where the service would benefit from security, though, you can still just obviate the need for relying on SSH's security specifically. For example, you can expose your SSH server only over a VPN. (I know a lot of people do this, though I personally find it to be more of a hassle than just correctly configuring SSH.) Or you can expose your SSH server behind an stunnel instance, thereby reducing your configuration work down to just "setting up a TLS-terminating load-balancer", that can then be shared between HTTPS and SSH traffic. --- Or, if it's just that you don't trust the Erlang SSH impl, you could just hack up OpenSSH to act as an "SSH terminator", forwarding the SSH-channel flows out of each SSH connection, as regular (auth-headered) TCP connections to your backend. Sort of like an fCGI server for SSH. I'm pretty sure the only reason nobody has done this yet is that no language (other than Erlang) has batteries-included support for speaking the server-side of SFTP.
  - helper 8y ago
    We have customers that batch upload data to our cloud service. We originally only offered HTTPS uploads but found a significant number of our customers really preferred SFTP workflows. My best guess as to why is that WinSCP provides a comfortable UI paradigm and there isn't an equivalent (well known) windows GUI for doing HTTPS uploads. Our SFTP server is written in go and exposes a VFS that has nothing to do with anything on the local file system. It doesn't even allow you to download the files you just uploaded in the same session. Of course things like the recent libssh CVEs should make anyone exposing non-standard ssh services to the internet a bit nervous.