19

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?

Rachel
  • 293
  • 1
  • 2
  • 6
  • 2
    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

5 Answers5

18

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.

  • 2
    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
  • 1
    I understand what you're saying. SFTP has more room for error and can be done in an insecure way...is all I'm saying. –  Nov 14 '12 at 16:30
  • assuming you use a CA... –  Nov 14 '12 at 16:39
  • 1
    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 –  Nov 14 '12 at 16:48
  • In terms of providing contextual support (like registration, password recovery, account access history and additional configuration by users) associating movement of data with processing of data (including content validation), leaving aside the treatment of dead letter drops as data diodes (they're not, BTW) 'https is a long way ahead of sftp – symcbean Oct 05 '15 at 21:09
18

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 https://your-secure-file-transfer.com but instead just type your-secure-file-transfer.com 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).

Community
  • 1
dr jimbob
  • 38,768
  • 8
  • 92
  • 161
  • 2
    Interestingly, we both picked one protocol over the other based (mainly) on what we thought a person would most likely screw up. –  Nov 14 '12 at 18:38
  • 2
    @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
3

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.

symcbean
  • 18,278
  • 39
  • 73
3

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.

Lee
  • 31
  • 1
0

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

MevanMartinez
  • 1