Come far rotolare il mio meccanismo di sicurezza - evitare SSL

Naviga le tue risposte
7

Sto cercando di implementare il mio meccanismo di sicurezza piuttosto che usare SSL perché SSL è 'disperatamente rotto ' e anche perché è un esercizio interessante :)
Questo è per un'applicazione internet client-server.

Caveat - Non sono un esperto di sicurezza - ho appena letto sulla sicurezza.
Creerò anche l'applicazione client, quindi avrò il controllo dell'implementazione su entrambi i lati.

Problema SSL

Il problema principale che vedo con SSL è dovuto allo scambio di chiavi pubbliche nella fase di handshake e un uomo nel mezzo che intercetta questo. SSL tenta di evitare questo problema utilizzando la firma di messaggi e certificati ecc per convalidare la chiave pubblica del server per il client. Ma un attaccante con un certificato contraffatto può ancora aggirare questo.

Soluzione

A causa di questo problema di scambio sicuro di chiavi pubbliche, penso che questo possa essere evitato semplicemente non dovendo scambiare la chiave pubblica del server, avendo "conosciuto" la chiave pubblica del server incorporata in ogni applicazione client. Pronuncia una chiave RSA a 3072 bit.

Attuazione

  1. L'implementazione per ogni sessione di comunicazione sarebbe quindi il client genera una coppia di chiavi RSA pubblica / privata
    2. Il client
  2. crittografa la sua nuova chiave pubblica con la chiave pubblica del server e la invia al server
    3. Il server
  3. decrittografa il messaggio per scoprire la chiave pubblica del client e quindi lo utilizza per crittografare le risposte al client
    4. Il client
  4. continua a inviare traffico al server crittografato con la chiave pubblica del server
  5. ogni messaggio inviato dal client contiene anche nell'intestazione:
    1. il nome utente del client crittografato con la chiave pubblica del server
    2. un hash del messaggio client non crittografato - utilizza come input per generare questo hash, un altro hash di [nome utente + realm + password client]

Osservazioni

  • Il server può dimostrare l'identità del client decodificando prima il messaggio utilizzando la sua chiave privata e quindi calcolando l'hash del messaggio non crittografato utilizzando l'hash di [nome utente + password + password] che ha memorizzato nel suo database.
  • L'uomo nel mezzo non può monitorare il traffico poiché è crittografato in entrambi i modi
  • L'uomo nel mezzo non può rappresentare un client perché non può generare un hash del messaggio valido
  • L'uomo nel mezzo non può rappresentare un server perché poiché non può decrittografare il messaggio iniziale, non può scoprire la chiave pubblica del client in cui crittografare le risposte al client
  • La password del client stessa è protetta dallo scrutinio della forza bruta poiché l'hash che utilizzava la password del client come input è contro il messaggio non crittografato, quindi l'attaccante dovrebbe prima decodificare il messaggio prima di iniziare un attacco di forza bruta contro questo hash

Visto che non sono un esperto di sicurezza spero che qualcuno che sa qualcosa di più sulla sicurezza possa individuare eventuali buchi in questo approccio, o confermare se è buono. E anche se una chiave RSA a 3072 bit può sopportare il test del tempo senza essere interrotta.

Grazie!

    
posta DaManJ 02.12.2011 - 15:25
fonte

4 risposte

5

Ho deciso di andare con SSL perché alla fine è diventato l'approccio più semplice - l'altra idea non funzionava bene sul lato WCF.

Ho scritto questo sul progetto di codice per aiutare gli altri ad avere un problema simile.

link

Avrei ancora bisogno di capire come fidarmi solo della mia chiave pubblica e nessuna chiave CA - osservando as3cryptolib potrebbe essere possibile con la proprietà CAStore sul TLSConfig - link

    
risposta data 07.12.2011 - 00:24
fonte
23

Stai confondendo SSL / TLS con il suo schema di utilizzo più comune, che è TLS in congiunzione con i certificati X.509 e un'infrastruttura a chiave pubblica (PKI, RFC 5280 ).

Anche se è molto importante proteggere una connessione TLS autentificando il suo sito server (per prevenire attacchi MITM attivi), la specifica TLS in realtà non obbliga a farlo usando certificati X.509, ancor meno usando una PKI.

Come ha detto @jathanism, puoi scegliere di non fare affidamento su una PKI gerarchica, utilizzando un certificato X.509 autofirmato. Dovrai stabilire la fiducia nel certificato del server con altri mezzi.

Inoltre, TLS può essere utilizzato anche con certificati OpenPGP , Kerberos o Chiavi pre-condivise .

TLS stesso ha avuto pochissimi bug noti per quanto ne so, ad es. c'era il bug di rinegoziazione (CVE-2009-3555), che è stato corretto (più recentemente, c'erano anche alcuni problemi con determinati codici a blocchi, che possono essere risolti scegliendo suite di crittografia migliori o aggiornando a versioni più recenti di TLS).

I problemi di cui parli (e spesso discussi nella stampa) tendono ad essere correlati ai PKI, cioè come stabilire la fiducia nella parte remota. Come ciò dovrebbe essere fatto non è dettato dalla specifica TLS stessa.

Se vuoi provare a trovare un modo migliore, fai qualche ricerca, ma ti suggerisco di concentrarti su questa parte e lasciare SSL / TLS e il lato crittografico delle cose da solo. Probabilmente scoprirai che i maggiori problemi riguardanti gli PKI e le loro alternative sono amministrativi, non molto tecnici.

L'altro aspetto dell'autenticazione del party remoto è verificare che tu stia parlando con la parte interessata (ad esempio verifica del nome host ).

    
risposta data 02.12.2011 - 20:14
fonte
9

Se hai il controllo di entrambi i lati, utilizza i certificati SSL autofirmati. Fatto. Non ti stai fidando di un'autorità di certificazione di root e quindi la tua crittografia diventa quasi impossibile da decifrare senza una conoscenza interna dell'architettura.

    
risposta data 02.12.2011 - 15:30
fonte
1

Non è SSL il meccanismo che è "irrimediabilmente rotto", ma piuttosto SSL v3.0 (e SSL v2.0) le versioni delle specifiche.

Dopo SSL v3.0, la specifica è stata rinominata in TLS. TLS 1.0 è ancora considerato sicuro. Ti consigliamo di utilizzare TLS 1.2.

E, sì, come altri hanno già detto, non pensare nemmeno a far girare il tuo. Cercando di eseguire il rollover da qualcuno che non conosceva abbastanza crittografia è il motivo per cui la crittografia WiFi iniziale potrebbe essere risolta in pochi secondi o minuti. Hanno iniziato con un algoritmo debole, e poi attraverso problemi di implementazione ulteriormente indebolito.

    
risposta data 05.04.2015 - 19:20
fonte

Leggi altre domande sui tag

Qual è il modo migliore per proteggere l'accesso a un sito Web senza SSL o chiavi già condivise? Esistono misure di sicurezza resistenti a un attacco di forza bruta?