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ść 2k. 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 2nr 2bloki 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
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).
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.
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.
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
- Konfiguracje SSL/TLS powinny preferować AES zamiast DES. Wersje OpenSSL dostarczane z Red Hat Enterprise Linux 6 i 7 już to robią.
- 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.
- 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.
- Wyłącz 3DES. Można to osiągnąć dla Apache httpd, ustawiając:
SSLCipherSuite WYSOKI:ŚREDNI:!MD5:!RC4:!3DES
Rezolucja
- Ta wada jest związana z konstrukcją szyfru DES/3DES i nie jest wadą implementacji.
- 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.
- 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.
- 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