Voor zover ik zie is OpenSSL v1.0.1g van 7 april 2014 onderzocht (een update voor v1.0.1f met het Heartbleed lek), maar ik zie in security announcements van latere versies niet zo snel dat genoemde issues zijn gefixed of als onzin zijn beoordeeld.

Het lijkt inderdaad vooral te gaan om issues gerelateerd aan de CSPRNG (Cryptographically Secure Pseudo Random Number Generator), maar in veel gevallen lijken bewuste keuzes tussen security en performance daaraan ten grondslag te liggen - helaas zonder dat daar (door het OpenSSL team) veel ruchtbaarheid aan gegeven wordt.

Voorbeeld: als je de verbinding tussen jouw browser en een server (met OpenSSL) een DHE of ECDHE cipher suite gebruikt, suggereert dit dat er een uniek (= "ephemeral") Diffie-Hellmann (DH) sleutelpaar is gebruikt voor het uitwisselen van de symmetrische sleutel (tegenwoordig meestal AES). Mocht de versleutelde sessie door een aanvaller zijn opgeslagen, en de DH private key ooit herleid kunnen worden uit de public key, dan kan alleen die ene sessie worden ontsleuteld. Dit mechanisme staat bekend als (Perfect) Forward Secrecy.

Nou, perfect is het bij OpenSSL zeker niet, want by default genereert OpenSSL helemaal geen nieuw DH sleutelpaar voor elke verbinding. Dat doet OpenSSL kennelijk alleen als je deze compileert met de compilerflags SSL_OP_SINGLE_DH_USE en SSL_OP_SINGLE_ECDH_USE, en dat is niet de default. Als je naar die laatste flag Googled vind je pagina's waarin mensen klagen over serverperformanceverlies als ze dit aanzetten (zie bijv. https://crypto.stackexchange.com/questions/32265/degrade-in-performance-with-ssl-op-single-ecdh-use).

Nb. momenteel gebruikt mijn browser "TLS_ECDHE_RSA_WITH_AES_128_CGM_SHA256, 128 bit keys, TLS 1.2" voor de https verbinding met www.security.nl. Of daarbij daadwerkelijk sprake is van Forward Secrecy, is dus nog maar helemaal de vraag.

Noem me paranoïde, maar bij het genereren van RSA sleutelparen voor certificaten gebruik ik al enkele jaren een seperaat programma dat (onder invloed van muisbewegingen en/of toetsaanslagen) een bestand met willekeurige bytewaarden genereert. Met de OpenSSL parameter "-rand" meng ik vervolgens die bytes met de random bytes die OpenSSL zelf heeft gegenereerd. Ervan uitgaande dat OpenSSL dit mixen niet verklooit, heb ik in elk geval geen SPOF (Single Point Of Failure) bij het genereren van de noodzakelijke random numbers.

Off topic: als je CSPRNG persé wilt vertalen, gebruik dan iets als "Cryptografisch Veilige Pseudo Willekeurige Getallen Generator".

@erik van straten:
Volgens mij is het genereren van goede random nummers de taak van je omgeving, oftewel het OS voor programma's, of de browser voor websites. Ben zelf niet zo'n fan van zelf slimme dingen doen als de omgeving waarin je draait het nalaat.

Zie ook de discussies rondom getrandom en getentropy.

https://blogs.oracle.com/darren/entry/solaris_new_system_calls_getentropy

Dat laatste zeker niet: uitsluitend software kan onmogelijk cryptographically secure random numbers genereren, hooguit pseudo random, gebaseerd op security by obscurity (bijv. een timestamp hashen, en als je meer bytes nodig hebt, telkens de laatste hash zelf hashen en dat herhalen). Je hebt slecht voorspelbare (bij voorkeur onvoorspelbare) externe events nodig, en op een sub-seconde tijdschaal zijn die gewoon schaars.

OpenSSL maakt, onder Linux, gebruik van /dev/random of /dev/urandom; beide worden gevuld door het OS. Probleem: /dev/random is niet populair want het blokkeert als er onvoldoende entropie is, terwijl /dev/urandom niet blokkeert, maar je de kans loopt kwalitatief slechtere (eerder raadbare) random numbers terug te krijgen (zie http://dilbert.com/strip/2001-10-25 en https://xkcd.com/221/).

Met de toename van encryptie, en de noodzaak voor langere sleutels, wordt gebrek aan randomness een steeds grotere issue. Te veel programmeurs denken "not my problem", het OS regelt het maar (best begrijpelijk, je kunt dat ook niet fixen). En de programmeurs van het OS hebben er geen rekening mee gehouden dat het OS gevirtualiseerd wordt en/of dat er randomness nodig is direct na opstarten, nog voordat er netwerkverbindingen zijn gemaakt. Het lijkt vreemd dat niet elk device tegenwoordig een hardware RNG heeft - maar zo'n chipje kan weer een (nauwelijks te detecteren) achterdeurtje hebben. We rommelen dus maar wat aan...

Interesting. Ik volg het met name vanuit OpenBSD en ik weet dat die zeggen dat Linux het idd minder serieus neemt. Overigens lijkt me het hashen van een voorgaande random waarde prima, zolang je seed maar erg sterk is. Oftewel een non-block CSPRNG zou geen probleem mogen zijn, is wat ik daaruit haal.