In che modo SSL crittografa i dati dal server al client?

Question

La maggior parte degli articoli del wiki descrive come il browser client utilizza la chiave pubblica (certificato) per crittografare i dati sensibili (come nome utente/password) e inviare questi dati crittografati al server. Il server utilizzerà la chiave privata per decodificarlo. Ho questa parte. Ma nessuna informazione chiara dice come il server cripta i dati e li rimandi al browser.

Usa mia banking online come ad esempio:

(0) già certificato attendibile accettato (chiave pubblica) dal mio online-banking.

(1) Attraverso URL SSL, La mia visita del browser https://myonlinebanking.com

(2) Ho digitato il nome utente/password per accedere. Questi dati sono criptati, quindi il man-in-middle può vedere solo dati senza senso.

(3) Il server Web della banca ha ricevuto i miei dati crittografati e utilizza la sua chiave privata per decrittografarlo e autenticare il mio account con successo.

Ora qui sono le mie domande:

Come banca invia di nuovo i miei dati? La banca cripta i dati di risposta con quale chiave? Se la banca crittografata con "chiave pubblica", l'uomo in mezzo può vederlo proprio come posso vederlo. Quindi il man-in-middle non conosce il mio nome utente/password, ma può ancora vedere il mio saldo del conto?

Grazie per il vostro aiuto.

Answer 1

Il processo TLS handshake imposta una chiave simmetrica tra le due parti, potenzialmente utilizzando asimmetrica crittografia nel processo (i dettagli dipendono dalle algoritmi esatti che sono stati negoziati tra client/server). In questo modo, la comunicazione viene crittografata in entrambi i modi, non solo a senso unico.

La cosa che in definitiva ti protegge da un MITM, tuttavia, è il fatto che il tuo browser esegue una qualche forma di convalida del nome host. Il certificato presentato dal server nell'handshake viene prima verificato per la sua validità. Se ciò riesce, il tuo browser controlla se il certificato è associato all'esistente con cui sta parlando. Se questo controllo fosse omesso, un attacco MITM avrebbe comunque esito positivo, anche se il resto della comunicazione seguisse rigorosamente il protocollo, inclusi tutti gli elementi crittografici. L'attaccante potrebbe semplicemente fingere di essere un qualsiasi host ed eseguire il resto del protocollo rispettosamente, non si saprebbe la differenza.

Answer 2

Hai alcuni presupposti errati:

• I dati HTTP non è sempre cifrato con la chiave pubblica del server, al fine di inviarlo al server
• La chiave pubblica del server è solo utilizzato all'inizio (protocollo di handshaking) per stabilire una chiave sicura, per crittografia della chiave sicura (crittografia simmetrica)
• Tutte le comunicazioni sono su chiave segreta o crittografia a chiave simmetrica, in cui il client (browser) e il server utilizzano la stessa chiave segreta crittografare e decrittografare i dati.

Il protocollo TLS (Transport Layer Secuirty) utilizza una combinazione di crittografia asimmetrica (chiave pubblica) e Symmetric Encryption (chiave sicura). La comunicazione principale con la tua banca utilizza la crittografia simmetrica, per la quale le chiavi di sessione (chiave sicura) vengono stabilite in modo sicuro durante l'handshake TLS, utilizzando la crittografia asimmetrica.

È tutto nell'handshake TLS (Transport Layer Security), che è molto ben spiegato in questo collegamento here.