La domanda che ho è semplicemente come faccio a impedire un attacco MiTM su un certificato quando il lato server ne crea uno nuovo e tenta di inviarlo a un client? Il certificato viene crittografato da rsa e inviato o ...
La domanda che ho è semplicemente come faccio a impedire un attacco MiTM su un certificato quando il lato server ne crea uno nuovo e tenta di inviarlo a un client? Il certificato viene crittografato da rsa e inviato o ...
Hai due potenziali attacchi:
L'autore dell'attacco si presenta come un server falso e parla con il vero cliente, fornendogli un certificato errato o altri dati nefandi.
L'utente malintenzionato si presenta come un client fittizio e parla con il server originale, ottenendo un certificato valido con il nome del client effettivo ma con la chiave dell'attaccante.
Un attacco man-in-the-middle è quando l'attaccante esegue entrambi contemporaneamente. Tuttavia, ogni attacco è problematico di per sé.
Sconfiggi il primo attacco (impersonificazione del server), utilizza i meccanismi standard: fai in modo che il server utilizzi un certificato, rilasciato da una CA nota, che il cliente si fida. Tutti i siti Web HTTPS lo fanno. Ecco come, quando ti connetti a https://www.paypal.com , ottieni l'icona del lucchetto nifty e sai che stai davvero parlando al server di Paypal.
Per sconfiggere il secondo attacco, beh, spetta a te: il server sta creando e inviando un certificato a "un cliente che ha appena connesso". In che modo il server conosce cosa inserire nel certificato? Da dove viene la sua conoscenza dell'identità del cliente? Se, ad esempio, il "vero client" viene autenticato in virtù del fatto che è stata concessa una password di registrazione unica, la comunicazione avverrà all'interno di una connessione HTTPS. In tale connessione (dove il server è verificato come "vero" dal client, vedi sopra), il client invia la sua password di registrazione unica e il server, da quel momento in poi, sa che sta parlando al client previsto, e puoi mandargli un certificato o qualsiasi altra cosa desideri mandargli.
Usa HTTPS come suggeriva Tom Leek nella sua risposta. Inoltre, richiedi una password all'utente e rispedisci un file in formato PKCS-12 crittografato che viene crittografato utilizzando la password che hai ricevuto dall'utente. Il file PKCS-12 conterrà il certificato dell'utente e la chiave privata. Facoltativamente, puoi anche firmare il file PKCS-12 utilizzando il certificato del tuo server, anche se non penso sia necessario perché il certificato contenuto nel file PKCS-12 è già stato firmato da una CA attendibile e valida.
Ho postato questo come una risposta separata perché non ritengo che sia sufficiente inviare chiavi private su SSL quando esiste una procedura standard nota come PKCS-12 che viene utilizzata per proteggere le chiavi in alcuni casi, ad esempio quando inviarlo su reti non sicure. Tuttavia, se il tuo unico obiettivo è sconfiggere un attacco MITM, la risposta di Tom Leek potrebbe essere sufficiente. Se il tuo obiettivo è anche quello di inviare in modo sicuro un certificato e una chiave privata, ti suggerisco di rispondere.
Leggi altre domande sui tag server client tls certificates man-in-the-middle