Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My company works with financials, and we are required to transfer files containing non-public consumer information securely between our company and our clients.

The usual solution is to go with sftp for file transfers, however many of our clients are not tech-saavy, and getting them setup with sftp software and teaching them how to use it is very time consuming and often frustrating for both parties.

As an easy solution, I created a very basic website hosted over https that allows users to login using their ftp credentials and upload/download files through a web interface.

But can https be considered the equivalent to sftp as a way to securely transfer a file?

share|improve this question
Check whether whatever is requiring you to transfer data securely specifies a method or minimum requirement. Maybe run it by your legal department. – Mark Allen Nov 14 '12 at 21:13
up vote 16 down vote accepted

HTTPS and SFTP when used properly are equally safe. The underlying encryption algorithms in practice are both functionally equivalent -- neither can be broken in practice by directly attacking the cryptographic protocols.

However, in practice with non-tech savvy user, HTTPS is slightly weaker in my opinion.

There are attacks on both that can be launched on uncareful, non-tech savvy users. The attack on SFTP as Rell3oT said is that typically you initially do not know the public key of the SFTP when you first connect, and remember it for all subsequent connections (though the SSHFP DNS record defined in DNSSEC could solve this issue, but are not currently widely-used) . This means an attacker who rerouted internet traffic initially to their fake sftp server could capture your data, if they targetted the attack on someone connecting to the sftp site for the first time from a computer (that does not have the public key saved). This attack cannot happen on subsequent connections.

However, with https there are several more potential attacks introduced that non-tech-savvy users could get tricked into.

  1. The user may not go to but instead just type into the web browser (which by default goes to the http version). An attacker could wait for this case, and then capture this traffic and redirect it to their forged copy of that site; stealing the authentication information/financial data. (Yes a similar thing could happen with sftp being replaced with ftp; but as its typically done in a separate app that saves the connection information this seems less likely -- to go to the ftp version the user typically has to manually type in a different port number). You can fix this by requiring the site to have HSTS enabled. Unless they are careful about the URL bar displaying https, the user may not notice they are at an http site or a different URL. HSTS is only enabled on a small list of major websites by most browsers. Most of the time, it gets enabled in a web browser after successfully visiting the HTTPS site the first time (where there is a header to remember that this site must always connect over https); giving functionally equivalent security to SFTP.
  2. A non-tech savvy user's web browser is less secure than your standard SFTP client. Users often install various browser extensions that have the ability to access all your internet activity to get some sort of functionality. This added-on functionality may come with a secret attack; e.g., steal session cookies, information entered on forms (like their password), etc that eventually gets sent back to the client author.
  3. The CA (or intermediate CA) could be compromised at any date and attackers could get browser-trusted certificates that allow them to spoof your https without detection. This differs from SFTP again, where the sftp client remembers the public key for the site that it has seen before and alerts you if it has changed. (Web browsers will not do this; certificates are allowed to change as long as they are properly signed. Again this is not likely to change any time soon, as load balanced web servers generally all have different signed certificates.

All and all I'd say HTTPS is slightly weaker in practice than SFTP; while both are equally secure based on their cryptographic merits. If you train your users to check that https is present and at the correct domain, and additionally instilled some paranoia about using browser extensions on their work computers (or suggest using browsers' private mode typically with few extensions installed) it will be roughly equivalent (assuming you have the site setup correctly with HSTS/secure http-only cookies, etc).

share|improve this answer
Interestingly, we both picked one protocol over the other based (mainly) on what we thought a person would most likely screw up. – Rell3oT Nov 14 '12 at 18:38
@Rell3oT, I guess because both protocols are state of the art and no big security flaws are known for them, so the "next level" is the biggest security issue: the human being using the system. – Manuel Faux Nov 14 '12 at 20:20

Yes. I would argue HTTPS is equivalent or better than SFTP.

HTTPS uses a central certificate authority where SFTP does not. There is a risk the first time you authenticate with SFTP. HTTPS' use of the trusted third party prevents that risk.

It is important to note that (assuming a secure channel is established) SFTP and HTTPS are equally secure.

share|improve this answer
I would not generally say that a PKI is more secure. I would say you move your trust away from the operator of the system you want to communicate with, to the operators of the certificate authorities. Just the fact that there is no need for checking hashes does not make the system per se more secure. – Manuel Faux Nov 14 '12 at 16:12
I understand what you're saying. SFTP has more room for error and can be done in an insecure all I'm saying. – Rell3oT Nov 14 '12 at 16:30
assuming you use a CA... – Rell3oT Nov 14 '12 at 16:39
I think it can be broken down to something like "usable security". HTTPS can be made secure for non-technical-aware users easier than SFTP. But this does not mean that one protocol or one verification method is more secure than the other one. – Manuel Faux Nov 14 '12 at 16:43
Well said and exactly what I meant. :D – Rell3oT Nov 14 '12 at 16:48

HTTPS and SFTP differ in one very important way that, in my opinion, tilts the advantage significantly toward HTTPS: streaming data versus file transfer. A proper HTTPS connection between software services generates and transmits data incrementally, and doesn't require files at rest. On the other hand, SFTP by convention, practice and protocol requires files to be created and stored while being transferred (sending and receiving) -- so two at rest copies exist simultaneously.

Zero files at rest versus two files at rest is huge, particularly when put in context with the CA issue. HTTPS wins.

share|improve this answer

An answer giving some good reasons for SFTP has been accepted but it seems that nobody has put forward many the advantages of using https.

First, the availabilty of tools for 'https is much wider than for SFTP. It has much wider usage, so should be a more mature technology.

It's much easier to integrate tools from different vendors without compromising on encryption strength.

Moving files around alone has little benefit. It's when the data is processed that the value is realised. It is much easier to integrate processing with 'https transfers than with SFTP.

Http (and 'https) has a vocabulary for describing how the data should be interpreted (encoding, language, mime type) and processed (get, post, put, delete) which are not available in SFTP.

Http(s) provides a mechanism for providing contextual information alongside the transfer capability - documentation, information about account usage, account management, problem logging and more which is not available is SFTP.

Often the weakest link in a secure network is the users. Users have a much better understanding of HTTPS than of SFTP. Client certificates/keys add some complexity to this but telling people to check for a green background in the URL is a lot easier than talking them through enabling strict host checking and dealing with the rollover if they ever change.

And https certificates have an expiry date, and mechanism for oob verification (HSTS pre-registration).

That you are asking the question makes me think your a security analyst / system administrator. From that viewpoint the differences might not be so clear. Go talk to your developers and users and you'll get a very different picture.

share|improve this answer

I would comment without an answer, but I first need to establish my reputation. SFTP can be made to have a smaller attack surface. HTTPS implies a web server process and that is itself exposed to attack. SFTP seems a simpler setup.

To-do List: -dedicate one host for SFTP -run rcconf and kill all your unneeded services -create an sftp users group and chroot them -enable logging of SFTP user actvities separate in verbose mode -create crowned subdirectories for each of your clients/partners -backup your data to a different host

share|improve this answer

HTTPS all the way. Anything based on FTP is nearly 45 years old and comes with a ton of baggage from the era when people were just figuring out this stuff. It's not an accident that HTTP triggered one of the biggest information revolutions in human civilization while FTP barely manages to survive as used protocol. There is nothing that you can do with (S)FTP(/S) that you can't support with HTTP(S). The converse is not true.

I don't really understand a lot of the answers here since they center around the browser. HTTPS is used for much more than the browser. On the other hand, FTP is currently supported by major browsers.

As stated by other responses, the connection security between HTTPS and SFTP should be equivalent. The security problems with FTP (secured or not) are related to the overall design of the server implementation. There is (in my experience) always the concept of a directory that contains files. Unless you disable these features (assuming you can), users can both read and write to these directories. Even if all the permissions setup correctly, there are many examples of FTP servers having authorization flaws that allow users access to more than what they should have. Files are stored in the clear in these directories unless you use an additional layer of encryption. Where I work we are required to use PGP file encryption with SFTP for this reason.

EDIT: I should add that since SFTP is based on SSH, it (AFAIK) requires the creation of a system account on the server which opens up a huge slew of potential problems. If you are going to SFTP on the public internet, you should at the very least have a dedicated server strictly for this purpose and treat them mush like you would treat public HTTP servers in a DMZ. That is, connections coming are granted very little trust.

You can absolutely set up a web site that supports the functionality of FTP i.e. allowing if you list of the URIs that can be accessed. But you need to actually make an effort to do this. With FTP based tools, you need to go out of you way to remove these features. Additionally, the HTTP based solution allows for authentication and authorization at every step. So if you allow the user to list files they shouldn't see, they don't automatically get the right to retrieve them. If all you want is to let them POST a document, then just do that and don't support anything else.

EDIT: The statement that SFTP has nothing to with FTP is making a distinction without a difference with regard to the core of my argument. SFTP and FTP share almost the exact same meaning for the following commands:

bye (exit, quit)
rm (delete)

That is, the basic "file transfer" design i.e. a directory on a system that you manipulate remotely is functionally equivalent. It's this design that is the issue. However I should note that SFTP also provides the following which are fun to ponder from a system security perspective:

! (drop to a shell)

If you are using SFTP and exposing it to the internet, you better be sure you have these remote user accounts configured properly.

EDIT: Given the apparently lack of understand of the risks of SFTP here's some discussion about the kinds of things you have to consider when you give someone a server account (as required for SFTP):

I should probably qualify this a little. SFTP is a perfectly good way for a known system user to move files back and forth to a system. However, if your goal is to allow untrusted or semi-trusted users to send you data, you are most likely violating the Principle of Least Privilege and opening up a large number of vectors of attack unnecessarily. Given how trivial it is to implement this functionality securely with HTTPS and avoid these issues, it makes no sense to choose SFTP if HTTPS is an option.

share|improve this answer
Just a quick comment. SFTP is completely unrelated to FTP, and was developed independently as part of the SSH protocol. The only thing that's the same is literally they both have FTP in the name. – Steve Sether Oct 5 '15 at 17:28
I idsagree. It is not unrelated as it functions pretty much exactly like FTP. You have a one or more directories that you connect to. I image is where the name comes from. It's this design that makes it inferior to the stateless HTTP protocol which comes with no implicit assumptions about storage. – JimmyJames Oct 5 '15 at 18:32
No Jimmy, just because it uses the same words does not mean its the same. And old is not necessarily bad. – symcbean Oct 5 '15 at 21:04
That's a semantic argument. It's not bad because it's old. It's bad because the design is inherently flawed. People didn't consider security at the time it was created. It wasn't part of the requirements. Unfortunately, problems created by statefulnes and the lack of protection for data at rest cannot eliminated by building the same design on top of system shell, secure or not. Building SFTP on top of SSH creates a new type of risk that didn't exist with FTP in that it supports arbitrary commands. – JimmyJames Oct 5 '15 at 21:28
FTP and SFTP give no meaning whatsoever to lcd or help -- that's the user interface of your particular client. – Ben Voigt Oct 5 '15 at 21:32

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.