Che dire di SSL lo rende resistente agli attacchi man-in-the-middle? [duplicare]

Question

Che dire di SSL lo rende resistente agli attacchi man-in-the-middle? [duplicare]

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

0

Ecco come capisco cosa fanno effettivamente i certificati SSL, in termini di bambino di 4 anni. Devono esserci tre parti coinvolte. Due parti sono solo il mio cliente e il server con cui sto comunicando, mentre il terzo è l'emittente del certificato. Il mio cliente chiederà l'emittente del certificato se il server che ho contattato è in realtà il server che dice di essere, l'emittente del certificato proporrà una richiesta al server e risponderà se è andato bene.

Ecco però la cosa. Quando ho cercato altre persone che chiedevano attacchi man-in-the-middle, le risposte hanno detto che sarebbe stato possibile solo se la terza parte (l'emittente del certificato) avesse rubato la sua chiave privata, che l'uomo nel mezzo avrebbe potuto usare per falsificare la sua identità completando la sfida, o qualcosa del genere ...

Tuttavia, senza rubare la chiave privata, e senza rubare nulla - se l'uomo nel mezzo può imporre come server del sito che sto cercando di raggiungere (semplicemente reindirizzando il suo nome di dominio al proprio IP), allora cosa impedisce di fare lo stesso con il server dell'emittente del certificato? Quindi, ad esempio, potrebbe reindirizzare l'indirizzo IP di Facebook sul proprio server per provare a farmi inserire le credenziali del mio account e quando il mio browser cerca di chiedere a Digicert (il titolare del certificato per facebook.com) se sto comunicando con l'autentico Il server di Facebook, l'uomo nel mezzo potrebbe anche reindirizzare nuovamente l'indirizzo IP di Digicert a se stesso, e erroneamente confermare che Facebook è davvero Facebook.

tls man-in-the-middle

posta Digital Ninja 15.03.2017 - 02:47

fonte

3 risposte

Leggi altre domande sui tag tls man-in-the-middle

Difendendo dalle richieste POST da BURP? Come spiegheresti il token CSRF a un principiante? In che modo è più sicuro dell'approccio basato sui cookie?

score 1 · Answer 1

My client will ask the certificate issuer if the server I contacted is really the server it says it is, the certificate issuer will propose a challenge to the server, and respond to me if it went well.

No, non è necessario contattare separatamente l'emittente per verificare una certificazione. Altrimenti cambieresti il problema di fiducia. Invece deve esserci un'ancora di fiducia locale.

Ecco perché il tuo browser (e eventualmente il tuo sistema operativo) viene già fornito con certificati preinstallati per le autorità di certificazione ritenute attendibili. Dalla Norme sui certificati CA di Mozilla :

When distributing binary and source code versions of Firefox, Thunderbird, and other Mozilla-related software products, Mozilla may include with such software a default set of X.509v3 certificates for various Certification Authorities (CAs). The certificates included by default have their "trust bits" set for various purposes, so that the software in question can use the CA certificates to verify certificates for SSL servers and S/MIME email users without having to ask users for further permission or information.

Quando il tuo browser stabilisce una connessione SSL a facebook.com , il server presenta il certificato insieme a una firma per dimostrare che questo certificato è stato emesso da DigiCert per il dominio facebook.com . Il browser verifica ciò verificando che il certificato sia provvisoriamente firmato dal certificato radice di DigiCert fornito con il browser. Se il certificato radice corrispondente non può essere trovato o non è affidabile, non esiste una catena di certificati valida e la verifica ha esito negativo.

Come ulteriore meccanismo di sicurezza, Facebook utilizza il blocco della chiave pubblica HTTP (HPKP) funzionalità che blocca un aggressore man-in-the-middle anche se è riuscito a compromettere una CA e generare certificati apparentemente validi:

The feature binds a set of hashes public keys to a domain name such that when connecting to a site using TLS the browser ensures that there is an intersection between the public keys in the computed trust chain and the set of fingerprints associated with that domain. This check is done during the certificate verification phase of the connection, before any data is sent or processed by the browser.

(Origine)

Mentre qualsiasi sito web può annunciare i propri pin tramite un'intestazione Public-Key-Pins che diventerà attiva dopo la prima visita del browser ( modello TOFU ), Facebook e alcuni altri siti di alto profilo hanno i loro pin integrati in Firefox e Chrome, il che significa che questi browser si fidano direttamente dei certificati di Facebook e non hanno bisogno di verificare con la radice di DigiCert a tutti.

Si noti inoltre che esistono meccanismi indipendenti in cui i clienti contattano direttamente una CA. Ad esempio, il tuo browser può utilizzare OCSP per verificare lo stato di revoca di un particolare certificato.

Vedi anche:

score 0 · Answer 2

Nella tua domanda c'è qualche informazione sbagliata, quindi ti incoraggio a leggere più attentamente un articolo generale su come funziona SSL / TLS. La risposta breve è che la CA fornisce un segreto (il certificato) che è ospitato da Facebook o da un altro server di destinazione. Senza quel certificato, firmato dalla CA, la CA sa che l'autore dell'attacco non è quello che dichiara di essere. Un attacco MITM che ha effettivamente il certificato (e le informazioni appropriate per usarlo) è indistinguibile dall'obiettivo. È quindi importante che i proprietari / operatori di server proteggano i loro certificati.

PKI fornisce anche un meccanismo per la revoca dei certificati nel caso in cui un certificato sia compromesso, in modo che un certificato possa essere invalidato e riemesso.

score 0 · Answer 3

My client will ask the certificate issuer if the server I contacted is really the server it says it is, the certificate issuer will propose a challenge to the server, and respond to me if it went well.

Questo non è il modo in cui funziona TLS / SSL. In TLS / SSL, il client non ha bisogno di chiedere all'emittente del certificato se il server sia o meno chi è realmente. Invece ciò che sta accadendo è che il client invia un numero casuale al server (una sfida) e chiede al server di firmare crittograficamente quel numero usando il certificato emesso dall'emittente del certificato (Client Hello). Il server quindi firma il numero casuale con la sua chiave privata e restituisce la firma e il certificato al client (Server Hello). Il client può verificare che 1) la firma sia valida per la sfida inviata e il certificato restituito dal server, 2) il certificato sia valido per il server e sia ancora valido, 3) il certificato sia crittografato firmato da un emittente fidato da il cliente.

Il numero casuale firmato in ClientHello viene anche utilizzato per derivare la chiave di crittografia, utilizzando un processo chiamato Scambio chiave Diffie-Hellman . Il risultato finale è che il server e il client derivano entrambi una chiave di sessione che non può essere conosciuta da q MITM anche quando tutti gli scambi fino a quel momento sono su MITMed e in testo semplice.

L'unica volta che l'emittente del certificato deve contattare il server per convalidare il server è prima che il certificato venga emesso, durante la convalida del dominio quando l'emittente del certificato sta verificando l'identità del server. Successivamente, l'emittente del certificato non ha realmente bisogno di contattare nuovamente il server.