4

For FTPS, we rely on the DNS and public PKI to authenticate the FTP server when we first connect. On the first connection, foo.example.com resolves to 1.2.3.4 and my connection comes back encrypted by a private key that I can validate is truly owned by foo.example.com (more or less, given the issues with PKI).

But how does this work with SFTP (yes, I know it's SSH but I'm not terribly familiar with that)?

I know there are two common ways people use SFTP with regards to this question:

  1. Client is aware of the key to be used for connection in advance. This makes sense and is obvious to my question. I'm not asking about this.
  2. Client is unaware of the key to be used for the connection in advance. Instead they have a username and a password. This is the scenario where I'm specifically asking about.

For that second scenario, when I first connect to the SFTP server, how can I be sure it's truly my intended server and not some other server performing a MITM attack to then get my password (hopefully this is hashed & not easily stolen) and/or data?

I found this question but it doesn't seem to address the topic of server authentication, just client authentication.

4

SFTP is the exact same security model as SSH, as it uses SSH as the underlying transport. With SSH, the first time you connect to a server, the client should present you with the sever's fingerprint. Which looks like this:

The authenticity of host 'myserver.com (123.45.67.89)' can't be established. 
RSA key fingerprint is 12:34:56:78:9a:bc:de:f0:0f:ed:cb:a9:87:65:43:21. 
Are you sure you want to continue connecting (yes/no)? no

For best security, users should compare this host key/fingerprint with the real server's fingerprint, which should be obtained through another secure, out of band channel. This is often a website where the server owner published their fingerprint or may also be through face to face meeting or a phone call or by another trusted user who had previously done the check. SSH itself doesn't specify how this out of band communication of the fingerprint should be done.

Often though, people simply trust whatever fingerprint they're presented with. When this happens, SSH clients usually remembers the fingerprint so future reconnection should connect automatically without asking the user to check the fingerprint again, and the client would usually give a big warning message if the server's fingerprint had changed. When used with this model, SSH's security model essentially is TOFU (trust-on-first-use).

Alternatively, SSH also supports using SSH certificates to authenticate servers. The way SSH certificates works is essentially the same as x509 certificate, but it uses a simpler, incompatible certificate format. When using an SSH certificate, you assign a trusted user to act as your certificate authority, which can sign certificates for the servers and/or users. With this method, users only need to install the single CA certificate instead of verifying every server host keys individually.

  • I think this answers my question very well. Thank you for this explanation. – Jaxidian Nov 10 '17 at 18:08
2

In addition to Lie Ryan's excellent answer, ssh host keys can also be published in DNS using SSHFP entries. If the zone is properly configured with DNSSEC and the resolver supports DNSSEC, you can even set the VerifyHostKeyDNS option to yes in your ssh_config file to automatically trust it (like you would in the public PKI).

  • While I accepted Lie Ryan's answer, I think this is some great additional information. I need to research this more. Thank you! – Jaxidian Nov 10 '17 at 18:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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