Alcune buone informazioni anche nelle altre risposte, ma per rispondere direttamente alla tua domanda:

But what's to stop someone else from finding out the public RSA key that the site is using, and then replying with that same key, in order to pretend to be that site?

Un utente malintenzionato potrebbe eseguire questa operazione e potrebbe indurti a crittografare i tuoi dati utilizzando la chiave pubblica e inviandoli a loro. Tuttavia, senza la chiave privata corrispondente, questa informazione sarebbe inutile per loro perché non sarebbero in grado di decrittografarlo.

Le chiavi pubbliche sono esattamente questo: pubblico, destinato alla distribuzione. Avere una copia di una chiave pubblica non ti consente, da solo, di essere maschiato come proprietario della chiave. Ti dà la possibilità di crittografare i dati che invii al proprietario in un modo che solo il proprietario può decrittografarlo, usando la chiave privata che corrisponde alla chiave pubblica. Permette anche di decodificare i dati che sono stati crittografati utilizzando la chiave privata, dimostrando che i dati provengono dal proprietario della chiave privata, che è l'uso qui - la tua copia della chiave pubblica ti consente di essere ragionevolmente certo che il server comunicare con è affidabile (nella misura in cui ci si può fidare del proprietario della chiave privata per mantenere la segretezza di tale chiave privata).

Se il proprietario mantiene la chiave privata, privata, il sistema funziona come previsto.

L'articolo di Wikipedia su crittografia a chiave pubblica offre una buona introduzione su come funzionano cose come RSA, DSA ecc. .

L'impronta digitale è calcolata dalla chiave pubblica associata e può essere calcolata dal tuo computer. Se l'impronta digitale corrisponde a ciò che ti aspetti, la chiave che stai crittografando è quella appropriata per il tuo target.

Mentre si può segnalare una falsa impronta digitale, il fatto che possano essere calcolati indipendentemente dalla chiave posseduta effettiva rende praticamente inutile a meno che l'hash utilizzato per le impronte digitali sia abbastanza piccolo da rendere realisticamente possibile una collisione. Senza una collisione, qualsiasi scambio di dati verrebbe comunque crittografato sulla chiave pubblica appropriata (dal momento che hai verificato che quello che stai utilizzando corrisponde all'hash previsto) e non può essere decodificato senza la chiave privata corrispondente.

Il corto

Il MITM ha bisogno della chiave privata del server per posare come server e decifrare messaggi privati inviati al server. La chiave pubblica del server è per autenticazione dei messaggi firmati dal server e invio di messaggi privati a il server, quindi è ancora necessario verificare l'impronta digitale. Va bene se il MITM ha anche la chiave pubblica. Tutto ciò significa che il MITM può anche autenticare i messaggi dal server e invia messaggi privati al server.

In generale, se tutte le chiavi pubbliche sono conosciute da tutti, chiunque può autenticarsi le firme di chiunque e chiunque può inviare un messaggio privato a chiunque. Il privato controlli chiave firma e decrittazione, quindi idealmente nessuno può posare come un altro, e nessuno può leggere un messaggio privato inviato a un altro.

Il lungo

NB: Il seguente è un modello semplificato a soli fini didattici, destinato a illustrare il punto dell'impronta digitale chiave pubblica. Vedi questa altra domanda per ulteriori dettagli SSH .

Review. Per semplicità, invece di SSH su una rete di computer, prendi in considerazione a bacheca pubblica in cui gli agenti possono inserire note di testo. All'inizio, la tavola è vuoto. Gli agenti A e S vogliono comunicare e desiderano proteggere la privacy e integrità dei loro messaggi dall'agente dannoso M . Assumi le chiavi private sono noti solo ai rispettivi proprietari.

1. A post A_pub e S post S_pub .
2. A crittografa un messaggio con S_pub , firma con A_priv e post.
3. S decrittografa il messaggio con S_priv , verifica la firma usando A_pub .
4. S crittografa una risposta con A_pub , firma con S_priv e post.
5. Penso che tu sappia cosa fa A qui

L'agente M non può decodificare questi messaggi. M può postare messaggi crittografati a S o A . Tuttavia, un tentativo di falsificazione fallirebbe. Un messaggio firmato con M_priv non ha superato la verifica utilizzando A_pub o S_pub .

Ora per la funzione dell'impronta digitale della chiave pubblica. Supponiamo che M venga creato M_pub e M_priv , e tenta di imbrogliare A pubblicando M_pub come S_pub :

Dear A,

My public key is

   [contents of M_pub]

Love,
S

Se A ritiene questa bugia, A crittograferà i messaggi a S con M_pub in modo che M può decrittografarli e M può falsificare i messaggi come S usando M_priv . Tuttavia, se A ha l'impronta digitale di S_pub , A può confrontarlo con l'impronta digitale di M_pub e scopri la bugia. Quindi A rifiuterà di usare M_pub per crittografia dei messaggi a S e autenticazione dei messaggi da S .

Pertanto, quando SSH avvisa che l'impronta digitale della chiave pubblica è sconosciuta o cambiato, significa che potresti essere vittima di un attacco MITM. Se procedi, il MITM sarà in grado di decrittografare i messaggi e falsificare le risposte come server. Se il controllo delle impronte digitali ha successo, hai una sicurezza molto alta non sono una vittima del MITM, assumendo che l'impronta digitale che hai è reale le impronte digitali del server, le chiavi private (sia la tua sia quelle del server) in effetti privato, le implementazioni di SSH sono corrette, e la crittografia a chiave pubblica non è matematica compromessa.

L'autenticazione dell'host SSH si verifica durante lo scambio di chiavi . Lo scambio di chiavi avviene generalmente usando Diffie-Hellman , che consente di generare un segreto condiviso che può essere usato come una chiave di sessione simmetrica.

Assicurarsi che l'host abbia la chiave privata

All'inizio dello scambio di chiavi, viene negoziato un algoritmo di firma (che può essere RSA, DSA, ecc.). Alla fine dello scambio di chiavi , l'host utilizza questo algoritmo di firma con la sua chiave privata per firma i dati precedentemente scambiati. L'host invia la sua chiave pubblica e la firma al client (insieme al materiale Diffie-Hellman) e il client utilizza la chiave pubblica dell'host per verificare la firma. Poiché una firma può essere creata solo con la chiave privata, il client sa che l'host ha accesso alla chiave privata corrispondente alla chiave pubblica presentata dall'host.

Assicurati che sia l'host corretto

Il client ha alcuni modi per verificare che stia parlando con l'host corretto. Se è stato precedentemente collegato all'host, può abbinare la chiave pubblica dell'host a un database locale per assicurarsi che l'host abbia presentato la stessa chiave pubblica che aveva precedentemente.

Durante lo scambio di chiavi, l'host può anche scegliere di inviare un certificato firmato da una CA che il cliente si fida invece di inviare solo la chiave pubblica; il client può quindi verificare che la chiave pubblica dell'host sia stata firmata dalla CA (sebbene in pratica i certificati non vengano utilizzati con ssh molto spesso).

Se la chiave host non può essere verificata automaticamente, l'impronta digitale (hash della chiave pubblica dell'host) viene spesso presentata all'utente per consentire di verificarla manualmente out-of-band . Se accettata dall'utente, la chiave pubblica verrà generalmente archiviata per consentire la verifica automatica per le connessioni future.

Quindi per rispondere alla tua domanda: qualsiasi host può copiare la chiave pubblica di qualsiasi altro host, ma non sarebbe in grado di produrre una firma valida per lo scambio di chiavi e il client abortirebbe con un errore. Finché si verifica l'impronta della chiave host fuori banda (come si sta verificando sul sito Web, su HTTPS, spero), è impedito MitM.

Non mostra solo la chiave RSA. Inoltre, crittografa la comunicazione utilizzando una coppia di chiavi pubblica / privata (inclusa la chiave RSA). In questo modo sei sicuro che solo il server X può essere il server (poiché normalmente solo il server X ha la chiave privata).

Puoi leggere ulteriori informazioni sulle chiavi pubbliche / private qui . C'è un po 'di matematica in questione.

Se non mi sbaglio, la funzione utilizzata per generare l'impronta digitale utilizza la chiave privata per farlo. Quindi l'impronta digitale non può * essere ricreata senza la chiave privata.

* Esiste la possibilità di collisioni poiché l'intervallo di valori che le impronte digitali valide sono inferiori all'intervallo di valori di chiavi valide. È abbastanza raro che le impronte digitali siano ancora utili.

Non garantiscono la sicurezza contro l'uomo negli attacchi centrali. SSH utilizza l'handshake SSL / TSL come crittografia del traffico effettivo. Le chiavi SSH sono utilizzate solo per identificare che il client può iniziare la connessione. Il resto del traffico non utilizza la chiave privata SSH per crittografare il traffico. Quindi, l'unico modo per assicurarsi che il traffico SSH non venga eliminato da un attacco man-in-the-middle è l'utilizzo di una VPN in cui sia il server che il client dispongono di chiavi segrete private / private pre-condivise che non passare attraverso l'Internet / router / ISP pubblico in fase di esecuzione allo stesso modo delle chiavi di crittografia SSL / TLS. La coppia di chiavi SSL / TLS è più suscettibile a man-in-the-middle, in particolare con una bassa cifra di entropia.

link

link