MITM e replay attacca la prevenzione

6

Ho un client (un'app mobile) e un server, l'app si connette al server tramite SSL.

Il server utilizza un certificato autofirmato e il client ha un file (non sono del tutto sicuro di cosa, qualcosa da fare con bks e la verifica del nome host) che convalida il certificato.

Da quanto ho letto questo dovrebbe prevenire gli attacchi MITM, nel qual caso, a parte l'accesso fisico al client o l'accesso fisico / l'hacking del server, significa che il token di sessione è impossibile da usare in un attacco di replay.

Poiché gli utenti non vogliono voler accedere anche una volta al mese, il token dura per sempre (a meno che non si disconnettano o effettuino l'accesso su un nuovo dispositivo), posso solo pensare a un modo per aggirare questo, che è con ogni richiesta viene restituito un nuovo token, ma in tal caso un utente malintenzionato potrebbe essere in grado di rubare la sessione delle vittime.

Quindi domande:

1) Un certificato autofirmato con qualche tipo di convalida sul client (supponendo che nessuno dei due sia stato manomesso) protegge dagli attacchi MITM?

2) In caso contrario, è possibile impedire attacchi di riproduzione con token di sessione persistenti o interrompere il dirottamento se i token vengono rinnovati costantemente?

Non sono preoccupato di manomettere sul lato client i dati come se i dati degli utenti fossero privati, non potevano essere usati per causare altri danni.

EDIT: Per chiarire, intendo gli attacchi di replay usando i token di sessione, in pratica sto cercando di scoprire se l'uso di SSL (per impedire agli attaccanti di ottenere il token di sessione) è sufficiente per prevenire attacchi di replay, o se ho bisogno di ulteriori validazione sui token / client di sessione, e se sì cosa?

    
posta Ray Britton 06.06.2013 - 12:08
fonte

1 risposta

9

Gli attacchi min-in-the-middle in SSL sono impediti dal sicuro "che utilizza la chiave pubblica del server corretta e genuina. Questo elemento "che si assicura" è ciò che riguarda la convalida del certificato. Quando il certificato del server è autofirmato (ossia non emesso da un'autorità di certificazione attendibile), tale convalida deve essere eseguita in altro modo. Un metodo semplice, che funziona, è quando il client conosce già il certificato del server (è incorporato nel proprio codice): il certificato dal server viene convalidato da un semplice confronto bit-to-bit. Esistono molti modi per effettuare tale convalida e molti modi per renderlo inaccessibile, quindi non posso dire se il tuo metodo specifico sia corretto o meno.

Gli attacchi di replica sono una bestia completamente diversa e non sono correlati alla autofecondazione del certificato del server. Per farla breve, gli attacchi replay in SSL non funzionano, perché sia client che server includono valori casuali nei loro messaggi iniziali di handshake ( ClientHello e ServerHello - vedi overviewhandshake nello standard) e questi valori casuali vengono utilizzati in tutte le successive operazioni crittografiche, impedendo il riutilizzo raw del traffico di rete precedentemente acquisito (che è cosa sono gli attacchi di replay). Gli stessi dati (ad esempio lo stesso token di sessione) verranno nuovamente codificati, con una nuova chiave di sessione per ogni nuova connessione SSL.

    
risposta data 06.06.2013 - 13:11
fonte

Leggi altre domande sui tag