SSH: utilizzo di chiavi pubbliche e note-man-in-the-middle

Infine, penso di aver capito.

Prima di tutto - Ho confuso i protocolli ssh v1 e ssh v2 nella mia descrizione. L'autorizzazione challenge-response proviene da ssh v1.

Nel client ssh v2 si firma semplicemente un pacchetto specifico con la sua chiave privata e il server lo controlla usando la chiave pubblica memorizzata. Questo pacchetto è descritto in rfc, qui :

To perform actual authentication, the client MAY then send a
signature generated using the private key.  The client MAY send the
signature directly without first verifying whether the key is
acceptable.  The signature is sent using the following packet:

  byte      SSH_MSG_USERAUTH_REQUEST
  string    user name
  string    service name
  string    "publickey"
  boolean   TRUE
  string    public key algorithm name
  string    public key to be used for authentication
  string    signature

The value of 'signature' is a signature by the corresponding private
key over the following data, in the following order:

  string    session identifier
  byte      SSH_MSG_USERAUTH_REQUEST
  string    user name
  string    service name
  string    "publickey"
  boolean   TRUE
  string    public key algorithm name
  string    public key to be used for authentication

Quindi, il pacchetto firmato contiene "identificatore di sessione" che è calcolato come segue :

  H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K)
  <…..>
  mpint     K, the shared secret  

Cioè, la firma dipende dal segreto condiviso e i segreti condivisi sono diversi per P1 < - > S1 e S1 & lt ; - > S2 tunnel.

Usually, people recommend to use a single private-public key pair everywhere (if we're not talking about a possibility of compromising the private key)

Si noti che ci sono due coppie di chiavi coinvolte in una connessione SSH:

• uno per identificare l'host del server (il server ha la chiave privata);
• uno per identificare l'utente (il client ha la chiave privata), se si utilizza l'autenticazione della chiave pubblica.

I consigli che citi riguardano le chiavi utente. Avere una singola chiave privata per utente è un modello praticabile, anche se non lo consiglio particolarmente (il costo di avere coppie di chiavi separate per host o sito non è così elevato). Le chiavi del server, d'altra parte, non sono mai duplicate. Sono generati di nuovo quando il server SSH è installato.

Su questo argomento, oltre ai post che hai citato nella tua domanda, vedi anche Qual è la differenza tra i file authorized_keys e known_hosts per SSH?

Nell'attacco che descrivi, hai mescolato i ruoli delle chiavi. Queste sono le chiavi host, ssh_host_rsa e non le chiavi utente. Questo non è direttamente rilevante nel modo in cui funziona l'attacco che descrivi, ma potrebbe far parte della tua confusione.

Il punto fisso è al punto 3.3:

PC1 accepts S1_id_rsa.pub's fingerprint (as it's known)

Ci sono due casi.

• Se PC1 è collegato a S2 in precedenza, PC1 (o più precisamente l'account dell'utente su PC1) ha memorizzato la chiave pubblica ospite di S2 nel suo file known_hosts . Quindi, se S1 invia la chiave host di S2, il client SSH su PC1 rileverà che la presunta chiave host non corrisponde alla chiave host registrata e interrompe la connessione con un messaggio spaventoso:

  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
  Someone could be eavesdropping on you right now (man-in-the-middle attack)!
  It is also possible that the RSA host key has just been changed.
  

  L'attacco è quindi impossibile in questo scenario (a meno che l'utente non faccia in modo di bypassare il controllo - OpenSSH lo rende intenzionalmente difficile).

• Se PC1 non è mai connesso a S2, PC1 accetterà felicemente qualsiasi cosa S1 stia dicendo che è la chiave di S2. Poiché PC1 non ha alcuna conoscenza preliminare di alcuna associazione tra il nome S2 e un'identità crittografica, né alcun modo per contattare una terza parte fidata che conosce tale associazione (cioè un'infrastruttura a chiave pubblica), non c'è modo di impedire a questa attacco nel mezzo.

Il problema è che il client potrebbe sapere che sta parlando al server 1 a causa dell'uso del certificato del server 1. Se server1 ha un certificato valido che dice che sono server2, il client non sarebbe consapevole se prima non si fosse connesso a server2. La maggior parte dei client SSH tuttavia traccia l'impronta digitale del certificato a cui si connettono per un determinato server. Quando il client va a connettersi e termina con una connessione al server 1, anche se il certificato è firmato, l'utente probabilmente riceverà un avviso che l'impronta digitale è cambiata.

Come per una connessione nota a S1 che cerca di affermare di essere s2, se s2 conosce con precisione p1, s chiave privata, allora se 01 vuole parlare con s2 a s1 allora dovrebbe cifrare per s2 e s2 quindi criptare per p1 . Quando p1 non ottiene uno scambio di chiavi da s2, saprà che c'è un problema dal momento che s1 non può firmare uno scambio con p1 come s2.

In realtà si tratta di una vulnerabilità nota con certificati di crack nell'elenco di fiducia e del perché sono necessari elenchi di revoche.

Affinché questo attacco funzioni, devono esserci 2 fori:

1. PC1 deve pensare che stia comunicando con server2 mentre in realtà sta comunicando con server1.
2. PC1 deve avere S1_id_rsa.pub come certificato attendibile e punta all'indirizzo del server2 (l'altro PC1 saprà che sta parlando al server1 invece del server2 al punto 4.3).

# 1 può accadere su una rete non sicura, mentre # 2 può succedere solo quando è avvenuta una violazione precedente che ha permesso al server1 di inserirsi come parte fidata.