Parę osób podesłało linki o ostatnim bugu w OpenSSL w Debianie, więc skomentuję z punktu widzenia crypto:

1. co należy zrobić jeśli mamy Debiana: upgradnąć OpenSSL-a i wymienić wszystkie klucze z w nim używane (ogólnie jak to się nazywa „certyfikat” to trzeba założyć nowy);
2. jest to problem z generatorem kluczy kryptograficznych w debianowej paczce z OpenSSL (Debian Security Advisory DSA-1571-1);
3. jest na ten problem wystawione CVE ale jeszcze nie jest opublikowane;
4. problem dotyczy Debiana i dystrybucji pochodnych (Ubuntu, Xandros), NIE dotyczy reszty instalacji OpenSSL (np na Solarisie);
5. NIE JEST to problem klasy remote root exploit, przynajmniej na razie;
6. nie jest też dla mnie jasne czy problem nie jest zarażliwy, tzn czy klucz którym negocjowaliśmy Z serwerem na którym jest niedobry OpenSSL należy uznać za skompromitowany, może tak być;
7. należy zapaczować systemy i przegenerować wszystkie klucze OpenSSL, OpenSSH i pochodne używane od 2006, ale nie nerwowo, dotyczy to kluczy do: TLS, OpenSSL, OpenSSH, OpenVPN, DNSSEC, i inne w standardzie X.509;
8. należy unieważnić wszystkie klucze DSA których dotknął debianowy OpenSSL, ale znowu, nie nerwowo;
9. błąd polega na tym, że można przewidzieć stan generatora liczb losowych używanego w operacjach kryptograficznych, co powoduje że można sobie przewidzieć kawałki obliczeń kryptograficznych które nigdy nie miały być przewidywalne;
10. prawdopodobieństwo włamania przez taką dziurę jest epsilonowe, to nie jest normalny exploit, żeby włamać się do szyfrowanej transmisji dalej trzeba wykonać wiele cięźkich obliczeń, jedyne co ten błąd zmienia, że nie będą one trwały miliona lat;
11. nie wiem ile, powiedzmy godzinę, albo tydzień, botnety w końcu nauczą się to łamać równolegle, takie obliczenia się nieżle zrównolegla;
12. łamliwa w tym wypadku jest autoryzacja ssh spalonymi kluczami, oraz weryfikacja podpisów, np S/MIME czy w trakcie negocjacji TLS robiona ze słabego hosta;
13. może być z tego jakiś worm, ale nie zaraz, raczej za tydzień, albo za miesiąc;
14. bardziej przydatne to będzie do phishingu, ale to będzie dość skomplikowane (trzeba zrobić atak przez pośrednika na złamanym certyfikacie);
15. z punktu widzenia infosecu sytuacja jest niepożądana, ale normalna, to dla neutralizowania takich problemów powinno się co jakiś czas wymieniać klucze na wypadek ich spalenia, do tego są CRL-e, OCSP, do tego są procedury;
16. (macie procedury, prawda?);
17. (chciałbym obejrzeć to co się teraz dzieje w centrach certyfikacji kluczy, oni też używają Debiana);
18. centra certyfikacji będą miały dużo roboty teraz, do wymiany jest pierdyliard certyfikatów;
19. zarobią na tym dużo pieniędzy;
20. powyższe nie dotyczy softu kryptograficznego nie korzystającego z OpenSSL, w szczególności nie dotyczy GNU Privacy Guarda (gpg);
21. komentarze: Slashdot, Ben Laurie, LWN, Kravietz, Ben Laurie;
22. Debian obiecuje stronę z info co robić, na razie (2008-05-14 02:00 CEST) nic tam nie ma, how cute;
23. za to jest strona na Debian Wiki;
24. debianista który wtedy paczkował OpenSSL-a jest debilem;
25. nie popisali się też panowie z OpenSSL-a, ta poprawka była dyskutowana na liście dyskusyjnej OpenSSL-dev której twórcy OpenSSL nie czytają bo i po co;
26. w ramach ograniczania zniszczeń wyszła nowa paczka z OpenSSH (DSA), przy okazji upgrade wyrzuci wszystkie znalezione słabe klucze, uwaga, żeby się nie odciąć od serwerów, klucze można przetestować wcześniej tym skryptem;
    

Dobranoc państwu.