SWEET32: Urodzinowe ataki na szyfry TLS z blokiem 64-bitowym (CVE-2016-2183) — Red Hat Customer Portal (2024)

Przegląd

Red Hat Product Security został poinformowany o problemie z szyframi blokowymi w protokołach SSL/TLS, który w pewnych konfiguracjach może pozwolić na atak kolizyjny. Ten problem został oceniony jakoUmiarkowanyi jest przypisanyCVE-2016-2183. Ten problem nie wymaga obecnie żadnych aktualizacji ani działań ze strony użytkowników produktów Red Hat. Proszę zobaczyćRezolucjaponiżej, aby uzyskać więcej informacji.

Tło

Starsze szyfry blokowe o rozmiarze bloku 64 bitów są podatne na praktyczny atak kolizyjny, gdy są używane w trybie CBC. Wszystkie wersje protokołu SSL/TLS obsługują zestawy szyfrów, które używają 3DES jako symetrycznego szyfru szyfrującego (na przykład ECDHE-RSA-DES-CBC3-SHA). W wersjach OpenSSL dostarczanych z Red Hat Enterprise Linux 6 i 7, zestawy szyfrów oparte na DES są wymienione poniżej tych, które obsługują AES-128 (z zestawem szyfrów PFS) i AES-256. Oznacza to, że szyfr DES zostanie wybrany tylko wtedy, gdy serwer jawnie wyłączy AES-128 i AES-256. W wersji OpenSSL dostarczanej z Red Hat Enterprise Linux 5 zestawy szyfrów oparte na DES są wymienione poniżej AES-256, ale powyżej AES-128. W takich przypadkach DES zostanie wybrany tylko wtedy, gdy serwer wyraźnie wyłączy zestaw szyfrów oparty na AES-256.

Bezpieczeństwo szyfru blokowego zależy od rozmiaru klucza (k). Dlatego najlepszym atakiem na szyfr blokowy jest wyczerpujący atak wyszukiwania klucza, który ma złożoność 2^k. Jednak gdy szyfry blokowe są używane do szyfrowania dużych ilości danych przy użyciu trybów szyfrowania, takich jak CBC, rozmiar bloku (n) również odgrywa niewielką rolę w określaniu jego bezpieczeństwa.

Gdy używany jest tryb szyfrowania CBC, następuje prosty atak urodzinowy, w którym po 2^{nr 2}bloki danych są szyfrowane tym samym kluczem, oczekuje się kolizji między dwoma blokami szyfrowania. Kolizja na wyjściu oznaczałaby, że dane wejściowe są takie same. Te dane w połączeniu z kilkoma warunkami (omówionymi poniżej) mogą być użyte do wyodrębnienia zwykłego tekstu z zaszyfrowanych danych.

Praktyczność ataku

1. Po pierwsze DES/3DES jest jedynym szyfrem używanym w SSL/TLS, który ma rozmiar bloku 64 bitów. Jak omówiono w podsumowaniu, zestawy szyfrów zawierające 3DES mają wyższy priorytet niż inne zestawy szyfrów (na przykład AES-128).

2. Aby przeprowadzić atak na 64-bitowe szyfry blokowe, należy przechwycić co najmniej 32 GB danych w sieci. W przypadku SSL/TLS oznaczałoby to pojedynczą sesję SSL/TLS. (W przypadku wszystkich nowych sesji SSL/TLS renegocjuje klucze symetryczne). Dlatego długotrwałe połączenia https mogą być podatne na ataki.

3. W wielu kontekstach odzyskanie tylko xor między dwoma blokami zwykłego tekstu nie wystarcza do przeprowadzenia praktycznego ataku. Atak można jednak przeprowadzić, gdy spełnione są następujące warunki:

   • Stały sekret jest wysyłany wielokrotnie;

   • Pewna część zwykłego tekstu jest znana.

4. Atak typu dowód koncepcji, o którym mowa w artykule badawczym, zakłada, że ​​​​między serwerem a klientem przekazywany jest token uwierzytelniający dla całej jego komunikacji (token może być plikiem cookie z poświadczeniami używanymi w podstawowym uwierzytelnianiu). Atakujący następnie uruchamia złośliwy JavaScript w źródle atakowanej strony internetowej. ABESTIArodzaju ataku można następnie użyć do wyodrębnienia pliku cookie.

Łagodzenia

1. Konfiguracje SSL/TLS powinny preferować AES zamiast DES. Wersje OpenSSL dostarczane z Red Hat Enterprise Linux 6 i 7 już to robią.
2. W wersji OpenSSL dostarczanej z Red Hat Enterprise Linux 5, 3DES jest wymieniony poniżej szyfru AES-256 i powyżej szyfru AES-128, dlatego zestawy szyfrów oparte na AES-256 nie powinny być wyłączane na serwerze.
3. Serwery korzystające z OpenSSL nie powinny wyłączać mechanizmów szyfrowania AES-128 i AES-256. Wersje Apache dostarczane z Red Hat Enterprise Linux używają domyślnego ciągu szyfrującego, w którym AES jest preferowany w stosunku do zestawów szyfrujących opartych na DES/3DES.
4. Wyłącz 3DES. Można to osiągnąć dla Apache httpd, ustawiając:SSLCipherSuite WYSOKI:ŚREDNI:!MD5:!RC4:!3DES

Rezolucja

1. Ta wada jest związana z konstrukcją szyfru DES/3DES i nie jest wadą implementacji.
2. Ta luka nie wpływa bezpośrednio na żadne biblioteki kryptograficzne (OpenSSL, NSS i GnuTLS) w Red Hat Enterprise Linux 5, 6 i 7, ponieważ istnieje kilka silniejszych zestawów szyfrujących, które są umieszczone wyżej niż 3DES w domyślnych konfiguracjach list szyfrów.
3. W systemie Red Hat Enterprise Linux 5 nie wyłączaj mechanizmów szyfrowania opartych na AES-256 na serwerze. W przypadku Red Hat Enterprise Linux 6 i 7 nie wyłączaj mechanizmów szyfrowania opartych na AES-128 lub AES-256 na serwerze.
4. Zaleca się całkowite wyłączenie szyfrów DES/3DES, aby uniknąć scenariuszy, w których szkodliwi klienci mogą oferować wrażliwe szyfry tylko podczas uzgadniania TLS.

Poprawki bezpieczeństwa nadrzędnego:

OpenSSL:

OpenSSL oceniło to jako „niski” problem bezpieczeństwa. Przenieśli zestawy szyfrujące 3DES z kategorii WYSOKI do ŚREDNIEGO w gałęzi 1.0.2 i domyślnie wyłączą je w nadchodzącym wydaniu.

NSS:

Mozilla wprowadza limity danych dla wszystkich zestawów szyfrujących.

Powiązane kwestie

Upstream OpenVPN jest również podatny na atak Sweet32 i jest śledzony przezCVE-2016-6329. Wada ta nie ma wpływu na implementację OpenVPN firmy Red Hat.

Bibliografia

https://access.redhat.com/security/cve/CVE-2016-2183
https://sweet32.info/

• Produkt(y)
• Red Hat Enterprise Linux

• Kategoria
• Wsparcie

• Część
• opensl

• Tagi
• cve
• opensl
• bezpieczeństwo

• Typ artykułu
• Ogólny