image

Duitse overheid vindt beveiligingsproblemen in OpenSSL

woensdag 3 februari 2016, 09:34 door Redactie, 5 reacties

De Duitse overheid heeft een onderzoek naar OpenSSL laten uitvoeren waarbij verschillende problemen en kwetsbaarheden aan het licht zijn gekomen. OpenSSL is een populaire softwarebibliotheek voor het versleutelen van verbindingen, bijvoorbeeld tussen websites en hun bezoekers.

Omdat het zo populair is en een belangrijke rol vervult besloot het Bundesamt für Sicherheit in der Informationstechnik (BSI) een onderzoek naar de willekeurige cijfergenerator van OpenSSL en cryptografische werking van de software uit te laten voeren. Het onderzoek werd door het Duitse beveiligingsbedrijf Sirrix AG uitgevoerd. Het rapport werd vorig jaar al opgeleverd, maar is nu openbaar gemaakt. Daarin melden de onderzoekers verschillende problemen met de cijfergenerator alsmede verschillende andere onderdelen en doen ze allerlei aanbevelingen. De gevonden problemen lijken nog niet te zijn opgelost, aangezien het BSI stelt dat het rapport nu is gepubliceerd zodat de OpenSSL Software Foundation de problemen kan verhelpen.

Reacties (5)
03-02-2016, 11:19 door [Account Verwijderd]
[Verwijderd]
03-02-2016, 12:05 door Erik van Straten
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".
03-02-2016, 13:46 door Anoniem
@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
03-02-2016, 16:56 door Erik van Straten
03-02-2016, 13:46 door Anoniem: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.
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...
05-02-2016, 17:58 door Anoniem
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).

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.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.