sicurezza di PKI, certificati, autorità di certificazione, segreto di inoltro

Sì, gli attacchi MITM sono vanificati se puoi essere certo di utilizzare la giusta chiave pubblica. I certificati sono un metodo di distribuzione a chiave pubblica che consente proprio questo.

Il punto dei certificati è che devi solo "conoscere" la chiave pubblica della CA per essere in grado di verificare tutti i certificati rilasciati dalla CA - ce ne possono essere milioni e funziona anche su certificati che la CA emetterà la prossima settimana . Quindi, anche se i certificati non eliminano del tutto la necessità di una fonte di fiducia (una chiave pubblica conosciuta a priori ), concentrano sufficientemente tale necessità in modo tale da risolvere il problema pratico della distribuzione delle chiavi.

Ottenere fiducia in una chiave pubblica può essere fatto attraverso altri schemi rispetto ai certificati; ad esempio, SSH lo fa memorizzando nella cache (ci si fida della chiave pubblica del server perché è possibile verificare che sia la stessa chiave dell'ultima volta che l'hai contattata, in un certo senso, SSH realizza la concentrazione di fiducia in tempo, mentre i certificati lo fanno in modo spaziale).

Perfect Forward Secrecy è ottenuto con SSL quando si usano le suite 'DHE' - per "Diffie-Hellman Ephemeral". La parola importante qui è "Effimero": le chiavi private effettive che proteggono la chiave simmetrica di sessione sono generate dinamicamente e mai archiviate (queste sono chiavi Diffie-Hellman); quindi, quelle chiavi dovrebbero essere immuni alla rivelazione. Le chiavi che sono memorizzate (ad es. In un file di chiave privata) vengono utilizzate solo per le firme, quindi rubarle non consente di decifrare le conversazioni passate (offre la possibilità di impersonare il server per ulteriori conversazioni , anche se). PFS non parla delle interruzioni della chiave , ma del furto di chiavi, che in pratica è un percorso di attacco molto più plausibile. Le suite di crittografia DHE garantiscono PFS non memorizzando mai le chiavi private di scambio di chiavi.

What security brings certificates to the table? In theory i need a certificate from a CA itself

Sì, un numero (enorme) di certificati CA è già presente nel tuo browser per impostazione predefinita. Rimane comunque il problema della cinghia di avvio iniziale quando si scarica il sistema operativo che include il browser (oi certificati per il sistema di pacchetti di distribuzione utilizzato per scaricare il browser).

Penso che un tale compromesso sia più facile da notare di un CA in quel elenca la firma di un certificato server falso , a meno che non si tratti di un sito di alto profilo come nel caso collegato.

Another doubt; its stated also that SSL/TLS supports perfect forward secrecy because IKE happens at regular intervals

Si noti che mentre SSL supporta la perfetta segretezza in avanti, è comunemente disabilitato per motivi di prestazioni.

La proprietà di sicurezza non si basa sulla generazione frequente di nuove chiavi di sessione, ma sull'uso di Diffie-Hellman per lo scambio di chiavi.

DH consente la negoziazione di una chiave segreta su una linea non sicura, se l'utente malintenzionato non può né modificare il contenuto né la destinazione di entrambe le estremità del flusso di dati. L'articolo di Wikipedia collegato ha un'ottima spiegazione di come funziona DH. È comprensibile con poca conoscenza di base matematica.

L'idea alla base del perfetto segreto in avanti è quella di impedire a un utente malintenzionato di decodificare un vecchio flusso di dati registrato in futuro, quando la chiave privata potrebbe essere compromessa. I certificati assicurano che Alice stia parlando con il Bob corretto. Pertanto i requisiti della DH (nessuna modifica, nessun target errato) sono soddisfatti nello scenario PFS.