Come risolvere l'algoritmo SSL per maggiore sicurezza [duplicato]

Naviga le tue risposte
4

SSL utilizza la crittografia asimmetrica in questo modo:

  1. Il server invia una copia della sua chiave pubblica asimmetrica.
  2. Il browser crea una chiave di sessione simmetrica e la crittografa con la chiave pubblica asimmetrica del server.
  3. Il server decrittografa la chiave pubblica asimmetrica con la sua chiave privata asimmetrica per ottenere la chiave di sessione simmetrica.
  4. Server e Browser ora crittografano e decodificano tutti i dati trasmessi con la chiave di sessione simmetrica.

Ma cosa succede se qualcuno ascolta questa comunicazione nel "passaggio 1" e lo fa:

  1. Ascolta le comunicazioni tra server e client nel passaggio 1.
  2. Quando il server invia una copia della sua chiave pubblica asimmetrica, l'hacker la modifica nella propria chiave pubblica (che ha anche la sua chiave privata) e la invia al client.
  3. Il client crea una chiave di sessione e la crittografa con la chiave pubblica di hacker.
  4. Hacker ascolta la linea e ottiene la chiave di sessione e la decrittografa con la sua chiave privata.

Quindi ottiene qui la chiave di sessione. e poi ..

  1. L'hacker crittografa la chiave di sessione (decrittografata) dall'ultima chiave pubblica (quel server inviato)
  2. Quindi l'hacker ha ora la chiave di sessione ...

Ho usato questo algoritmo nel mio progetto per la comunicazione tra server e client. non c'è alcuna certificazione tra di loro. è giusto che aggiungo alcuni caratteri in chiave pubblica e il client li controlli e lo renda valido?

Come possiamo risolverlo? qualche idea?

    
posta Elahe 02.10.2014 - 07:28
fonte

3 risposte

8

TLS non è rotto, solo la tua comprensione di TLS;)

Il TLS completo è spiegato in questa risposta ma per rispondere alla tua domanda concreta:

  • Il server non invia la chiave pubblica semplicemente al client. Il server invia un certificato (catena) al client.
  • Il client verifica i certificati del server con uno dei certificati affidabili nel suo archivio.

Quindi per usare un MitM (Man in the Middle) -Attacco come hai descritto l'attaccante deve sostituire il certificato del server (che è anche possibile ma molto più difficile).

Un certificato è la chiave pubblica firmata da una CA (Certification Authority). Quindi il cliente può verificare i certificati del server verificando la firma su tale certificato.

Tutti i certificati hanno una catena di certificati firmati fino a un certificato autofirmato. Questo certificato autofirmato è chiamato certificato di origine ed è già incluso nel tuo browser.

È possibile creare la propria CA emettendo un certificato di origine e utilizzarlo per firmare i propri certificati. Devi quindi solo importare il certificato radice creato nell'archivio certificati del browser. Questo è solo fattibile per le piccole basi di utenti o per le aziende con aggiornamenti ai browser.

    
risposta data 02.10.2014 - 07:45
fonte
2

Ciò che ti manca è l'autenticazione, ovvero conferma che la chiave pubblica ricevuta è stata effettivamente inviata dal server.

In https, ad esempio, viene utilizzato il sistema dell'autorità di certificazione. Alcune organizzazioni vengono scelte come affidabili. Queste organizzazioni producono una chiave pubblica che viene quindi inclusa nei browser. Pertanto, quando scarichi firefox, ad esempio, è incluso un set di certificati CA affidabili. Quindi, quando ci si connette a un sito tramite https, il browser controlla se il certificato fornito dal server è firmato da uno dei certificati CA attendibili.

Le CA hanno quindi il compito di ricevere le richieste di firma dei certificati e di verificare che siano inviate dai veri proprietari di quel sito.

In un progetto personale, questo significa che è necessario includere la chiave pubblica del server da qualche parte, per verificare il certificato ricevuto.

    
risposta data 02.10.2014 - 07:52
fonte
0

Questo attacco non funziona perché il client convalida il certificato del server. Se un man-in-the-middle (l'hacker, nel tuo scenario) sostituisce la chiave pubblica del server con il proprio, allora il certificato non si convalida, il client sa che qualcosa non va e interrompe la transazione. Il client non utilizzerà la chiave pubblica errata per crittografare la chiave di sessione, quindi questa non è una minaccia.

    
risposta data 02.10.2014 - 07:39
fonte

Leggi altre domande sui tag

Algoritmo di crittografia a più chiavi [duplicato] È corretto considerare gli audit esclusivamente come "detective" in natura?