Diffie-Hellman e attacco MIM e identità server

Question

Diffie-Hellman e attacco MIM e identità server

#1 da (2 voti)
#2 da (1 voti)

0

Attacco Diffie-Hellman e MIM: Quando le varianti di algoritmi Diffie-Hellman come DHE, ECDHE ecc. Vengono utilizzate nell'handshake SSL per lo scambio di chiavi, possono diventare vulnerabili agli attacchi man in middle (MIM).

Supponiamo che l'handshake SSL sia iniziato e che sia ora di scambiare le chiavi, in modo che il cliente calcoli la sua parte chiave pubblica di DH e la mandi, ora il cattivo si siede nel mezzo lo intercetta e calcola la sua parte chiave pubblica di DH e invia esso. E poi entrambi calcola il segreto condiviso dalla reciproca chiave pubblica e viene stabilito il segreto condiviso. Ora anche se il traffico viene crittografato usando il segreto condiviso, ma poiché il cattivo ha fatto tutto questo, sarà in grado di decodificarlo. No?

In caso di RSA, dato che qualsiasi cosa criptata usando la chiave pubblica può essere decifrata solo usando la chiave privata, quindi è sicura. Sono sicuro di questo, ma con DH sto superando il dubbio.

Identità server: Supponiamo che il codice sia TLS_ECDHE_RSA ..... Ora, come ho capito, ECDHE è per lo scambio di chiavi e RSA è per dimostrare l'identità o l'autenticazione del server. Ma come RSA viene utilizzato per dimostrare l'identità del server o l'autenticazione perché è fatto con la firma digitale, giusto? Il client vedrà la DC del server firmata da una CA attendibile e identificherà e si fiderà del server. Quindi in che modo la parte "_RSA" o "ECDSA" della suite di crittografia entra in scena per dimostrare l'identità del server o per l'autenticazione?

Ho letto molte spiegazioni sull'algoritmo per la cosa sullo scambio di chiavi, ma mai sull'identità del server o per l'autenticazione dalla parte "cipratura" di _RSA "o" ECDSA ".

authentication diffie-hellman rsa

posta hagrawal 20.08.2015 - 01:52

fonte

2 risposte

Leggi altre domande sui tag authentication diffie-hellman rsa

Come steganografare le informazioni sulla proprietà in immagini caricate dai membri? Conflitto tra cipher-suite e certificato

score 2 · Answer 1

Diffie-Hellman and MIM attack: When variants of Diffie-Hellman algorithms like DHE, ECDHE etc. are used in SSL handshake for key exchange then can it become prone to man in middle (MIM) attack.

Suppose, SSL handshake has started and now it is time of key exchange, so client computes its public key part of DH and sends it, now bad guy sitting in the middle intercepts it and computes its public key part of DH and sends it. And then both computes the shared secret from each other's public key and shared secret is established. Now even though the traffic is encrypted using the shared secret but since the bad guy did all this, so he will be able to decrypt it. No?

In case of RSA, since anything encrypted using public key can only be decrypted using private key so it is safe. I am sure about this, but with DH I am getting above doubt.

Sembra che tu stia descrivendo qualcosa come lo scenario seguente ( fonte ):

Sinotichel'uomoalcentrosostituisceilcertificatoelachiavepubblicaperildominiolegittimoconilpropriocertelapropriachiavepubblicaprimacheiparametriDHvenganoscambiati.IlMITMutilizzaquindilapropriachiavepubblicaperfirmareiparametriDH.Ora,ciòchedovrebbeaccadereèchenonappenailclientericeveilcertificato,devecontrollarecheilcertificatosiaemessoperildominiochepensasistiaconnettendoa(ServerS).QuandovienepresentatoconuncertificatoperundominiodiversodalMITM(ServerA),deverifiutarequelcertificatoenonprocedereconloscambiodichiavi.Inunesempiopiùconcreto,consideraunclientechedesideraconnettersial link e invece di ottenere un certificato per il dominio google.com ottiene un certificato per il dominio evil.com (firmato da una CA attendibile). Ovviamente il client non dovrebbe interpretare questo certificato come valido.

Server identity: Suppose cipher is TLS_ECDHE_RSA..... Now, as I understand ECDHE is for key exchange and RSA is to prove server identity or authentication. But how RSA is used to prove the server identity or authentication because it is done with digital signature, right? Client will see the server's DC is signed by a trusted CA and he will identify and trust the server. Then how "_RSA" or "ECDCA" part of cipher suite comes into picture to prove server's identity or for authentication?

I have read a lot of algorithm explanation for key exchange thing but never about server's identity or for authentication from "_RSA" or "ECDCA" part of cipher suite.

Sì, il certificato che il MITM presenta potrebbe essere valido e firmato da una CA affidabile, ma il MITM non può ottenere un certificato per Server S.

Si noti che ci sono stati casi in cui il dominio nel certificato non è verificato rispetto al dominio a cui ci si sta collegando (come nel caso dell'app Chase mobile per un po '!), si può leggere su questi casi in questo carta , ma questo è un problema di implementazione, TLS correttamente implementato non consente questo scenario.

score 1 · Answer 2

But how RSA is used to prove the server identity or authentication because it is done with digital signature, right?

Sì. I parametri di scambio chiave sono firmati con la chiave a lungo termine del server. (Una tale chiave era principalmente RSA, ma ECDSA sta diventando abbastanza comune ora.)

Ulteriori letture

Vedi la sezione Scambio chiave nella risposta di Thomas Pornin qui: Come funziona SSL / TLS?