certificati X509 / SSL in pratica

Question

certificati X509 / SSL in pratica

#1 da (1 voti)

0

Dopo aver appreso la teoria alla base della crittografia, sto avendo alcuni problemi a capire come funzionano i certificati SSL o X509 nella pratica e semplicemente non riesco a trovare informazioni utili su Internet.

A mio parere, un server web ha bisogno di un certificato SSL per dimostrare al cliente che egli è chi sta affermando di essere (ad esempio www.company.com). Accanto a ciò, presumo che sia usato anche per scambiare una chiave di sessione temporanea per la crittografia simmetrica (probabilmente AES) da qualche sistema di distribuzione di chiavi asimmetriche come diffie-helmann?

In questo caso: il certificato contenuto nel server Web contiene più chiavi pubbliche per tutti questi sistemi crittografici, ad esempio una chiave RSA per RSA Signatures, i parametri DL per Diffie-Hellmann? O ha bisogno di più chiavi (anche per più dimensioni di chiave?)

Sarei estremamente grato se qualcuno potesse dirmi cosa succede esattamente (passo dopo passo), quando un client si connette a un indirizzo https. Grazie mille!

cryptography public-key-infrastructure tls

posta netik 19.05.2016 - 21:58

fonte

1 risposta

Leggi altre domande sui tag cryptography public-key-infrastructure tls

Rilevamento dei set di dati interessati dall'iniezione SQL Perché la memorizzazione dei nomi utente nei cookie è errata? [duplicare]

score 1 · Answer 1

No, c'è solo una chiave pubblica nel certificato. Ovviamente il server dovrebbe anche avere la chiave privata che appartiene alla chiave pubblica nel certificato.

La chiave di sessione viene recuperata utilizzando la chiave. Ci sono fondamentalmente due modi:

il master secret viene generato e quindi crittografato dal client utilizzando la chiave pubblica del server, il server può ora decodificare il master secret e derivare le chiavi di sessione;
il segreto principale viene derivato utilizzando il contratto chiave Diffie-Hellman, i frame richiesti per il contratto chiave vengono quindi firmati dal server utilizzando la chiave privata e verificati dal client per eseguire l'autenticazione.
in linea di principio il certificato può anche contenere una chiave Diffie-Hellman statica, ma in pratica non viene utilizzata (molto); in questo caso il contratto chiave viene verificato automaticamente.

Le chiavi di sessione sono quindi derivate dal segreto principale utilizzando la derivazione della chiave con il PRF (identificato alla fine della ciphersuite).

Il tipo 1. viene utilizzato dalle suite di crittografia che iniziano con ad es. %codice%. Il tipo 2. è usato da ciphersuites che iniziano con RSA_ o ECDHE_ . Il tipo 3 è identificato con DHE_ o ECDH_ .

In caso di autenticazione del client, il client dovrebbe anche eseguire l'autenticazione dei frame scambiati.

TLS 1.3 consentirà solo la creazione di una chiave di tipo 2 poiché si basa solo sulla generazione di firme per il certificato. Inoltre fornisce la segretezza in avanti perché le chiavi temporanee DH temporanee vengono distrutte dopo che è stata eseguita la creazione della chiave. Ciò rende impossibile rompere la struttura della chiave stessa, ricalcolare le chiavi di sessione e decrittografare i frame crittografati con il testo in chiaro all'interno della sessione.