Naprawiono lukę BEAST w Apache 2.0 działającym na RHEL 4

Mam serwer WWW z Apache 2.0 na RHEL4. Ten serwer ostatnio nie przeszedł skanowania PCI.

Powód: Luka w zabezpieczeniach protokołu SSLv3.0 / TLSv1.0 Słabe rozwiązanie w trybie CBC: Ten atak został zidentyfikowany w 2004 r. I późniejszych wersjach protokołu TLS, które zawierają poprawkę. Jeśli to możliwe, zaktualizuj do wersji TLSv1.1 lub TLSv1.2. Jeśli aktualizacja do TLSv1.1 lub TLSv1.2 nie jest możliwa, wyłączenie szyfrów w trybie CBC usunie tę podatność. Użycie następującej konfiguracji SSL w Apache eliminuje tę podatność: SSLHonorCipherOrder On SSLCipherSuite RC4-SHA: HIGH:! ADH

Prosta poprawka, pomyślałem. Dodałem linie do konfiguracji Apache i to nie działało. Najwyraźniej
„SSLHonorCipherOrder On” działa tylko na Apache 2.2 i nowszych. Próbowałem zaktualizować Apache, wkrótce wpadłem w piekło zależności i wydaje się, że będę musiał zaktualizować cały system operacyjny, aby uaktualnić do Apache 2.2. Wycofujemy ten serwer za kilka miesięcy, więc nie warto.

Rozwiązanie mówi „Jeśli aktualizacja do TLSv1.1 lub TLSv1.2 nie jest możliwa, wyłączenie szyfrów w trybie CBC usunie lukę”.

Jak mam to zrobić na Apache 2.0? Czy to w ogóle możliwe? Jeśli nie, czy są jakieś inne rozwiązania?

Oprócz ręcznego kompilowania nowszego Apache'a, jedyne, co mogę wymyślić, to uczynić RC4-SHA jedynym obsługiwanym szyfrem (testowany z openssl ciphers RC4-SHAbieżącym openssl, aby upewnić się, że drukuje tylko jeden szyfr, możesz zrobić to samo aby upewnić się, że nie pasuje do jakiegoś dziwnego starego szyfru na starym openssl):

SSLCipherSuite RC4-SHA

MS twierdzi, że Windows XP obsługuje TLS_RSA_WITH_RC4_128_SHA, więc nie powinieneś mieć żadnych problemów ze zgodnością.

Istnieją tylko dwa sposoby „naprawy” BEAST na poziomie serwera.

Najlepszą opcją jest uaktualnienie biblioteki SSL serwera do biblioteki, która obsługuje TLS 1.1 lub nowszą (i upewnij się, że klienci też ją obsługują, abyś mógł ją zmusić).

Inną opcją jest wyłączenie wszelkich algorytmów szyfrowania CBC (Cypher-Block-Chaining) i przejście na szyfr en en (Electronic Code Book) lub coś w rodzaju RC4 (algorytmy EBC są teoretycznie „mniej bezpieczne”, ponieważ dane wejściowe w postaci zwykłego tekstu są zaszyfrowane Klawisz zawsze odwzorowuje z powrotem na ten sam szyfrogram, co ułatwia przełamywanie znanych ataków w postaci zwykłego tekstu, ale w praktyce nie jest to prawdopodobnie duży problem. Google (na przykład) nadal używa RC4).

Ponieważ serwer, na którym działasz, jest martwy, zakopany, a jego rozkład prawdopodobnie nie jest wart wysiłku, którego wymagałoby zbudowanie łatanego Apache (będziesz musiał odbudować Apache i OpenSSL w izolacji, aby nie zdenerwować niczego, co wymaga domyślnie zainstalowanej w systemie wersji OpenSSL - jeśli wykonujesz tyle pracy, możesz również uaktualnić cały system do czegoś, co faktycznie jest obsługiwane), dzięki czemu pozostawiasz „Przełącz na szyfrowanie EBC” jako twoje realne rozwiązanie.

BEAST jest tak naprawdę niczym nie hamującym ataku - wszystkie popularne przeglądarki (IE, Chrome, Safari, Opera) wdrożyły skuteczne obejście , a ze względu na sposób działania ataku bardzo trudno jest go wdrożyć poza przeglądarką (więc apti yumnadal są całkiem bezpieczne).

Adam Langley z Google wygłosił znakomitą rozmowę na początku tego roku, w której przedstawiono niektóre z problemów, na które powinieneś się skupić w zakresie: SSL i bezpieczeństwa - Podczas gdy BEAST zasłużył na wzmiankę, jest blisko dolnej części listy rzeczy, o które należy się martwić.

Jedynym znalezionym przeze mnie rozwiązaniem, które pozwoli Ci przejść test ssllabs.com, jest dodanie następujących czterech wierszy do plików httpd.conf i plików ssl.conf w apache:

SSLHonorCipherOrder On

SSLProtocol -all + TLSv1 + SSLv3

SSLCipherSuite RC4-SHA: WYSOKI:! MD5:! ANULL:! EDH:! ADH

Wyłączono SSLInsecureRenegotiation

Upewnij się, że żadne z tych ustawień nie zostało dwukrotnie opublikowane w pliku ssl.conf.

Teraz moje strony przechodzą z literą A.