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

2

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.

apache-2.4 openssl mod-ssl Ron
źródło
Właściwie to ostatnio przez to przeszedłem i ten dokument bardzo mi pomógł. W rzeczywistości było dość podobne do twojego scenariusza: poordh.org/sysadmin.html
To bardziej przypomina pytanie konfiguracyjne serwera niż pytanie bezpieczeństwa. „Czy gdzieś indziej Apache / OpenSSL określa protokoły lub zestawy szyfrów?”
schroeder
Dzięki @Robert Mennell, ale ten link nie wydaje się być odpowiedni dla mojego problemu.
Ron
Dzięki @schroeder za przeniesienie tego do bardziej odpowiedniej lokalizacji
Ron

Odpowiedzi:

1

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

Źrebię
źródło
Dzięki za sugestie, wypróbowałem je wszystkie bez powodzenia. W pliku openssl.cnf nie było dyrektywy SSLCipherSuite. Dzięki za wskazanie literówek, to właśnie otrzymuję do kopiowania / wklejania od firmy. Posunąłem się o krok dalej i szukałem innych literówek, dzieląc moje szyfry na arkusz kalkulacyjny programu Excel, a następnie eksportując obsługiwane szyfry z openssl -v i dokonałem przeglądu między nimi. Znalazłem „kEDH + AESGCM” oprócz dwóch, które wskazałeś. Zmieniłem również protokół SSL, aby pasował do twojego, i nadal akceptuję „TLSv1 128 bitów RC4-SHA”.
Ron
Właśnie przeprowadziłem eksperyment z interesującymi wynikami. Mam serwer programistyczny z prawie identyczną konfiguracją. Jedyną różnicą, o której mogę myśleć, jest fakt, że Apache24 został skonfigurowany ponad rok temu, zanim się zaangażowałem. Skopiowałem httpd.conf z mojego serwera produkcyjnego na serwer deweloperski i zmieniłem dyrektywy z nazwami serwerów. Po ponownym uruchomieniu Dev Apache szyfry RC4 nie są akceptowane. To mówi mi, że mam coś innego między konfiguracjami między dev i prod, a coś na serwerze Prod powoduje ignorowanie dyrektyw związanych z SSL, nawet jeśli SSL jest uruchomiony.
Ron
Myślę, że goniłem za ogonem. Skopiowałem wszystkie moje pliki produkcyjne na serwer deweloperów, a serwer deweloperów działa świetnie. Następnie postanowiłem ponownie przeskanować serwer prod przy użyciu wewnętrznego adresu IP zamiast adresu publicznego i przeszedł on w żywych kolorach. Żadnych słabych szyfrów! Teraz muszę zacząć patrzeć w zupełnie innym kierunku!
Ron
1

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 ...

Ron
źródło
1

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ę.

Źrebię
źródło
@ Ron Tak, wydaje się, że dobrze byłoby wiedzieć! Oprócz kwestii bezpieczeństwa (najsłabsze łącze) konfiguracja odszyfrowywania / ponownego szyfrowania wydaje się być również bardzo nieefektywna, ponieważ istnieje wiele narzutów związanych z konfigurowaniem szyfrowania, co zwykle (w zależności od innych ustawień) zdarza się dla każdego wysyłanego pliku. Robienie tego DWUKROTNIE dla każdego pliku nie wydaje się dobrą rzeczą.
Colt