Problem występuje bezpośrednio w specyfikacji TLS i dotyczy jedynie połączeń wykorzystujących szyfry oparte na protokole wymiany kluczy DH (Diffie-Hellman, TLS_DH_*"). W przypadku szyfrów ECDH problem nie występuje i pozostają one bezpieczne. Podatne są tylko protokoły TLS do wersji 1.2; problem nie dotyczy protokołu TLS 1.3. Luka występuje w implementacjach TLS, które ponownie wykorzystują tajny klucz DH w różnych połączeniach TLS (takie zachowanie występuje w około 4.4% serwerów Alexa Top 1M).
W OpenSSL 1.0.2e i wcześniejszych wersjach klucz podstawowy DH jest ponownie używany we wszystkich połączeniach z serwerem, chyba że opcja SSL_OP_SINGLE_DH_USE jest jawnie ustawiona. Od wersji OpenSSL 1.0.2f klucz podstawowy DH jest ponownie używany tylko w przypadku używania statycznych szyfrów DH („DH-*”, np. „DH-RSA-AES256-SHA”). Luka nie występuje w OpenSSL 1.1.1, ponieważ ta gałąź nie wykorzystuje klucza podstawowego DH i nie używa statycznych szyfrów DH.
W przypadku korzystania z metody wymiany kluczy DH obie strony połączenia generują losowe klucze prywatne (zwane dalej kluczem „a” i kluczem „b”), na podstawie których wyliczane i wysyłane są klucze publiczne (ga mod p i gb mod p). Po otrzymaniu przez każdą ze stron kluczy publicznych wyliczany jest wspólny klucz podstawowy (gab mod p), który służy do generowania kluczy sesyjnych. Atak Raccoon umożliwia określenie klucza podstawowego poprzez analizę kanału bocznego w oparciu o fakt, że specyfikacje TLS aż do wersji 1.2 wymagają odrzucenia wszystkich wiodących bajtów zerowych klucza podstawowego przed obliczeniami z nim związanymi.
Wraz ze skróconym kluczem podstawowym przekazywany jest do funkcji generowania klucza sesyjnego, która opiera się na funkcjach skrótu o różnych opóźnieniach przy przetwarzaniu różnych danych. Dokładny pomiar czasu kluczowych operacji wykonywanych przez serwer pozwala atakującemu na ustalenie wskazówek (wyroczni), które pozwalają ocenić, czy klucz podstawowy zaczyna się od zera, czy nie. Na przykład osoba atakująca może przechwycić klucz publiczny (ga) wysłany przez klienta, przesłać go ponownie na serwer i określić
czy wynikowy klucz podstawowy zaczyna się od zera.
Samo zdefiniowanie jednego bajtu klucza nic nie daje, ale przechwytując wartość „ga” przekazywaną przez klienta podczas negocjacji połączenia, atakujący może wygenerować zestaw innych wartości związanych z „ga” i wysłać je do serwerem w oddzielnych sesjach negocjacji połączenia. Generując i wysyłając wartości „gri*ga”, atakujący może, analizując zmiany opóźnień w odpowiedzi serwera, określić wartości, które prowadzą do otrzymania kluczy podstawowych zaczynając od zera. Po określeniu takich wartości atakujący może utworzyć zestaw równań
Luki w zabezpieczeniach OpenSSL
Dodatkowe problemy są odnotowane osobno (
Źródło: opennet.ru