Processo di crittografia SSL e sicurezza

1. If there is a intercepting proxy between the web server and the client, mostly the proxy uses its own signed certificates which the client may or may not trust. Then why don't proxy just take the certificate from server and forward it to client so the client will trust it. Also if the private key is only held by the server, then how come an intermediary give its own certificate and decrypt the message?

Se il proxy di intercettazione utilizza certificati autofirmati (o firmati dalla propria CA) generati al volo, il certificato trasmesso al client non sarà considerato attendibile poiché non ha una catena di certificati valida. Se i certificati o la CA utilizzata sono attendibili dal client (che è spesso il caso nelle reti interne), tutto il traffico può essere annusato senza sospetti dall'utente credulone. Tuttavia, è possibile rilevare l'intercettazione osservando il certificato (catena) nel software.

Se il proxy non utilizza il proprio certificato ma il certificato del server, non può decrittografare il traffico. La chiave pubblica nel certificato corrisponde sempre a una chiave privata specifica, che non è nota agli altri.

Il certificato del server contiene una firma digitale della CA (principalmente un certificato intermedio), che è un valore hash firmato. La firma viene generata con la propria chiave privata e può essere verificata con la chiave pubblica utilizzando il certificato successivo nella catena di chiavi. Questo può essere ripetuto più volte, finché non viene fornito un certificato, che non ha un genitore ed è considerato affidabile dal client (certificato di root)

2. The signature hash generated by the private key can be decrypted with a public key. Can't someone decrypt that other then the client and can see the signature?

La firma non contiene alcuna informazione confidenziale. Di solito la firma si basa su un valore hash di un file, messaggio o (parti di) un certificato. Tutti con la chiave pubblica possono verificare la firma e confrontare i valori hash. Se corrispondono, la firma è valida, altrimenti no.

Vedi anche Qual è il valore effettivo di un'impronta digitale del certificato?

3. Does the client already has the public key with which it starts the encrypted message or do it first ask the server?

A meno che il client non utilizzi blocco dei certificati , non contiene informazioni sul certificato del server e sulla chiave pubblica. Il server invia il certificato all'inizio di una sessione TLS.

Crittografia a chiave pubblica

Devi prima capire il principio della crittografia a chiave pubblica. Sia il server che il client hanno la propria chiave pubblica e (privata / privata).

La chiave pubblica può essere utilizzata per due cose.

• Cifra i dati su destinatario .
• Verifica i dati ricevuti da mittente o altri dati firmati, come i certificati firmati.

La chiave privata può essere utilizzata anche per due cose.

• Decrittografa i dati ricevuti dal mittente.
• Firma i dati su ricevitore o altri dati come i certificati firmati.

Quando i tuoi dati di invio a una destinazione sono seguiti i seguenti passaggi:

1. Il mittente firma i dati con la sua chiave privata.
2. I dati mittente crittografati con destinatari chiave pubblica
3. Il ricevitore decrittografa i dati con la sua chiave privata.
4. Il ricevitore verifica la firma mittenti con la chiave pubblica mittenti .

Catena di certificati

Un certificato è un «documento digitale» che verifica la proprietà della chiave pubblica, il certificato è firmato allo stesso modo di altri dati nella crittografia a chiave pubblica. E i certificati possono accedere con una chiave privata che appartiene a un altro certificato firmato da un terzo certificato, questo è chiamato catena di certificati

Facciamo un esempio, l'emittente del certificato invia un certificato a un webhost. Il certificato che appartiene all'emittente di certificati è firmato da una chiave privata dell'autorità di certificazione . I seguenti passaggi saranno completati.

1. L' autorità di certificazione crea una coppia di chiavi pubbliche con certificato di appartenenza. (Root-certificato)
2. L' autorità di certificazione firma il proprio certificato con la sua chiave privata. (Self-signed)
3. L'emittente del certificato crea una coppia di chiavi pubbliche con certificato di appartenenza.
4. L' autorità di certificazione firma il certificato certificati emittenti con la sua chiave privata.
5. Il webhost crea una coppia di chiavi pubbliche con certificato di appartenenza.
6. Il certificato emittente firma webhosts certificato con la sua chiave privata.

Questa è chiamata catena di certificati , se il certificato dell'autorità di certificazione è un certificato attendibile, allora il certificato del webhost è attendibile. Questa catena può essere estesa all'infinito.

Sicurezza del livello di trasporto

1. If there is a intercepting proxy between the web server and the client, mostly the proxy uses its own signed certificates which the client may or may not trust. Then why don't proxy just take the certificate from server and forward it to client so the client will trust it. Also if the private key is only held by the server, then how come an intermediary give its own certificate and decrypt the message?

Poiché esiste una chiave pubblica che appartiene al certificato inviato dal server , il client crittograferà i dati utilizzando la chiave pubblica del server , e middle-man non può decifrare i dati inviati dal client poiché il middle-man non ha la chiave privata del server .

2. The signature hash generated by the private key can be decrypted with a public key. Can't someone decrypt that other then the client and can see the signature?

La firma non è crittografata, quindi non puoi decrittografarla. Ma puoi verificarlo utilizzando la chiave pubblica del mittente e chiunque abbia la chiave pubblica per il mittente può verificare la firma.

3. Does the client already has the public key with which it starts the encrypted message or do it first ask the server?

Normalmente la chiave pubblica e il certificato vengono scambiati sotto l'handshake della sessione TLS. Ma è possibile pre generare un certificato e fornire al server quel certificato prima dell'handshake TLS. Ad esempio è usato nel server OpenSSH.

If there is a intercepting proxy between the web server and the client, mostly the proxy uses its own signed certificates which the client may or may not trust. Then why don't proxy just take the certificate from server and forward it to client so the client will trust it. Also if the private key is only held by the server, then how come an intermediary give its own certificate and decrypt the message?

Se il proxy ha prelevato il certificato dal server, non sarà in grado di decrittografare l'invio segreto premaster da parte del client, poiché viene crittografato con la chiave pubblica dal server.

Se un intermediario fornisce il proprio certificato, il client crittograferà il segreto premaster con la chiave pubblica del proxy, non con il server.

Si può pensare che un proxy di intercettazione sia un server e un client. Quindi invece di

Client --> Server

È

Client --> Proxy Server --> Proxy Client -- > Server

quindi ci saranno due connessioni separate e due separati tunnel SSL / TLS.

The signature hash generated by the private key can be decrypted with a public key. Can't someone decrypt that other then the client and can see the signature?

Non sei sicuro di cosa intendi con questo. Non è decrittazione o crittografia, è una firma. Un client può verificare che qualcosa sia stato firmato da una chiave privata con la chiave pubblica corrispondente, ma nient'altro può firmare nulla senza la chiave privata.

Does the client already has the public key with which it starts the encrypted message or do it first ask the server?

Il server invia la catena di certificati nel suo messaggio server hello . La foglia del certificato contiene la chiave pubblica. Il client ha già certificati di root in modo che sappia di cosa fidarsi (qualsiasi catena che conduce a una radice attendibile).

Controlla I primi pochi millisecondi di una connessione HTTPS per una buona guida di base.

L'intermediario avrebbe bisogno di "falsificare" il certificato del server creando un certificato con lo stesso nome host ma con una coppia di chiavi controllata dall'intermediario.

Questo perché se l'intermediario trasmette semplicemente il certificato del server al cliente, il client e il server stabiliranno uno scambio sicuro di chiavi e un canale crittografato che l'intermediario non sarà in grado di intercettare. Se ci pensate, non ci sarebbe alcun valore per SSL se non fosse così perché Internet è una rete decentralizzata e ci sono sempre più intermediari tra il client e il server.

Quindi, in un proxy di intercettazione https, l'intermediario prenderà i dettagli del certificato del server e creerà un nuovo certificato con lo stesso hostname ma con le chiavi controllate dall'intermediario in modo che l'intermediario possa decrittografare entrambe le comunicazioni tra se stesso e il client stesso e server. Nella maggior parte dei casi questo da solo non sarà comunque sufficiente. Come misura di sicurezza, i browser avviseranno su tutti i certificati autenticati o certificati firmati da root di cui non si fidano. Per impersonare correttamente il server reale su un client, il cert root dell'intermediario dovrebbe essere installato nell'archivio principale attendibile del client.