Come fa un client ad autenticare un server SFTP se non ci sono chiavi condivise in anticipo?

4

Per FTPS, ci affidiamo al DNS e al PKI pubblico per autenticare il server FTP quando ci connettiamo per la prima volta. Alla prima connessione, foo.example.com si risolve in 1.2.3.4 e la mia connessione ritorna crittografata da una chiave privata che posso validare è di proprietà di foo.example.com (più o meno, dati i problemi con PKI).

Ma come funziona con SFTP (sì, so che è SSH ma non ne ho molta familiarità)?

So che ci sono due modi in cui le persone usano SFTP per quanto riguarda questa domanda:

  1. Il cliente è a conoscenza della chiave da utilizzare per la connessione in anticipo. Questo ha senso ed è ovvio alla mia domanda. Non te lo chiedo.
  2. Il client non è a conoscenza della chiave da utilizzare per la connessione in anticipo. Invece hanno un nome utente e una password. Questo è lo scenario in cui ti sto chiedendo specificatamente.

Per quel secondo scenario, quando mi connetto per la prima volta al server SFTP, come posso essere sicuro che sia veramente il mio server e non qualche altro server che esegue un attacco MITM per ottenere la mia password (spero che questo sia hash e non facilmente rubato) e / o dati?

Ho trovato questo domanda ma non sembra affrontare l'argomento dell'autenticazione del server, solo l'autenticazione del client.

    
posta Jaxidian 10.11.2017 - 14:56
fonte

2 risposte

4

SFTP è lo stesso modello di sicurezza di SSH, poiché utilizza SSH come trasporto sottostante. Con SSH, la prima volta che ci si connette a un server, il client deve presentare l'impronta digitale del server. Che assomiglia a questo:

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

Per garantire la massima sicurezza, gli utenti dovrebbero confrontare questa chiave / impronta digitale host con l'impronta digitale del server reale, che dovrebbe essere ottenuta tramite un altro canale sicuro, fuori banda. Questo è spesso un sito Web in cui il proprietario del server ha pubblicato le proprie impronte digitali o può anche essere attraverso una riunione faccia a faccia o una telefonata o da un altro utente fidato che aveva precedentemente eseguito il controllo. SSH stesso non specifica come dovrebbe essere eseguita questa comunicazione fuori banda dell'impronta digitale.

Spesso, tuttavia, le persone si fidano semplicemente di qualsiasi impronta digitale con cui sono presentate. Quando ciò accade, i client SSH di solito memorizzano l'impronta digitale in modo che la riconnessione futura si connetta automaticamente senza chiedere all'utente di verificare nuovamente l'impronta digitale e il client di solito emette un grande messaggio di avviso se l'impronta digitale del server è cambiata. Se utilizzato con questo modello, il modello di sicurezza di SSH è essenzialmente TOFU ( fiducia al primo utilizzo ).

In alternativa, SSH supporta anche utilizzando i certificati SSH per autenticare i server. Il modo in cui i certificati SSH funzionano è essenzialmente lo stesso del certificato x509, ma utilizza un formato di certificato più semplice e incompatibile. Quando si utilizza un certificato SSH, si assegna un utente fidato ad agire come autorità di certificazione, che può firmare i certificati per i server e / o gli utenti. Con questo metodo, gli utenti devono solo installare il certificato CA singolo invece di verificare individualmente ogni chiave host del server.

    
risposta data 10.11.2017 - 15:19
fonte
2

Oltre all'eccellente risposta di Lie Ryan, le chiavi dell'host ssh possono anche essere pubblicate in DNS usando le voci SSHFP. Se la zona è configurata correttamente con DNSSEC e il risolutore supporta DNSSEC, puoi anche impostare l'opzione VerifyHostKeyDNS per yes nel tuo file ssh_config per fidarti automaticamente (come faresti nella PKI pubblica).

    
risposta data 10.11.2017 - 17:05
fonte

Leggi altre domande sui tag