SSH e man-in-the-middle

Naviga le tue risposte
4

Assumi il seguente scenario e, per favore, correggimi se sbaglio da qualche parte:

C'è un client e c'è un server SSH al quale il client si connette. C'è anche un man-in-the-middle (MIM) che è in grado di intercettare il traffico in entrata e in uscita del client.

Ora supponiamo che il client si connetta al server SSH per la prima volta e le informazioni sulla chiave pubblica del server non siano ancora nel file known_hosts. Il server invia la sua chiave pubblica al client, il client controlla il file known_hosts, non trova la chiave pubblica del server e quindi il server deve ora dimostrare la propria identità al client. L'identità è dimostrata con successo (usando la chiave privata del server), ma supponiamo che il client non memorizzi la chiave pubblica del server in known_hosts dopo (non è obbligatorio archiviarlo in known_hosts, per quanto ne so).

La prossima volta che il client si connette al server SSH, il man-in-the-middle (MIM) intercetta la richiesta di connessione del client e invia la propria chiave pubblica al client, per conto del vero server SSH. Il client riceve la chiave pubblica di MIM, ispeziona il file known_hosts e non trova la chiave pubblica ricevuta in quel file, quindi il "server" (MIM) deve dimostrare nuovamente la propria identità. Poiché la chiave pubblica del MIM è associata alla chiave privata corrispondente, MIM dimostra con successo la sua identità al client.

È possibile compromettere la sicurezza in questo modo? Correggimi se sbaglio da qualche parte per favore.

Qualcuno mi ha detto che il certificato del dominio del server è in grado di risolvere il problema, quindi in aggiunta vorrei capire lo scopo dei certificati host. Ho letto che il certificato è inserito nel file known_hosts proprio come la normale chiave pubblica. Ma che senso ha usare un certificato se possiamo usare la stessa chiave pubblica su tutti i server nel dominio e semplicemente mettere quella chiave pubblica nel file known_hosts del client? Apparentemente, se non ci sono ancora le chiavi pubbliche in known_hosts, l'attacco che ho descritto sopra è ancora possibile, e non importa se il server usa o meno il certificato.

    
posta mangusta 07.01.2018 - 09:24
fonte

1 risposta

3

Sembra che tu pensi che l'identità del server sia dimostrata dal server che dimostra che possiede la chiave pubblica presentata. Ma questo non prova l'identità del server dal punto di vista del cliente.

Una parte importante della convalida dell'identità dei server è che il client verifica la chiave pubblica del server rispetto a quella prevista. Ecco perché l'impronta digitale viene presentata al client per la convalida al primo collegamento o se la chiave è stata modificata. Ciò significa che l'impronta digitale o la chiave pubblica devono essere conosciute dal cliente in anticipo, vale a dire prima della convalida della chiave. Ciò che descrivi è invece fidarsi ciecamente di qualsiasi chiave presentata all'utente nella speranza ma non certezza che sia quella corretta ( TOFU - confida per il primo utilizzo ).

Someone told me that the server domain certificate is able to solve the problem

I certificati in SSH hanno un ruolo simile ai certificati in TLS (e quindi HTTPS ). Hanno una chiave pubblica e sono rilasciati e firmati da un'autorità di certificazione fidata dal cliente. In caso di autenticazione basata su certificato, il server presenta il certificato che include la chiave pubblica e la firma dell'emittente. La firma dell'emittente può essere utilizzata per convalidare che il certificato è stato emesso dall'autorità locale attendibile e quindi che la chiave pubblica nel certificato è in realtà la chiave del server prevista. Successivamente viene utilizzata la chiave pubblica come nella normale autenticazione basata su chiave, ovvero il server deve dimostrare di possedere la chiave privata per la chiave pubblica.

Con i certificati, quindi, il cliente non ha bisogno di conoscere tutte le chiavi del server in anticipo. È invece sufficiente affidarsi a un'autorità specifica per emettere e firmare i certificati corretti che includono le chiavi pubbliche dei server. Ciò lo rende più scalabile se hai a che fare con molti sistemi diversi, tutti gestiti da poche entità.

Per informazioni su come utilizzare i certificati in SSH, vedi ad esempio Come creare una CA SSH per convalidare host e client con Ubuntu .

    
risposta data 07.01.2018 - 09:42
fonte

Leggi altre domande sui tag

In che modo SSL implementa l'autenticazione del server? Come proteggere un contenitore TrueCrypt che consente l'accesso con più chiavi pubbliche SSH?