Nie można zaktualizować protokołów Apache SSL ani szyfrów

Od kilku dni szukam i testuję i zabrakło mi rzeczy do wypróbowania. Oto mój problem. Mam serwer WWW Apache Lounge 2.4.18 (Win32) VC14 działający na serwerze Microsoft Windows 2008 R2 przy użyciu OpenSSL 1.0.2g. Nasz korporacyjny zespół ds. Bezpieczeństwa przeskanował mój serwer i wykrył, że używany jest RC4. (Użyli Nexpose z Rapid7). Zalecili skonfigurowanie serwera w celu wyłączenia obsługi szyfrów RC4 i zasugerowali użycie konfiguracji szyfrów pokazanej poniżej. Zalecili także, aby nie używać TLSv1, a tylko TLSv1.1 i TLSv1.2. Uruchomiłem również SSLScan, aby powielić wyniki i widzę, że „TLSv1 128 bitów RC4-SHA” został zaakceptowany.

Nie ma problemu. Pomyślałem i zmieniłem plik httpd.conf, jak pokazano poniżej, a następnie ponownie uruchomiłem usługę Apache2.4. Następnie kazałem im ponownie przeskanować serwer i otrzymali te same wyniki. Przeszukałem cały serwer w poszukiwaniu plików zawierających „SSLCipherSuite” lub „SSLProtocol” i usunąłem je lub zmieniłem ich nazwy z wyjątkiem \ Apache24 \ conf \ httpd.conf. Mam plik \ Apache24 \ conf \ openssl.cnf, ale nie sądzę, że coś robi, ponieważ nadal jest to domyślny plik dostarczany z Apache. Zrobiłem też ogromne czyszczenie i usunąłem wszystkie stare wersje Apache, OpenSSL i PHP. Zaktualizowałem Apache i OpenSSL z Apache 2.2 i OpenSSL 0.9.x około 3 tygodnie temu i działam bez problemów. Nie mam żadnych błędów uruchamiania w przeglądarce error.log lub Windows.

Czy jest jeszcze gdzieś Apache / OpenSSL określa protokoły lub zestawy szyfrów?

Czy istnieje jakieś ustawienie domyślne, które ignorowałoby moje dyrektywy związane z SSL?

Zawartość mojego pliku httpd.conf („MYDOMAIN” oczywiście nie jest moją rzeczywistą nazwą domeny):

<VirtualHost *:80>

    DocumentRoot "C:/Apache24/htdocs"
    ServerName www.MYDOMAIN.com
</VirtualHost>

<VirtualHost *:443>
    DocumentRoot "C:/Apache24/htdocs_apps"
    ServerName apps.MYDOMAIN.com

    SSLEngine on
    SSLCertificateFile "C:/Apache24/certs/233afff052190aeb.crt"
    SSLCertificateKeyFile "C:/Apache24/certs/star_MYDOMAIN_com.key"
    # SSLCertificateChainFile "C:/Apache24/certs/gd_bundle-g2-g1.crt"

    SSLProtocol -ALL +TLSv1.1 +TLSv1.2 
    SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSAAES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSAAES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK

    <Location / >
        Options -ExecCGI -FollowSymLinks -Indexes
        Require all granted
    </Location>
</VirtualHost>

Każda pomoc jest mile widziana.

Jeśli chodzi o openssl.conf, czy zawiera on dyrektywę SSLCipherSuite, a jeśli tak, to czy jest komentowany? Może występować problem „scalania”.

Patrząc na twoją dyrektywę SSLCipherSuite, widzę następujące problemy (które mogą, ale nie muszą być częścią problemu tutaj):

Literówki:

• ECDHE-ECDSAAES256-GCM-SHA384 powinien być prawdopodobnie ECDHE-ECDSA-AES256-GCM-SHA384
• chociaż TLSv1.0, DHE-RSAAES256-SHA prawdopodobnie powinien być DHE-RSA-AES256-SHA

Protokoły TLSv1.0:

• DHE-RSA-AES128-SHA to TLSv1.0
• DHE-DSS-AES256-SHA to TLSv1.0

W każdym razie używam:

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

z

SSLProtocol all -SSLv2 -SSLv3

i wyciągnąć ocenę A + z testu serwera SSL Qualys SSL Labs (w tym weryfikacji braku RC4).

UWAGA: Chociaż niektóre osoby upuszczają TLSv1.0, możesz mieć problemy z dużą liczbą przeglądarek, w tym prawdopodobnie z Androidem 5.0.0 i starszymi, IE 8-10 w Win 7, IE 10 w Win Phone 8.0, Safari 5.1.9 w systemie OS X 10.6.8 i Safari 6.0.4 w systemie OS X 10.8.4

Ahhh sukces! Okazuje się, że nasza sieć używa urządzenia „F5”, które nawiązuje połączenie SSL, a następnie nawiązuje połączenie z powrotem do mojego serwera. Wygląda na to, że muszą pracować na ICH szyfrach! Mój serwer jest teraz wyjątkowo bezpieczny dzięki temu niewielkiemu ćwiczeniu. Używam również CloudFlare, więc połączenie działa Cloudflare-> F5-> OpenSSL przy użyciu TLSv1.1 i TLSv1.2.

Czas na lunch. Zastanawiam się, czy nadal mamy zasady dotyczące 2 drinków na lunch ...

Wygląda na to, że konfiguracja F5 może być „przychodzącym przedsiębiorstwem” zamiast „przychodzącym tranzytem SSL”. Wygląda na to, że różnica polega na tym, że w poprzednim ruchu od użytkownika do F5 jest szyfrowany przez konfigurację F5 SSL, następnie odszyfrowywany w F5 i ostatecznie ponownie szyfrowany za pomocą konfiguracji SSL tylko do komunikacji między F5 a serwerem, podczas gdy w tym ostatnim ruch jest szyfrowany między użytkownikiem a serwerem całkowicie korzystającym z konfiguracji SSL (i jest po prostu przekazywany przez F5 bez deszyfrowania / ponownego szyfrowania). W takim przypadku może się zdarzyć, że Twój ruch jest tylko „bezpieczny” (bez RC4) między Tobą a F5 i jest na łasce konfiguracji F5 w sieci publicznej. Być może warto przynajmniej zadać kilka pytań swoim osobom korzystającym z NetWrok przed założeniem, że masz bezpieczną konfigurację.