Come funzionano i certificati nella protezione contro un attacco man-in-the-middle? [duplicare]

1

A quanto ho capito, se Alice e Bob vogliono comunicare in modo sicuro, devono prima concordare i protocolli che verranno utilizzati. Quindi devono confermare che stanno effettivamente comunicando tra loro. Questo viene fatto tramite certificati firmati da terze parti fidate. La chiave pubblica e l'algoritmo di hashing utilizzati dalla terza parte sono già memorizzati sul tuo computer. Alice quindi invia a Bob il suo certificato e Bob invia ad Alice il suo certificato. Entrambi verificano la firma del certificato utilizzando la chiave pubblica della terza parte. Se è valido, iniziano il loro scambio di chiavi e così via. Tuttavia, cosa c'è in quei certificati che confermano la loro identità? Immagino non possa essere solo "Ciao, questo è totalmente Bob / Alice, credimi". Immagino che il certificato di Bob debba contenere la chiave pubblica di Bob, ma non sarebbe pericoloso se Bob usasse la stessa chiave pubblica ogni volta? Non sarebbe meglio se potesse usare una chiave pubblica diversa per ogni cliente?

Inoltre, un sito web (come Amazon) ha un solo certificato che invia a tutti i client o è un nuovo certificato firmato da terzi per ogni cliente che si connette al sito web?

Apprezzerei anche alcune fonti sulle basi dell'applicazione della crittografia asimmetrica se qualcuno ha alcune fonti semplici (sono comunque un maniaco).

    
posta Dasherman 05.01.2015 - 17:01
fonte

2 risposte

0

l'articolo wikipedia in particolare l'immagine svg è una buona base per iniziare,

1 cosa fondamentale che devi capire è che per PKI, non importa se tutti hanno la chiave pubblica, dato che puoi usarla solo per ENCRYPT, intesa per ME con esso (è come se dessi a tutti solo un lockbox che ho la chiave di)

e la chiave privata non può essere dedotta dalla chiave pubblica. ('legge' crittografica)

    
risposta data 05.01.2015 - 17:09
fonte
0

Esistono server di autorità di certificazione (CA) di root utilizzati dal browser. Va un po 'così.

Site: Hi I'm BOB!

Browser: Mr. Root CA server signed this certificate that Bob gave me. I fully trust the CA's signature, and I checked that it's a valid signature. Therefore, you are Bob. Hi Bob!

Due insidie:

  1. Compromissione delle firme CA radice, che vengono poi utilizzate per produrre falsi certificati. OSSIA Perdita di chiavi, crittografia rotta. Un fattore attenuante: i produttori di browser inseriranno nella black list CA compromesse.

  2. CA radice canaglia. Ci sono CA di proprietà di governi e altre società. Se hanno deciso di violare la fiducia dell'utente assegnando il certificato al proprio sito Web MITM, nessuno se ne accorgerebbe. Un fattore attenuante: osservatorio SSL , del FEP.

Questa è una visione piuttosto semplicistica delle cose, ma spero che questo aiuti.

    
risposta data 05.01.2015 - 17:25
fonte