Sì, c'è un rischio qui, anche se è quasi del tutto limitato nella portata della rete / utenti di tali dispositivi proxy / firewall. L'entropia bassa potrebbe anche avere un effetto molto minore sul client nonce nell'handshake TLS che influisce sulle connessioni in uscita dal dispositivo proxy / firewall.
L'entropia bassa potrebbe significare valori primi probabili, il che significa chiavi private indovinate, che possono condurre a attacchi MITM vitali. Se c'è un problema di bassa entropia su tale sistema e la chiave CA è la prima cosa generata, allora potrebbe avere un vero problema .
(C'è un ovvio beartrap con tali sistemi se si utilizza una chiave o una CA condivisa o venduta, ma è piuttosto una problema diverso).
Il rischio maggiore è generalmente assegnato a problemi di verifica della catena e della revoca e una configurazione inadeguata che porta all'utilizzo di crittografia o crittografia legacy non sicura, vedere US CERT TA17-075A L'intercettazione HTTPS indebolisce la sicurezza TLS (a questo aggiungerei una protezione insufficiente delle chiavi private, almeno un prodotto commerciale supporta HSM, sebbene Sospetto che funzioni solo per la CA interna piuttosto che per i certificati su richiesta).
Il potenziale problema qui è che se l'entropia è bassa, i numeri primi possono essere prevedibili - ma questo da solo non rende il modulo più semplice da calcolare (per determinare la chiave privata). fa rende praticabile un attacco di forza bruta, in questo caso l'input PRNG forzato brute (il hacker sa il PRNG) per tentare di scoprire un primo (e quindi una chiave) che è in uso.
Se sei un malvagio amministratore con accesso a un tale proxy da cui puoi raccogliere chiavi e certificati, allora hai il mazzo impilato in il tuo favore se stai attaccando il proxy di qualcun altro.
Come utente malvagio potresti essere in grado di generare abbastanza traffico per trovare collisioni, ma questo è meno interessante.
In pratica (certamente nel caso di OpenSSL) viene utilizzato un PRNG per generare il materiale sorgente chiave (a cerca i numeri primi ), quindi è necessaria una minima entropia" reale ". Un proxy è generalmente un buon candidato per la raccolta di entropia dagli eventi di timing e hardware (rete e disco potenzialmente occupati, con molte connessioni casuali).
Ho stimato che approssimativamente 90-100kiB di output PRNG sarebbero generalmente richiesti per una generazione di chiavi a 2048 bit (2x primi 1024 bit, con un algoritmo di generazione / test / scarto ingenuo), che richiede solo una manciata di byte non PRNG di "reale" entropia da seme (32 byte per osservazione). Il ritardo nella generazione della chiave è in realtà il test di primalità .
Per le implicazioni dei tasti a bassa entropia puoi leggere la carta (spiritosamente intitolata) Estrazione di Ps e Q: Rilevazione di diffuse chiavi deboli nei dispositivi di rete (PDF).
Esistono due documenti utili che trattano i problemi di sicurezza relativi all'uso di tali proxy:
Ciò solleva molti altri problemi di sicurezza, ma casualità / entropia viene solo brevemente menzionato nel secondo:
Entropy during generation.
It is possible that the entropy
used during the generation of a new public/private key pair
in install-time generated certificates is inadequate. In practice,
since most products we analyzed generate a root certificate
with RSA keys using OpenSSL, the generation process is
expected to call certain known functions, e.g., RAND_seed(),
RAND_event(), RSA_generate_key_ex(); we found
calls to the last function in many cases. However, we did not
investigate further the key generation algorithm in CCAs.
Vedi anche: