Wyłączenie RC4 w apartamencie szyfrowania SSL w serwerze Apache


17

Proszę zobaczyć sekcje Edytuj w moim odpowiedź; one zawierać wyjaśnienie tej zagadki .

Próbuję wyłączyć RC4 dla serwera Apache 2.2.9 uruchomionych na CentOS 6.5 VPS i nie może wydawać się uda.

Niedawno zakupiony certyfikat potwierdzony biznesowo jest zainstalowany, a połączenia SSL działają poprawnie, ale chciałem skonfigurować wszystko tak dobrze, jak to możliwe, aby „wzmocnić bezpieczeństwo”, jak to mówią niektóre samouczki.

Sprawdzając konfigurację za pomocą Qualys SSL Labs, strona wyników pokazuje „Ten serwer akceptuje szyfr RC4, który jest słaby. Klasa ograniczona do B.”

Mam jednak umieścić to w ssl.conf:

 SSLCipherSuite HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!SSLv2:!SSLv3

Zapisałem skrypt podany w odpowiedzi na to pytanie w pliku o nazwie test-ssl-ciphers.sh i zmieniłem adres IP na adres sprzężenia zwrotnego. Jest to wynikiem ./test-ssl-ciphers.sh | grep -i "RC4":

Testing ECDHE-RSA-RC4-SHA...NO (sslv3 alert handshake failure)
Testing ECDHE-ECDSA-RC4-SHA...NO (sslv3 alert handshake failure)
Testing AECDH-RC4-SHA...NO (sslv3 alert handshake failure)
Testing ADH-RC4-MD5...NO (sslv3 alert handshake failure)
Testing ECDH-RSA-RC4-SHA...NO (sslv3 alert handshake failure)
Testing ECDH-ECDSA-RC4-SHA...NO (sslv3 alert handshake failure)
Testing RC4-SHA...NO (sslv3 alert handshake failure)
Testing RC4-MD5...NO (sslv3 alert handshake failure)
Testing RC4-MD5...NO (sslv3 alert handshake failure)
Testing PSK-RC4-SHA...NO (no ciphers available)
Testing KRB5-RC4-SHA...NO (no ciphers available)
Testing KRB5-RC4-MD5...NO (no ciphers available)
Testing EXP-ADH-RC4-MD5...NO (sslv3 alert handshake failure)
Testing EXP-RC4-MD5...NO (sslv3 alert handshake failure)
Testing EXP-RC4-MD5...NO (sslv3 alert handshake failure)
Testing EXP-KRB5-RC4-SHA...NO (no ciphers available)
Testing EXP-KRB5-RC4-MD5...NO (no ciphers available)

Każdy z tych wierszy zawiera „Nie”, które, według scenariusza oznacza, że ​​serwer nie obsługuje określonej kombinacji szyfru.

Ponadto komenda grep -i -r "RC4" /etc/httpddaje mi tylko wyżej wymieniony plik ssl.conf.

Ponadto, działa openssl ciphers -Vna moim apartamencie szyfr RC4 szyfrów nie wykazuje w ogóle, co ma sens, biorąc pod uwagę ciąg konfiguracja.

Mam w związku z tym w jakiś sposób utracone, dlaczego strony internetowe wyboru SSL mówią mi, że „serwer akceptuje RC4”. Oni nawet wymienić następujące szyfrów jako przyjęte:

TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA

Czy ktoś ma możliwego wyjaśnienia? Co ja robię coś źle? Może jest inne miejsce, w którym można skonfigurować obsługę RC4 lub „akceptację”?

Dzięki.

[ EDIT ] Korzystanie z CentOS 6.6 w maszynie wirtualnej w domu, wpadłem skryptu ponownie przed moim VPS przy użyciu jego nazwy domeny zamiast adresu zwrotnego. Taka konfiguracja oznacza, że lista szyfrów zapewniają instancji openssl w VM: Nadal nie mam RC4 wśród szyfrów że dają tak.

Odpowiedzi:


16

Podczas instalowania odnowionego certyfikatu odkryłem, że problem został spowodowany przez określenie (dla domeny i każdej subdomeny) w ISPConfig całego zestawu danych niezbędnych do HTTPS: certyfikat, klucz prywatny, łańcuch CA itp.

Mówiąc inaczej, usuwając zestaw danych doprowadziły do ​​testu Qualys do klasy A i domena jednocześnie usunięcie ostrzeżenia o RC4. Oddanie szczegółów kopii prowadzi do ostrzeżeń wraca i jest ograniczona do klasy B ponownie, co nie pozostawia miejsca na wątpliwości co do linku przyczynowości.

To tak, jakby podanie szczegółów dla każdego vhosta w jakiś sposób stworzyło nowe środowisko, w którym niektóre wartości domyślne zastąpiły zestaw szyfrów, który podałem w ssl.conf. Dziwne.

Rozwiązaniem tego problemu jest dodanie specyfikacji SSLCipherSuite w Dyrektywy Apache tekstowego dla każdego vhost. Oto, co mam w konfiguracji, która daje mi ocenę A:

SSLProtocol ALL -SSLv2 -SSLv3
SSLHonorCipherOrder on
# Compression is disabled by default on my distribution (CentOS 6)
# SSLCompression off 
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

EDIT (16.05.2017): Dodatkowy stwierdzenie o tym problemie: z dnia określające SSLCipherSuitejest obowiązkowe. Nie mogę pojąć, dlaczego ta dyrektywa specyficzny, choć określone na poziomie serwera nie stosuje się automatycznie do konfiguracji hostów wirtualnych . Korzystam z Apache 2.2.15 na CentOS 6.9.

EDIT (18.06.2018): Więcej informacji. Właśnie odkryłem, że SSLCipherSuitedyrektywa może być podany jeden raz i będzie mieć zastosowanie do wszystkich hostów wirtualnych: w pliku konfiguracyjnym baza mod_ssl (na CentOS 6, plik znajduje się na /etc/httpd/conf.d/ssl.conf), po prostu trzeba określić dyrektywa zewnątrz z domyślny wirtualny host. Dokumentacji Apache 2.2 stwierdza, że domyślną wartością tej dyrektywy jest SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP. Sądzę, że jest to miejsce gdzie szyfr RC4 pochodzi z: w przypadku braku jakiejkolwiek specyfikacji, co miało dla mnie, ponieważ nie było w specyfikacji „globalnej” kontekście odnosi się wartość domyślna. To zrozumienie końce, co zostało tajemnicą dla mnie. Paradoksalnie, mam zamiar przejścia na CentOS 7 kiedy znajdę to wyjaśnienie! HTH.


6
SSLCipherSuite HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!SSLv2:!SSLv3
                                                                    ^^^^^^^

Kiepski pomysł. Wyłączenie wszystkich SSLv3 szyfrów wyników w wyłączając szyfrów użytkowych z TLS1.0 i TLS1.1 i liści tylko kilka szyfrów nowo wprowadzonych z TLS1.2 (jeśli obsługuje serwer TLS1.2)

Mam w związku z tym w jakiś sposób utracone, dlaczego strony internetowe wyboru SSL mówią mi, że „serwer akceptuje RC4”. Oni nawet wymienić następujące szyfrów jako przyjęte:

Upewnij się, że testy lokalnych i zewnętrznych zarówno dostęp do tego samego serwera (adres IP). Widziałem wiele miejsc, w których example.comznajduje się na innym hoście niż www.example.coma więc testy różnią.


Tak, domena główna i jej poddomeny znajdują się na tym samym VPS. Jest jeden adres IP związany z VPS i używam ISPConfig zarządzać nimi. Dzięki.
AbVog,

Użyj SSLLabs . Porównaj adres IP, który pokazują, z adresem IP twojego systemu. Upewnij się, że nie masz przed sobą innego (odwrotnego) proxy lub CDN, który mógłby mieć wpływ na wynik.
Steffen Ullrich,

„Wyłączenie wszystkich SSLv3 szyfrów wyników w wyłączając szyfrów użytkowej z TLS1.0 i TLS1.1 i liści tylko kilka szyfrów nowo wprowadzonych z TLS1.2 (jeśli obsługuje serwer TLS1.2)” Więc co jest właściwe rozwiązanie?
Rohn Adams

@RohnAdams: „” RC4 jeśli celem jest RC4 wyłączyć niż część jest w porządku. Problem polegał na overblockingu poprzez użycie dodatkowo „! SSLv3”. Co do przydatnych szyfrów do użytku zobaczyć Mozilla Cipher Generator .
Steffen Ullrich

2

Urzędy Qualys SSL wydaje się bardzo wrażliwe na domyślnych gospodarze itd. Sprawdź, czy wszystkie HTTPS VirtualHosts w tym wykorzystania adresów IP dokładną same ustawienia (oprócz plików certyfikat), miałem podobny problem, gdzie niektóre z Qualys Testy przetestowany przed moim docelowym VirtualHost i niektóre testy zdawały się wybierać domyślny VirtualHost. Mój docelowy vhost miał włączony tylko jeden szyfr, ale Qualys znajdowała znacznie większą listę od domyślnego vhosta.

Znalazłem też lepiej wyglądający skrypt , który podaje dokładniejsze informacje na temat testów SSL.


2

Właśnie przejrzałem jedną z moich stron. Na podstawie odpowiedzi @ AbVog odkryłem, że moje dyrektywy były w rzeczywistości tylko w domyślnym vhostie. Kiedy przeniosłem dyrektywy do globalnego kontekstu, wszystko było dobrze.

Nawiasem mówiąc, natknąłem się również na https://cipherli.st/, który ma dobrą listę konfiguracji SSL dla wielu różnych pakietów. Obecna rekomendacja dla apache jest następująca:

SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff

# Requires Apache >= 2.4
SSLCompression off 
SSLSessionTickets Off
SSLUseStapling on 
SSLStaplingCache "shmcb:logs/stapling-cache(150000)" 

0

Na moim Fedora 25 z Apache / 2.4.25 szyfry są obsługiwane przez cryptopolicies (zobacz / etc / cryptopolicies / backendy). Domyślna konfiguracja całkowicie wyłącza RC4, więc nie ma potrzeby manipulowania szyframi w konfiguracji Apache. Z wyjątkiem zapewnienia, że ​​używasz najnowszej ssl.conf gdyż nie jest instalowany domyślnie ale pozostawił jako ssl.conf.rpmnew w katalogu conf.d.

Aby skonfigurować SSL, musiałem tylko określić certyfikaty, ServerName i DocumentRoot. To znaczy dla Squirrelmail.

SSLCertificateFile /etc/letsencrypt/live/mail.xxxx.dk/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mail.xxxx.dk/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/mail.xxxx.dk/chain.pem
SSLCACertificateFile /etc/letsencrypt/live/mail.xxxx.dk/fullchain.pem
ServerName mail.xxxx.dk:443
DocumentRoot "/usr/share/squirrelmail"
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.