Lo spoofing di un certificato firmato dalla CA è possibile?

L'handshake include questi passaggi (grezzi):

1. Il server invia la sua chiave pubblica.
2. Il client crittografa le informazioni di configurazione con quella chiave pubblica e lo invia di nuovo al server.
3. Il server decrittografa l'invio del client e lo utilizza per ricavare un segreto condiviso.
4. Ulteriori passaggi utilizzano quel segreto condiviso per impostare la crittografia effettiva da utilizzare.

Quindi la risposta alla tua domanda è, dal momento che un impostore non può eseguire il passaggio 3 (poiché non ha la chiave privata) non può mai passare al punto 4. Non ha il segreto condiviso, quindi non può completare l'handshake.

Asudhak, non sentirti male se questo è un po 'confuso. Inventare crittografia asimmetrica è stato un enorme passo avanti in Matematica. Sembra molto contro-intuitivo se non addirittura impossibile quando lo si incontra per la prima volta.

Quando un client (spesso un browser Web) e un server (spesso un browser Web) desiderano stabilire un canale di comunicazione sicuro, eseguono quello che viene chiamato "scambio di chiavi".

La chiave pubblica che il server fornisce al programma client non contiene nulla di segreto. La sua unica funzione è crittografare le informazioni.

Il client genera una password segreta una tantum che solo il browser Web conosce. Il client utilizza quindi la chiave pubblica del server per crittografare quella volta che utilizza una password segreta. La chiave pubblica può solo crittografare , la chiave pubblica non può decodificare !

Il client può trasmettere tranquillamente questa password segreta crittografata al server. Qualsiasi persona in grado di intercettare questo scambio di chiavi non otterrà nessuna informazione utile poiché quasi certamente non può decifrare quel segreto utilizzato una volta e generato dal client e crittografato con la chiave pubblica del server.

Il server, e solo il server ha la chiave privata corrispondente. La chiave privata del server può essere utilizzata solo per decrypt . La chiave privata del server non viene mai trasmessa a nessuno!

Il server utilizza la chiave privata per decrittografare la password segreta un tempo generata dal client (browser Web).

Il client e il server ora conoscono entrambi un segreto che nessun altro conosce !

Utilizzando questo segreto, possono crittografare le conversazioni successive utilizzando qualsiasi tradizionale algoritmo di crittografia simmetrica con un elevato grado di sicurezza sul fatto che il canale sia sicuro.

Inoltre, il cliente ha un archivio di certificati 'che contengono le chiavi pubbliche delle organizzazioni che si fida. Gli attuali scambi di chiavi TLS falliranno se il server non presenta un documento digitale chiamato certificato che contiene un valore hash crittografato con la chiave privata dell'organizzazione fidata. Il client può utilizzare questo hash e la chiave pubblica attendibile per sapere che questo server è considerato affidabile.

Non saresti in grado di completare l' TLS handshake come il client prende il certificato pubblico dei server e usa per crittografare un PreMasterSecret utilizzato per generare il Master Secret.

The client responds with a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key of the server certificate.

The client and server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed pseudorandom function.

Ricorda che nella crittografia asimmetrica la chiave pubblica non è affatto un segreto e in generale (non assumendo altri difetti) non è di alcuna utilità per un utente malintenzionato.

Le risposte esistenti parlano della crittografia con la chiave pubblica del certificato, che non è sempre quella che viene effettivamente utilizzata (in particolare con le suite di crittografia DSA o DHE). (C'è una risposta con maggiori dettagli qui , ad esempio.)

Lo scopo immediato dell'handshake SSL / TLS è quello di stabilire un segreto pre-master condiviso tra il client e il server. Questo segreto pre-master viene quindi derivato in un master secret e quindi in chiavi di crittografia (e MAC). Questa procedura è più ampiamente definita come lo scambio di chiavi (vedi RFC 4346 Appendice F.1.1 ).

Per assicurarti di comunicare con la persona giusta, devi utilizzare una suite di crittografia che supporti lo scambio di chiavi autenticate . (Le suite di codici anonimi sono disabilitate per impostazione predefinita in configurazioni sensate.)

Questo scambio di chiavi autenticate si divide in due categorie:

• Scambio chiave RSA (ad esempio TLS_RSA_WITH_AES_128_CBC_SHA ): il client crittografa il segreto pre-master utilizzando la chiave pubblica del server (presente nel certificato). Solo il server legittimo può decifrarlo con la sua chiave privata.

• Scambio chiavi DHE (ad esempio TLS_DHE_RSA_WITH_AES_256_CBC_SHA o suite di cifrature con certificato DSS): avviene uno scambio di chiavi Diffie-Hellman. Di solito è effimero DH, la variante con parametri fissi (DH, non DHE) è molto rara. (Avere un certificato basato su RSA non implica uno scambio di chiavi RSA.) Il server firma i propri parametri DH e il client verifica la firma con la chiave pubblica nel certificato del server. Poiché solo il server legittimo era in grado di firmare con la sua chiave privata, lo scambio è autenticato.

Un metodo utilizza la crittografia, l'altro utilizza la firma digitale, entrambi utilizzando la chiave pubblica nel certificato. Entrambi hanno lo stesso risultato finale: un segreto pre-master che il client può condividere esclusivamente con il server che ha la chiave privata per il suo certificato.

(Naturalmente, l'altro punto è che il client deve verificare che si fidi del certificato per essere valido e rilasciato al server con cui vuole comunicare, ma questi sono punti leggermente separati.)

Ciò presuppone che tu conosca le basi dell'autenticazione della chiave pubblica e di come un browser web comunica con un server web attraverso un nome di dominio. L'interazione è tra il browser Web dell'utente e il server Web dell'azienda.

Chiavi pubbliche e chiavi private

Il server Web ha una chiave pubblica e una chiave privata. La chiave privata può decodificare un messaggio crittografato dalla chiave pubblica. La chiave pubblica può decodificare un messaggio crittografato dalla chiave privata. L'autorità di certificazione ha la propria chiave pubblica e chiave privata.

Il server Web invia le informazioni sulla società, la chiave pubblica e il nome del dominio (da associare al certificato SSL) all'autorità di certificazione. L'autorità di certificazione invia un messaggio di conferma all'indirizzo email associato al nome di dominio, al fine di dimostrare che questa richiesta è stata fatta dal vero proprietario del nome di dominio. A questo punto, l'autorità di certificazione attenderà che il proprietario del nome di dominio convalidi la richiesta via e-mail.

Firma del certificato

L'autorità di certificazione crittografa il nome di dominio del server web, le informazioni sulla società e la chiave pubblica utilizzando la propria chiave privata. L'autorità di certificazione invia il risultato crittografato al server web. Questo risultato è il certificato SSL, un messaggio di testo contenente il nome di dominio, le informazioni sulla società e la chiave pubblica del server Web che è stato crittografato con la chiave privata dell'autorità di certificazione. Il server Web invia questo certificato al browser dell'utente.

Autorità di certificazione attendibili

Il browser Web viene pre-caricato con un elenco di autorità di certificazione attendibili e le loro chiavi pubbliche. Il browser Web decrittografa il certificato utilizzando la chiave pubblica dell'autorità di certificazione corrispondente. A questo punto, il browser Web sa che il certificato e il suo contenuto sono affidabili perché solo un messaggio crittografato con la chiave privata dell'autorità di certificazione potrebbe essere stato coerentemente decifrato dalla chiave pubblica dell'autorità di certificazione.

Il browser Web ora conosce le informazioni sull'azienda fidata, la chiave pubblica e il nome di dominio che si suppone siano associati al server Web, che è ancora sospetto. Il browser Web conferma che il nome del dominio sul certificato corrisponde al nome effettivo del dominio del server web.

A questo punto, se i nomi dei domini corrispondono, il browser Web determina che il server Web è abbastanza affidabile da inviare dati crittografati. Inoltre, a questo punto, il browser Web determina che può utilizzare la chiave pubblica attendibile del certificato per crittografare i suoi messaggi perché solo la chiave privata del server Web autentico può decrittografarlo.

Si noti che se veniva utilizzata una chiave pubblica non sicura (non passata attraverso la verifica dell'autorità di certificazione), il browser Web potrebbe avere crittografato e inviato informazioni riservate solo per essere decifrato dalla chiave privata di un server dannoso! In altre parole, è fondamentale che la chiave pubblica sia attendibile perché la crittografia di un messaggio con essa è l'unica linea di difesa di intercettazione per le informazioni inviate dal browser.

Proseguendo, il browser Web crittografa il suo messaggio utilizzando la chiave pubblica attendibile e invia il messaggio crittografato al server web. Il server Web decrittografa il messaggio con la vera chiave privata, se ne ha una, quindi legge correttamente il messaggio decrittografato.

Chiave segreta condivisa

Quando il server web risponde al browser web, anche quel messaggio deve essere inviato in modo sicuro. Il browser Web potrebbe copiare ciò che il server Web ha appena fatto (escluso il processo dell'autorità di certificazione) generando una chiave pubblica e una chiave privata per sé, inviando quindi la sua chiave pubblica al server web. Questo stabilirà una connessione sicura chiamata crittografia asimmetrica a 2 vie. Tuttavia, tale comunicazione è tassativamente computazionale (relativamente parlando).

Quindi l'approccio standard consiste nell'utilizzare una chiave segreta condivisa in grado di crittografare un messaggio e anche decodificarlo. Il browser Web genera una chiave segreta, la crittografa utilizzando la chiave pubblica attendibile, quindi la invia al server Web. Se il server web è autentico, sarà in grado di decrittografare la chiave segreta con successo.

A questo punto, sia il browser Web che il server Web dispongono di una chiave segreta condivisa che possono essere utilizzate per crittografare e decrittografare ulteriori comunicazioni da ora in poi.

Per ulteriori informazioni:

• Verifica dell'integrità del messaggio con le funzioni hash per rilevare le alterazioni del messaggio

• Catena di fiducia tra le autorità di certificazione

Che il certificato CA (chiave pubblica) per i certificati verificati sia già incluso nel browser e che lo scenario generi un avviso SSL.

Se stai parlando di qualcosa sulla falsariga di SSH, dovrai comunque accettare la chiave pubblica. Se non verifichi che quella chiave sia corretta attraverso un altro canale sicuro, allora è colpa tua se ricevi MITM.

La risposta al motivo per cui non puoi semplicemente prendere la chiave pubblica firmata e usarla per intercettare il traffico in un attacco di tipo man-in-the-middle è che tu (o l'attaccante) non avrai la corrispondente chiave privata che accompagna la chiave pubblica.

Quindi il browser riceverà i server Web o la chiave pubblica firmata CA, e lo userà per crittografare il proprio segreto per inviarlo al server web.

Il server web ha la chiave privata corrispondente necessaria per decrittografare i dati inviati dal browser che è stato crittografato con la chiave pubblica, l'utente malintenzionato non lo fa, quindi non sarà in grado di decodificare il traffico.

A quanto pare, ho fatto questa domanda nel 2012, ma ora nel 2015 c'è effettivamente un attacco che lo rende possibile. A seconda dell'implementazione, i client possono essere vulnerabili a questo attacco che può consentire a un utente malintenzionato, a un MiTM di falsificare qualsiasi certificato firmato che desidera.

Il link fornisce una spiegazione approfondita di come funziona a causa della cattiva implementazione della macchina a stati SSL sul client.