3

I have two machines in an internal network. One is a development server, which is isolated from external communications (neither through HTTP, HTTPS, SSH, etc). The last one is a production server (which already has a web server installed on it and it's handling a web application developed by another person) that is reachable from external networks through SSH and HTTP/HTTPS.

I have a routine that queries a database every day and generates an Excel report (.xlsx file) automatically. The information this report has is not critical or sensitive but is is private, anyway so I would like to keep it confidential if possible (so that no external agents could access to it).

I have the need to expose this Excel file so it can downloaded by a machine in an external network.

I have considered developing an small web application so that the external machine can connect to a fixed route through a browser (let's say ip_address/hash_salt) in order to download the new file everyday (by using an username and a password).

I ask this question in order to ask if there exists an alternative solution (maybe using SSH or SFTP or another protocol) which would allow me the to achieve the same in a secure way (I don't consider sharing a file through HTTP/HTTPS secure by itself, but I might me wrong, of course).

Is there a recommended way to achieve this file sharing? Please, let me know.

addictedtohaskell
  • 131
  • 2
  • 4
    Use SFTP/ssh. SFTP/ssh has proven, secure authentication. With keys, password auth disabled and fail2ban to limit retry rate, it's a secure solution. – vidarlo Sep 18 '17 at 16:53
  • There is no *most recommended way*. It depends on your actual security and usability requirements. For example you might decide that it is too risky to provide access to the machine from outside. Instead you could encrypt the file, push it to some external storage (cloud or similar), download it from there on the other system and decrypt it. This is more secure but lacks usability compared to direct access. – Steffen Ullrich Sep 18 '17 at 18:08
  • I understand that. I'm considering the most general case, where the user which will receive or access the file has almost zero IT knowledge, so the simpler, the better. It can of course access a website or open a software, but it might be too much to download a file, decrypt it and then open it (most likely due to the reason that it will not know what encryption is, why it is necessary, it will add an extra step, etc). – addictedtohaskell Sep 18 '17 at 19:57
  • @vidarlo how would you share the key? Is it mandatory for the user in the external computer to download or open a software GUI that works as a SSH client? Is there any other approach? – addictedtohaskell Sep 18 '17 at 20:00
  • The key fingerprint can be verified over the phone if you want. There'es no need for a gui; you can fully automate scp/sftp if you want. – vidarlo Sep 19 '17 at 04:38

1 Answers1

1

HTTPS with authentication

While HTTPS relies on the PKI infrastructure, making it potentially vulnerable to rogue CAs, it is perfectly adequate for "confidential but not highly sensitive" material. Using HTTP basic auth sends the password to the server, and when TLS is being used, it is additionally encrypted. This will provide you with a few guarantees which you will need when handling confidential information:

  • Is the entity requesting access allowed to access this material?
  • Can an authorized entity be sure the material being sent has not been tampered with on the wire?
  • Can an active/passive eavesdropper view the material as it is being sent to an authorized entity?

Any good form of authentication solves the first question, and TLS solves the second two. There is no need to use basic auth specifically (as it has its limitations, being rather simple and not ideal for storing sensitive user-created and potentially re-used passwords), so long as any simple authentication system is in place to ensure that only those who are supposed to download can do so.

Client certificates

Depending on how important the confidentiality of this material is, and partially on exactly how little knowledge "zero IT knowledge" is, you can also use encrypted client certificates. These are certificates generated either by you or by the client, and stored in the client's browser. It is not difficult for an end-user to set them up and use them, but it requires slightly more effort than the normal internet user is used to. It requires opening up the settings for your browser and importing the client certificate file, which will open a prompt for creating a new password to encrypt it. When they later access your site over HTTPS, their browser will ask them for the certificate password and, if it is correct, it will use the certificate to authenticate them to your website. This is by far the most secure browser-based authentication method, as the client authenticates itself to the server, and the server authenticates itself to the client.

Securing a TLS connection

If you do end up with using HTTPS, you should follow best security practices for TLS deployment:

  • Use a strong private key (2048 bits or larger RSA), signed by a reputable CA (e.g. LetsEncrypt).
  • Disable insecure cipher suites (such as those from SSLv2-3 and non-PFS modes).
  • Avoid using small or default moduli if using DHE, or just use ECDHE.
  • Pin the HTTPS state by using HSTS, ideally with HSTS preloading.
  • Use HPKP to pin the precise public key you use. This is safe as long as you use a backup key.
  • Use OSCP stapling to check for revoked certificates.
  • Make a tight CSP policy and other anti-XSS measures to reduce the risk of XSS attacks.
  • If practical and feasible, require users of the site use an up-to-date browser.
  • Test your site regularly with Qualys' SSL Test. Seriously. It is an amazing service.

While this is not all an absolute must, it does significantly improve the security of the whole situation closer to that of SSH, while still retaining accessibility for the technologically-handicapped. At an absolute minimum, the first four bullet points and the last bullet point should be followed.

Community
  • 1
forest
  • 64,616
  • 20
  • 206
  • 257