L'uso di jCryption 3.0 + SSL avrebbe mitigato la vulnerabilità Heartbleed?

Question

L'uso di jCryption 3.0 + SSL avrebbe mitigato la vulnerabilità Heartbleed?

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

2

Mi sono imbattuto in un progetto chiamato jCryption 3.0, che crittografa i dati tra client e server, senza utilizzare SSL. Se JavaScript di un sito Web avesse utilizzato jCryption 3.0 per crittografare i campi del modulo di accesso prima di inviarli (su SSL) al server, questa tecnica avrebbe mitigato un potenziale attacco Heartbleed?

Questa domanda assume quanto segue:

SSL viene utilizzato per verificare l'identità del sito e fornire un secondo livello di crittografia
jCryption 3.0 viene utilizzato per crittografare tutti i dati sensibili inviati tra client e server, anche su SSL
Il server su cui il browser invia messaggi è un servizio di bilanciamento del carico (che esegue una versione vulnerabile di openssl), che decrittografa il traffico in entrata e lo invia a un server Web per un'ulteriore elaborazione

Da quanto ho capito, qualcuno che esegue un attacco Heartbleed sul bilanciamento del carico vulnerabile sarebbe potenzialmente in grado di scoprire solo nome utente & i dati della password o la chiave privata del server dalla memoria.

javascript openssl heartbleed

posta Jay Sheth 16.04.2014 - 19:09

fonte

2 risposte

Leggi altre domande sui tag javascript openssl heartbleed

Il seguente codice semina il PRN di OpenSSL necessario, superfluo o dannoso? Classificazioni SIP SIP

score 1 · Answer 1

Il server deve decrittografare le informazioni. Una volta decifrato, è nella memoria di processo del server in chiaro. Allora sarebbe trapelato da heartbleed.

Inoltre, il server deve avere la chiave di decodifica. Quindi verrebbe probabilmente memorizzato nella memoria del processo e sarebbe recuperabile tramite attacchi heartbleed.

score 0 · Answer 2

Credo che l'autore dell'attacco possa teoricamente recuperare la chiave privata per il certificato SSL del server, MITM la sessione e quindi compromettere la libreria JS che si invia al client. Tuttavia, si tratta di un trucco piuttosto elaborato e (data l'efficacia quasi al 100% di SSLStrip) probabilmente non varrebbe la pena. Quindi sì, aiuterebbe mitigare il problema, ma non al 100%.

Un modo per mitigarlo ulteriormente è archiviare le chiavi pubbliche / private nella memoria lato client del browser o eseguire alcune impronte digitali dell'ambiente JS del client e del browser stesso. Tuttavia, anche questa sarebbe la crittografia best-effort: se il browser scarica le tue chiavi di archiviazione non hai altra scelta che generarne di nuove. Potresti essere in grado di chiedere al cliente di eseguire un'autenticazione fuori banda o semplicemente utilizzarla come metodo per verificare i client mentre stai lavorando alla rigenerazione dei certificati TLS e alla revoca di quelli vecchi ....