il www del brics

[lnessuno]

Snowden diceva che la criptazione può aiutare, ma i problemi stanno a monte. Non serve craccare o mettere backdoor negli algoritmi, se puoi avere un accesso per controllare chi li produce.

Ti giro un commento di "Uriel Fanelli", personaggio odioso ma che qualche volta ha il dono della sintesi:
http://www.ilpost.it/2013/09/06/nsa-dati-cifrati/

Non c'e' alcun bisogno di arrivare a tanto. Lo spiegava anche Snowden: la crittazione vi puo' aiutare, ma la protezione delgli endpoint e' troppo debole. Parliamo di crittazione, che sul traffico internet e' quasi sempre https. Bene, i certificati che avete sul browser sono di aziende che non conoscete. Basta che il governo USA ne possieda una*, e puo' produrre certificati validi per qualsiasi dominio. A quel punto basta mettersi in mezzo e non serve nemmeno rompere il codice. E' l'intero stack ad essere debole, non serve assalire la cifratura quando puoi assalire gli endpoint con due lire.

* RSA?

Lettura interessante
http://www.zdnet.com/how-the-nsa-and...sl-7000016573/

[MItaly]

Snowden diceva che la criptazione può aiutare, ma i problemi stanno a monte. Non serve craccare o mettere backdoor negli algoritmi, se puoi avere un accesso per controllare chi li produce.

La questione che citi è ancora differente; come dici, non è un problema di produrre algoritmi o di inserire backdoor, ma di compromettere la "catena di fiducia" (chain of trust).

Da qualche parte, in una comunicazione sicura basata su crittografia asimmetrica, Alice e Bob devono avere qualcosa in comune - ovvero, Alice deve avere un modo per sapere che Bob è davvero Bob; questo scopo normalmente in un contesto basato su PKI si raggiunge tramite le Certification Authorities.

Alice nel computer di default ha installati un tot di certificati (i root certificates), corrispondenti ad alcune autorità di certificazione che si postulano come "fidate"; nel momento in cui deve parlare con Bob, per verificare che sia davvero lui, controlla il certificato che le viene inviato: per fidarsi, devono valere due condizioni:

1. il certificato che Bob propone come suo è stato rilasciato effettivamente a Bob (ovvero, il nome DNS contenuto nel certificato è effettivamente quello del server a cui ci si è collegati);
2. il certificato deve essere stato rilasciato (ovvero, firmato digitalmente) da una CA di cui Alice si fida, oppure da una CA sconosciuta, ma il cui certificato a sua volta è stato rilasciato da una CA nota (questa cosa può andare avanti ricorsivamente per diversi livelli).

Ora, è ovvio che se Alice ha tra i certificati fidati un certificato generato da Eve l'intera sicurezza della questione va a ramengo, dato che ora Eve può generare certificati di cui Alice si fida, e impersonare qualunque host (a patto naturalmente di poter intercettare le comunicazioni di Eve, ma questo in ambito crittografico si dà giustamente per scontato).

Come si risolve il problema? Da quel poco che ne so, ci sono sostanzialmente due sistemi diffusi:

• paranoia: mi fido solo dei certificati emessi da una mia CA, di cui so esattamente quali sono le politiche di emissione di certificati, e so con certezza che non è stata compromessa. Questo è un sistema di base non molto pratico per un uso generale, ma è fondamentale quando è richiesto un elevato grado di sicurezza; inoltre, è applicabile facilmente nel momento in cui tutti gli endpoint sono sotto il mio controllo (ad esempio, nel caso di VPN, o di una mia applicazione custom) e posso quindi evitare di dover tirare in ballo altre persone/istituzioni e decidere se fidarmi di loro o meno.
  D'altro canto, se applicato su ampia scala, potrebbe essere la soluzione al problema che vorrebbe risolvere questa nuova rete: i BRICS fanno delle loro root CA e ignorano quelle attuali nei loro browser/applicazioni basate su SSL; compromettere una CA statunitense a questo punto non serve a niente, visto che parte come "non fidata" fin da principio.
• anarchia: invece della "chain of trust" (dove se cede l'anello più debole della catena tutta la sicurezza è compromessa) uso una "web of trust", in cui si decentralizza il problema della fiducia, che a questo punto deriva dalla fiducia che diverse altre persone (che dovrebbero aver verificato l'identità del possessore in maniera indipendente) hanno nel certificato. Sicuramente funziona, ma è difficile estendere al grande pubblico, che giustamente non sa e non vuole sapere cosa sia una chiave pubblica, e in base a cosa ci si possa fidare.