Newsgroup: it.comp.www.php
Titolo: Criptazione RSA (e sicurezza RIA)

Salve a tutti, per un applicativo che sto sviluppando in flex+php dove
il client (FLEX) comunica con il server (PHP) attraverso il protocollo
AMF, ho la necessità di implementare un layer di criptazione (è molto
importante la parte FLEX->PHP, meno la parte di comunicazione PHP->FLEX).
Il fatto che le app flex siano facilmente deassemblabili rende del tutto
inutile un layer di criptazione che non sia a chiave pubblica/privata
(questo farebbe si che nessuna chiave venga memorizzata nell'app flex).
Con un sistema a chiave publica/privata dovrei raggiungere una sicurezza
accettabile ed anche un attacco men-in-the-middle non dovrebbe essere in
grado di minare la stabilità del sistema, perchè sarebbe si in grado di
vedere in chiaro le risposte di PHP spedite a FLEX, ma non sarebbe
comunque in grado di capire le richieste da FLEX a PHP, giusto?
Per quanto riguarda il client FLEX ho trovato un componente che esegue
tutte le operazioni per la criptazione usando il sistema RSA, per php
non trovatò alcunchè, se non una classe ma è veramente lentissima ed
inutilizzabile.
Prima di mettermi a reinventare la ruota scrivendo una classe apposta,
mi chiedevo se qualcuno di voi conoscesse una classe (o una funzione o
qualsiasi cosa) che già faccia tutto ciò.
O eventualmente un sistema alternativo per mettere in sicurezza le
comunicazioni
Grazie
J.


Non so se ho capito correttamente la questione, ma non dovrebbe bastarti 
andare in https?
M



L'https è una possibile soluzione, ma vorrei che la comunicazione fosse
sicura a prescindere dal mezzo, anche perché l'https non è che sia non
decrittabile, anzi è sufficiente un qualsiasi prodotto della categoria
"web debugging proxy" per avere tutto il traffico in chiaro, e quindi va
considerato un mezzo insicuro.
Però mentre sto scrivendo mi viene in mente che anche usando rsa, nel
caso di disassemblaggio del client flex, il disassemblatore avrebbe
accesso alla chiave privata del client, quindi tutto sarebbe piuttosto
inutile, o sbaglio? [però a questo punto mi sa che sono finito offtopic]
Ad ogni modo, conoscete qualche implementazione dell'RSA in php? :)
J.

 considerato un mezzo insicuro.
a me questa affermazione pare completamente errata.
Certo https è sicuro in caso di certificati validi rilasciati da 
autorità attendibili. Poi se l'utente clicca su CONTINUA -> CONTINUA -> 
ACCETTA -> NON ME NE FREGA NULLA -> CONTINUA pur di accettare un 
significato self-signed... beh.. non è un problema dell'applicazione.

 
Se ti installi ad esempio il Charles, per dirne uno, ed importi i
certificati, vedrai che riuscirai a vedere il traffico https in chiaro,
l'https č sicuro una volta che ha lasciato il tuo computer, prima non lo č.
Mi spiego meglio, se ho il metodo sul server salvaRecord($id,$valore),
anche se lo faccio passare in https, l'utente puň intervenire e passare
sia id che valore con un valore qualunque, usando appunto il proxy.
Se invece l'app cifra il tutto quello che esce dall'app č giŕ sicuro. Il
problema č che il flex (cosě come il flash) č facilmente deassemblabile
e quindi l'eventuale chiave RSA privata usata verrebbe rivelata.
Per questo mi sa che in fondo l'unica sicurezza per le RIA (flex in
particolare) sia fare il piů possibile metodi senza tanta flessibilitŕ,
cioč anziche salvaRecord($id,valore) un metodo ad esempio
aumentaValorediUno($sessionId) o diminuisciValoreDiTre($sessionId) ed un
sistema di sessioni.
J.

 l'https è sicuro una volta che ha lasciato il tuo computer, prima non lo è.
Per tuo computer intendi il server (apache) o il client (Firefox)
Se intendi il client , stai dicendo che vuoi trovare un modo per usare 
una connessione sicura su un computer potenzialmente compromesso ?
La vedo dura...

 sistema di sessioni.
La minore flessibilità dei metodi mi sembra solo un problema per gli 
sviluppatori, non un fattore che incrementi la sicurezza.
Come indichi va invece usato un sistema come le sessioni (lato server, 
anche se poi l'identificazione avviene tramite intervento lato client). 
Vi sono anche altre alternative ma il concetto di fondo è quello: 
separare l'invio di dati applicativi da quello di dati relativi la 
sicurezza.
Restando in ambito PHP e relative sessioni (da Flex) qui trovi un 
articoletto riassuntivo:
http://corlan.org/2008/07/22/flex-air-php-and-user-authentication/
qui del codice pratico:
http://flexaired.blogspot.com/2008/08/php-session-in-flex.html
Prova a vedere, in caso ci si risente.

 La vedo dura...
anche io la vedo dura, ma non per questo credo non si debba cercare un
soluzione.
J

 Prova a vedere, in caso ci si risente.
Lo so come creare un sistema di sessioni, infatti non era questa la
domanda originale :)

 domanda originale :)
Io ho segnalato un errore in una affermazione (riguardo la sicurezza di 
https). Errore che poteva dare adito a "reinventare la ruota" (ti cito 
;-) ) senza che ce ne fosse la necessità.
Vorrei capire nei link che ho postato cosa ci sia che non ti convince, 
di non adatto alla tua situazione.
Comunque se la domanda era questa:
 > Con un sistema a chiave publica/privata dovrei raggiungere una
 > sicurezza accettabile ed anche un attacco men-in-the-middle non
 > dovrebbe essere in grado di minare la stabilità del sistema,
 > perchè sarebbe si in grado di vedere in chiaro le risposte di
 > PHP spedite a FLEX, ma non sarebbe comunque in grado di capire
 > le richieste da FLEX a PHP, giusto?
credo che ti siano state date tutte le indicazioni per una risposta:
- men-in-the-middle non può vedere in chiaro nulla, se non 
autorizzandolo esplicitamente;
- https è un sistema asimmetrico (a doppia chiave) per cui quel che vale 
per il tuo discorso vale anche per https.

 soluzione.
Non è questione di "durezza": non esiste una soluzione. Se hai un pc 
"compromesso" non puoi stabilire una connessione sicura.
E' come voler costruire un ponte potendo appoggiarlo solo ad una 
estremità :-)


era infatti il dubbio che avevo

 per il tuo discorso vale anche per https.
Hai dimenticato il pezzo nel quale chiedevo se conosceste una classe php
per l'RSA che fosse utilizzabile, perchè l'unica che ho trovato è lentissima

 per l'RSA che fosse utilizzabile, perchè l'unica che ho trovato è lentissima
Magari se dici quale classe hai provato... ;-)
Comunque ribadisco che usare una classe di questo tipo o usare https è 
esattamente equivalente sul piano metodologico; col secondo hai inoltre 
delle infrastrutture già pronte e tendenzialmente più solide (e non devi 
scrivere codice ex novo, soggetto a potenziali bug e quindi ad altre 
vulnerabilità di sicurezza).


Posso assicurarti che adesso è possibile ANCHE non far comparire più 
"accetta,accetta,accetta,blablablabla", a quanto ho capito basta usare 
"sslstrip".
Non ho mai provato,ma ho visto un video del programmillo in azione e 
SEMBRA che faccia ciò che dice...

 SEMBRA che faccia ciň che dice...
Dire "basta usare" mi sembra a dir poco riduttivo... ;-)
sslstrip funziona basandosi sul problema noto come ARP poisoning che non 
č banale da attuare, senza contare che si puň utilizzare solo 
all'interno di una stessa LAN.
A questo punto si legge tutto il traffico HTTP e solo piccole parti 
dell'HTTPS, tipo gli header. I contenuti crittati continuano ad esserlo.
Ricapitolando: o si alterano le chiavi/certificati (e il browser lo 
segnala) o si decritta il contenuto (usando algoritmi solidi e chiavi 
sensate -almeno 1024 bit- non č matematicamente fattibile) o si usano 
chiavi/certificati rubate.
Sinceramente credo che i problemi locali (es. usare un S.O. non messo in 
piena sicurezza, cosa assolutamente non banale da fare) siano molto piů 
frequenti e molto piů rischiosi di queste casistiche "borderline" :-)