TLS handshake proof of private key posession [chiuso]

Question

TLS handshake proof of private key posession [chiuso]

#1 da (1 voti)

1

In quale fase della configurazione della connessione TLS sottostante il server ha dimostrato al cliente di possedere la chiave privata corrispondente alla sua chiave RSA pubblica.

Ho usato TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 Cipher suite per configurare correttamente una connessione reciprocamente autenticata del client del server. Sono solo curioso di sapere come funziona. Ho una vaga idea della generazione delle chiavi di Diffie Hellman (credo sia indipendente dall'autenticazione, e solo per la generazione di segreti per creare una chiave simmetrica) ma non ho potuto capire nel diagramma di sequenza sottostante, dove il server ha dimostrato di possedere la chiave privata (So che solo la chiave privata decrittografa quale chiave pubblica codifica, ma qualsiasi hacker potrebbe inviare una copia del certificato pubblico di qualsiasi server)

authentication encryption public-key-infrastructure tls asymmetric

posta Chetan Gowda 23.11.2016 - 10:18

fonte

1 risposta

Leggi altre domande sui tag authentication encryption public-key-infrastructure tls asymmetric

Con SSL / TLS, è pre-condivisione di un certificato fondamentale per evitare un MITM attivo iniziale? CISecurity AMI EC2 Amazon

score 1 · Answer 1

Non deve esserci alcuna prova esplicita del possesso di una chiave privata.

Quando si presenta un client con il proprio certificato, il client risponderà crittografando i dati con la chiave pubblica presente nel certificato. Se non si dispone della chiave privata, non sarà possibile decrittografare ciò che il client ha inviato, pertanto la connessione non verrà spostata in avanti. @ adam86 ha sottolineato che la mia risposta non era chiara. Quello che intendevo era che fino a quando non hai uno scambio di chiavi Diffie Hellman, i messaggi vengono crittografati usando la chiave pubblica. Una volta stabilita una chiave simmetrica (chiave di sessione), viene utilizzata per il resto della sessione.

Ciò che un aggressore motivato può invece fare è creare il proprio certificato e comportarsi come se fosse il vero server (l'uomo nel mezzo). Questo è ancora possibile in SSL / TLS.