Comprensione della certificazione digitale nel suo complesso a partire da una normale richiesta http

In primo luogo, penso che tu stia confondendo alcuni termini. Il termine è "certificato digitale", "certificato" o semplicemente "certificato". Non "certificazione digitale". Se intendi davvero "certificazione digitale", allora questa risposta è probabilmente sbagliata.

1. Sì. Le chiavi simmetriche sono utilizzate per la crittografia di massa perché gli algoritmi di crittografia simmetrica sono molto più veloci di quelli asimmetrici.
2. Nessun. Questa non è una garanzia. Tutto ciò che è richiesto è che il server e il client concordino su un segreto condiviso. Usando uno scambio di chiavi Diffie-Hellman , possono concordare il segreto condiviso senza bisogno di alcuna crittografia . Puoi leggere i dettagli dell'algoritmo o puoi semplicemente fidarti che lo scambio di chiavi DH consente di concordare un segreto condiviso senza che sia necessaria alcuna crittografia. Il DH è spesso (forse principalmente ma non ho statistiche) usato per concordare il segreto condiviso.
3. Si
4. Si
5. Sì. Una catena di certificati viene utilizzata per dimostrare che tutti i certificati non sono chiusi.
6. I certificati di certificazione attendibili vengono installati in Windows. IE utilizza quelli di Windows mentre Chrome e Mozilla installano il proprio set di certificati CA attendibili.
7. OK. Sei per lo più corretto qui. Alcuni algoritmi di firma digitale funzionano crittografando l'hash del messaggio con una chiave privata. Altri algoritmi fanno altri trucchi (non ho familiarità con i dettagli) ma non è esattamente la stessa cosa. Quindi il numero 7 è meglio indicato come "La firma viene quindi convalidata dal client." Generalmente ciò significa hash e crittografia asimmetrica, ma non sempre.
8. Ancora, no. Lo scambio di chiavi Diffie-Hellman è generalmente usato (come discusso in 2 sopra).
9. Sì!

Per quanto riguarda le tue domande puntate.

Is my understanding correct ?

Per lo più - ho apportato correzioni sopra.

for 2* is the session key created by the web client and send to the webserver for use directly (encrypted) or it is setup by exchanging information that end up having both side with the same session key (Diff hellman algorithm ?)

Diffie Hellman come affermato sopra.

For 5* I have never applied for a digital certificate before. When the CA issue a digital certificate, does it really issue the digital certificate ? or it just issue a digitally signed hash of the certificate.

Le CA non rilasciano certificati tanto quanto le richieste di firma. In genere ciò avviene inviando alla CA una richiesta di firma del certificato o CSR . La maggior parte degli strumenti che generano certificati o chiavi hanno opzioni per generare una CSR.

Else,how do we send the digital certificate (original) and its digitally signed hashed version without the CA private key ?

Non sono sicuro di cosa intendi qui. Forse ho risposto sopra?

For 6* is my understand correct that CA's public key come preinstalled with the browsers ?

Risposta sopra, vengono con i browser o il sistema operativo. Penso che Java abbia mantenuto anche il proprio elenco. Probabilmente alcune altre app comuni fanno lo stesso.

Does the client need to authenticate with the webserver ? (i read about having the client sending cert to the webserver as well).

Questo è un passaggio facoltativo. Per la maggior parte delle applicazioni (ad esempio: Amazon e la tua banca), tu, il cliente, esegui l'autenticazione sul sito effettuando una connessione HTTPS sicura e assegnandogli nome e password. Alcuni siti consentono anche l'autenticazione a due fattori. L'SSL autenticazione reciproca (AKA: autenticazione a 2 vie) fa parte di SSL che consente al client di autenticarsi sul server durante Handshake SSL. Perché ciò si verifichi, il client deve avere un certificato e una chiave privata e tale certificato deve essere pre-registrato con il server. (Si noti che non ci sono CA per questi certificati, il browser si fida di un certificato perché ne ha ricevuto una copia e gli è stato detto di fidarsi di esso.) La parte conveniente dell'autenticazione 2way è che avviene per magia. Nessuna cattiva password da ricordare o digitare. La parte (davvero) scomoda è che dover gestire una raccolta di certificati e chiavi private su tutti i tuoi browser (pensa il cellulare) è un problema. Talvolta i certificati client (ovvero: autenticazione 2way) vengono utilizzati anche come secondo fattore in un processo di autenticazione a 2 fattori. La mia esperienza è che l'autenticazione 2way è più utilizzata in ambienti ad alta sicurezza in cui gli utenti (quasi) usano sempre lo stesso computer.

What will be put in the truststore on the webclient, and what will be put in the keystore on the webserver ?

Intendi cosa verrà inserito nel truststore / keystore quando si utilizza l'autenticazione 2way? Nulla viene inserito nel truststore del client per l'autenticazione 2way. Il certificato e la sua chiave di solito sono conservati in un archivio di chiavi o in un altro archivio dati sicuro, tipicamente crittografato. E nulla va nel keystore del server per l'autenticazione a 2 vie. Tutto ciò che il server deve fare è conservare una copia del certificato e associarla all'utente appropriato. Questo è generalmente fatto in un database.

Forse stai chiedendo cosa andrà nel truststore / keystore per le connessioni SSL standard? I certificati CA radice entrano nel truststore del cliente. Questo è tipicamente fatto dal fornitore del browser / OS e gli utenti non hanno mai bisogno di cambiarlo. Se si distribuiscono certificati autofirmati (ad esempio: senza CA) o si esegue un proxy Web, potrebbe essere necessario aggiungere nuovi certificati al truststore del client. La chiave privata del server è memorizzata nel suo keystore. Per comodità, spesso anche il certificato è memorizzato lì.

When a user access a website, in order to encrypt communication between the the user and the website, a symmetric key is to be use.

Sì.

*In order for the symmetric key to be used by both the client and server, information about the creation of the symmetric key must be encrypted using the asymmetric key

Sì, a meno che non sia diffie-hellman.

But 1st, the authenticity of the webserver must be confirmed. Hence, the webserver send the user/client its digital certification. Inside the digital certification, it contains the public key use by the webserver to be use for asymmetric encryption at 2).

Sì.

This digital certification is being issued by the Certificate Authority which will does checks and verification to prove that the webserver/domain does really belongs to whom it is suppose to be long to.

Sì: dipende dal livello del certificato. Se il certificato richiesto è Domain Validated (DV), Organization Validated (OV) o Extended Validation (EV) certificato determina quali controlli vengono effettuati.

*However again, how do we prove the authenticity and integrity of the digital certification ? For integrity, the digital certificate is hashed and send together with the original certificate. For authenticity, the hashed digital certificate is signed with the CA private key.

Sì, il certificato include una firma scaricata dal browser.

*So if the digital certificate is signed by the CA private key, how do we get CA's public key ? The overall idea i have is that public keys from CA are preinstalled in many browsers.

Affinché il browser consideri attendibile il certificato, la chiave pubblica della CA deve trovarsi nel sistema operativo o nell'archivio principale del certificato del browser. Internet Explorer e Chrome utilizzano lo store del sistema operativo, mentre Firefox ha il suo negozio.

With the public key of the CA, the digitally signed hash/certificate is decrypted and to produce the original hash. The client then hash the received certificate and compare it with the original hash. If the 2 hash results matched, the certificate is not tampered.

Non proprio. Non confondere hashing, crittografia e firma. Il certificato pubblico del sito web è firmato dalla chiave privata della CA (o da una CA intermediario). Finché la catena risulta in un certificato radice affidabile, tutto è buono. per es.

Site CA --signed-by-> Intermediary CA --signed-by-> Root CA

Chiunque può verificare che la firma corrisponda al certificato con hash tramite la chiave pubblica della CA. La crittografia a chiave pubblica sfrutta le "funzioni botola" in equazioni matematiche. È facile verificare che una firma sia generata da una chiave privata utilizzando la chiave pubblica, tuttavia è computazionalmente impossibile generare la firma senza la chiave privata della CA.

With the digital certificate, the public key used by the webserver is retrieved by the webclient/user. The webclient/user then use this public key to encrypt the information of building the symmetric key over to the webserver.

Sì, il segreto pre-master è crittografato con la chiave pubblica. Nel caso di Diffie-Hellman la chiave pubblica viene invece utilizzata per firmare i segreti condivisi.

For 5* I have never applied for a digital certificate before. When the CA issue a digital certificate, does it really issue the digital certificate ? or it just issue a digitally signed hash of the certificate.

Sì, riceverai il certificato e la firma che è calcolata sull'hash del certificato.

Else,how do we send the digital certificate (original) and its digitally signed hashed version without the CA private key ?

È possibile mantenere la chiave privata. Per ottenere la firma del certificato, si genera una richiesta di firma del certificato (CSR) da inviare alla CA. Una volta firmato il certificato, è possibile installare la versione firmata sul server per eseguire il pairing con la chiave privata precedentemente generata.

Alcune CA genereranno la chiave privata per te - tuttavia, per sicurezza ti consiglio di crearne una tua e di inviare semplicemente il CSR.

Does the client need to authenticate with the webserver ? (i read about having the client sending cert to the webserver as well).

Sì, è possibile autenticare il client con il server Web utilizzando i certificati client. Questo è solo per l'autenticazione, piuttosto che per la crittografia.

What will be put in the truststore on the webclient, and what will be put in the keystore on the webserver ?

Il client Web invierà il suo certificato e il server Web può verificare la sua chiave pubblica e verificare che sia firmato da una CA attendibile. Come prova del possesso della chiave privata, il client firma anche i messaggi di handshake che possono essere verificati dalla chiave pubblica dal server.