se Noscript è sicuro è possibile che il nostro sistema sia ancora compromesso da cripto?

Question

se Noscript è sicuro è possibile che il nostro sistema sia ancora compromesso da cripto?

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

0

forse tutti noi usiamo no-Script quando visitiamo pagine Web non fidate per bloccare tutti i plug-in di script ecc., ma c'è ancora qualcosa accanto a semplici codici HTML che non blocchiamo; Connessione SSL! nel protocollo Https qualsiasi pagina web può inviarci dati crittografici che è gestita da Firefox NSS lib e si basa quasi sempre su due cose, AES e RSA. secondo me la crittografia o la decifrazione dei dati ricevuti da un sito non affidabile devono essere sicuri perché le librerie crittografiche non sono come un flash player che dà la possibilità a chi attacca di fare infiniti codici possibili ed eseguire .. per esempio in AES sta processando ogni byte con pochi noti cicli per crittografarlo o decodificarlo ed entrambi sono quasi uguali e in RSA è solo una funzione matematica su un numero, perché il calcolo dei numeri dovrebbe causare un buffer-overflow? la domanda è:

è possibile raggiungere un compromesso con la crittografia / decrittografia AES ?
è possibile raggiungere un compromesso con la decifrazione RSA (se l'hacker conosce la chiave privata o non lo sa)

web-browser buffer-overflow

posta user20876 17.02.2013 - 17:42

fonte

3 risposte

Leggi altre domande sui tag web-browser buffer-overflow

Backup volume nascosto TrueCrypt [chiuso] Quanto è sicuro il processo di hashing / salting / stretching come descritto in questo diagramma?

score 5 · Answer 1

Gli algoritmi crittografici non sono interpreti per un linguaggio equivalente a Turing. In quanto tali, non possono essere significativamente confrontati con il supporto per gli script, che Noscript disattiva.

Le implementazioni degli algoritmi crittografici sono raramente afflitte da overflow del buffer, ma possono perdere alcuni dati altamente sensibili (come le chiavi crittografiche) se implementate in modo inesperto. Una fonte più comune di vulnerabilità è la gestione dei certificati X.509 (ad esempio, vedere questo per OpenSSL ), perché la decodifica dei certificati può essere un compito scoraggiante a causa del suo (ab) uso di tutte le complessità di ASN.1 .

score 2 · Answer 2

Stai chiedendo se è possibile trovare un difetto nel meccanismo SSL, in modo che tu possa eseguire un exploit su un computer vittima.

Questo è altamente improbabile, lo scopo della connessione crittografata è chiaro e l'implementazione è anche testata e abbastanza severa.

Se l'altro capo non parla SSL e dice che lo fa, il browser interromperà la connessione non appena qualcosa non va.

Non appena verifichi di essere nel dominio giusto e di avere un certificato valido, dovresti essere sicuro nella maggior parte dei casi (eccetto il caso in cui sia un server DNS che un'autorità di certificazione sono compromessi).

score 0 · Answer 3

Per darti una risposta breve e chiara: Sì, in teoria è possibile essere compromessi semplicemente visitando view-source: http s : //attacker.in.

Tuttavia la maggior parte della crittografia si concentra molto sulla gestione degli errori (ad esempio, qualcuno che manomette il flusso crittografato non dovrebbe imparare nulla sul testo in chiaro), quindi, proprio come gli altri, penso che sia altamente improbabile che esista un difetto (sfruttabile) in questa parte del codice.

Un utente malintenzionato potrebbe anche trovare un difetto nell'immagine / css-rendering o forse ignorare NoScript con una sorta di charset misto intelligente (mentre NoScript è fantastico (!!), quindi non è perfetto al 100% - niente è).