Quanto è sicuro aSSL (javascript)? Simula efficacemente SSL?

Naviga le tue risposte
15

Alcuni di voi potrebbero avere familiarità con il progetto aSSL, che utilizza AJAX / PHP per imitare il protocollo SSL. Utilizza RSA 512 o 1024 per le chiavi e AES per i dati effettivi. Mi sembra impressionante nel concetto, ma sono curioso di vedere se voi vedete delle intercettazioni ovvie che potrebbero / rivelerebbero le chiavi che vengono passate. Come tutti sappiamo, la tecnica di crittografia da JS a PHP è in genere inutile in quanto la chiave viene passata allo scoperto sul lato client. Questo sembra essere un approccio più avanzato.

Ecco i passaggi: 1. Il browser chiama il server per avviare il processo.

  1. Il server restituisce il suo modulo RSA e l'esponente pubblico.

  2. Il browser genera una chiave a 128 bit a scambio casuale, la crittografa utilizzando la chiave pubblica del server e passa la chiave di scambio crittografata al server.

  3. Il server riceve questa chiave di scambio crittografata a 128 bit, la decrittografa con la sua chiave privata e, se il risultato è ok, restituisce la durata della sessione.

  4. Il browser riceve la durata della sessione e imposta un timeout per mantenere attiva la connessione.

L'URL del progetto è qui: link

Se questo ha un potenziale, ho alcune idee su come migliorare ulteriormente l'handshake e garantire ulteriormente il lato client.

    
posta Jeremy P 23.11.2012 - 14:43
fonte

3 risposte

15

In che modo protegge dall'uomo negli attacchi centrali? Da quello che ho raccolto, non lo fa affatto (non riesco a pensare a un modo in cui potrebbe effettivamente). Ciò lo rende perfettamente inutile .

Il tipo SSL / TLS funziona perché ti fidi del software che ti dice che la connessione è sicura (nel solito caso il tuo browser). Quando scarichi il codice che ti dice che la connessione può essere attendibile da un utente malintenzionato, tutte le scommesse sono ovviamente disattivate.

Potrei sbagliarmi dato che la documentazione è piuttosto scarsa, ma non sembra affatto buona (per essere gentile).

    
risposta data 23.11.2012 - 15:21
fonte
13

I KNOW, I KNOW, I KNOW -- the second I mentioned javascript to php you guys rolled your eyes, but seriously, take a look first -- this is a bit different.

No, sfortunatamente, questo non è diverso. Crittografia Javascript considerata dannosa dovrebbe darti un buon riassunto di quali sono i problemi generali .

Alcuni problemi hanno a che fare con un'implementazione inadeguata (ad es. PRNG). Questo non è un difetto in JavaScript stesso (forse l'implementazione di Node.js potrebbe fare di meglio), ma nelle implementazioni del browser (su cui non puoi fare affidamento).

Altre questioni sono più fondamentali per il modo in cui viene utilizzato JavaScript. Il problema con qualsiasi libreria JavaScript che mira a emulare SSL / TLS nel browser è che farà sempre affidamento sul codice JavaScript fornito con o come parte dello stesso sistema del contenuto che mira a proteggere. Da quel punto, la battaglia contro un MITM è persa (vedi anche le sue stesse FAQ ).

Inoltre, un punto fondamentale di SSL / TLS è la verifica dell'identità del partecipante remoto. Questo si basa su (a) avere una serie di trust ancore (i certificati CA) già esistenti e (b) avere un modo coerente di visualizzare come è stata valutata la fiducia (integrazione della GUI all'interno del browser, mostrando un simbolo di blocco o simile). Questi elementi semplicemente non possono appartenere alla pagina Web (altrimenti chiunque può servire un'icona a forma di lucchetto su una pagina).

    
risposta data 23.11.2012 - 16:56
fonte
3

Per prima cosa mi viene in mente una debole entropia PRNG in JS. E potrebbe essere lento ... e perché non usare solo SSL?

    
risposta data 23.11.2012 - 14:47
fonte

Leggi altre domande sui tag

Come può un sistema imporre un numero minimo di caratteri modificati nelle password, senza memorizzare o elaborare vecchie password in chiaro? Lua loadstring, whitelisting contro l'iniezione