Dettagli della verifica del certificato TLS

2

Capisco le basi della crittografia, ma non sono sicuro dei seguenti tre passaggi:

Passaggio 1: come calcolare un certificato TLS

Correggimi se sbaglio: L'autorità di certificazione calcola un valore di hash sulle informazioni relative al certificato pertinenti (inclusa la chiave pubblica del responsabile del certificato), quindi firma questo valore di hash utilizzando la chiave privata dell'autorità. L'output di questo processo è un singolo file di certificato che può essere distribuito su server che hanno accesso alla chiave privata corrispondente.

Passaggio 2: come verificare che il server sia proprietario della chiave privata corrispondente al certificato TLS?

Il client riceve il certificato dal server durante l'handshake TLS. Ma il certificato da solo non è sufficiente per verificare l'autenticità dei dati. (dato che chiunque può inviare una copia di un certificato senza possedere la chiave privata) Quindi penso che ci debbano essere alcune informazioni casuali aggiuntive trasmesse, che devono essere firmate usando la chiave privata corrispondente (forse anche calcolando un hash)?

Il client decrittografa queste informazioni casuali con la chiave pubblica del certificato? Come viene eseguito questo controllo?

Passaggio 3: come verificare che il certificato sia firmato da un'autorità affidabile?

Penso che funzioni principalmente con le tabelle del browser preinstallate che contengono le chiavi pubbliche dell'autorità attendibile (tra le altre informazioni).

Le chiavi pubbliche dell'autorità di certificazione vengono utilizzate per decrittografare un valore di hash e verificare se corrisponde a un valore hash calcolato automaticamente sull'intero certificato?

    
posta Mike76 08.10.2016 - 20:40
fonte

1 risposta

3

Una risposta alla domanda 1:

Sì, tranne che la root della CA non è in linea in un HSM in un vault, non disponibile per essere rubato elettronicamente. La root è stata utilizzata per firmare una manciata di certificati intermedi (backup e certificati di risponditore OCSP e altre informazioni) che risiedono in HSM direttamente connessi ai computer che possono essere raggiunti elettronicamente.

Per emettere un certificato, il "back-end" della CA:

  1. riceve CSR
  2. utilizza alcuni metodi di convalida (protocollo ACME, clic umani "ok" sul sito web di amministrazione, ecc.)
  3. registra tutte le decisioni e le informazioni utilizzate per prendere la decisione per il controllo con un controllo successivo
  4. genera i dati del certificato (X.509 v3) codificati in DER X.690, utilizzando un modello e un nuovo numero di serie / fonte di casualità.
  5. forse ottiene gli SCT della trasparenza del certificato
  6. chiede all'HSM di firmare il blob (o l'hash del blob).
  7. aggiunge la firma al certificato e la invia allo spazio di archiviazione del cliente.

Una risposta alla domanda 2:

Nello scambio di chiavi RSA, il client genera una sequenza casuale di byte ed esegue la crittografia RSA utilizzando la chiave pubblica dal certificato del server. Quindi il client invia il testo cifrato risultante al server e si aspetta che il server lo decodifichi (utilizzando la chiave privata corrispondente alla chiave pubblica dal certificato) e utilizzi il valore casuale in un KDF, insieme ad altri valori, per generare chiavi simmetriche e invia un messaggio finito crittografato con le chiavi simmetriche risultanti. Il client verifica il messaggio Finito. Il server può solo riuscire a generare le chiavi simmetriche attese tramite messaggio crittografato RSA di decifratura. link

Nello scambio di chiavi DHE / ECDHE con PFS, il server firma la sua chiave temporanea utilizzando la chiave privata corrispondente alla chiave pubblica nel certificato e la invia in ServerKeyExchange. Il client verifica la firma utilizzando la chiave pubblica dal certificato. link

Una risposta alla domanda 3: Il browser contiene un elenco di root attendibili (Mozilla Firefox fa ciò) o utilizza un elenco di root attendibili forniti dal sistema operativo (Google Chrome utilizza il root store del sistema operativo). L'archivio radice contiene certificati autofirmati e alcuni metadati su di essi che potrebbero limitare ciò per cui possono essere utilizzati. I browser contengono anche codice che aggiunge controlli aggiuntivi, come Chrome che richiede la trasparenza dei certificati dalle CA di proprietà di Symantec e le date limite che consentono l'utilizzo dei certificati SHA1.

Il modo in cui un server foglia / certificato di dominio viene verificato utilizzando l'archivio principale è creando una catena di certificati intermedi, uno firmando l'altro, da una radice attendibile all'anta. La radice firma un intermedio e l'intermedio firma la foglia. Ci può essere più di un intermedio in una catena. Gli intermedi vengono inviati dal server insieme alla foglia. link

Diversi computer hanno diversi archivi root e utilizzando la cross signing, possono essere creati molti percorsi diversi. Attualmente i browser tentano di costruire percorsi sha256-only, se possibile, a volte falliscono e producono un errore dicendo che solo un percorso sha1 è stato creato, quindi la connessione potrebbe essere insicura.

Non confondere le firme digitali con la crittografia: link

    
risposta data 08.10.2016 - 21:11
fonte