Bezpieczna konfiguracja SSL na serwerze Apache

Generowanie certyfikatów

Certyfikaty SSL od ponad 20 lat są podstawowym składnikiem poprawnie skonfigurowanej usługi hostowania stron internetowych. Krytycznym parametrem określającym siłę szyfrowania SSL jest długość użytych kluczy. Im jest on dłuższy, tym trudniej jest rozszyfrować transmisję, między dwoma komputerami, nie posiadając dedykowanego do tego celu klucza. Aktualnie zalecaną długością klucza asymetrycznego jest 2048 bitów. Zakupione u nas certyfikaty SSL spełniają te wymagania.

Generowanie certyfikatu u zewnętrznego dostawcy

Do (poprawnego) generowania próśb o wygenerowanie certyfikatu (CSR – Certificate Sign Request), zgodnego z obowiązującymi standardami można użyć polecenia:

openssl req -sha256 -new -nodes -newkey rsa:2048 -out /etc/pki/tls/certs/www.example.com.csr -keyout /etc/pki/tls/private/www.example.com.key

Generuje ono dwa pliki – prywatny plik klucza (służący do odszyfrowywania wiadomości) oraz plik CSR na bazie którego będziemy mogli wygenerować publiczny plik klucza (służący do szyfrowania wiadomości). CSR umożliwia wygenerowanie klucza publicznego u zewnętrznych dostawców takich jak Comodo, RapidSSL, Go Daddy itd. O ile sami nie jesteśmy CA (Certificate Authority) to jest to jedyny sposób by móc posiadać „zaufany certyfikat”, tj. taki, który jest rozpoznawany przez przeglądarkę użytkowników i nie wyświetla ostrzeżenia HTTPS (połączenie niezaufane).

Powyższe narzędzie openssl utworzy klucz RSA o długości 2048 bitów (-newkey rsa:2048) nieszyfrowany (-nodes) oraz prośbę o wystawienie certyfikatu, w formacie PKCS#10, z zaznaczeniem iż do podpisania certyfikatu chcemy użyć algorytmu SHA z kluczem 256-bitowym.

Opcja -sha256 jest szczególnie istotna, gdyż wiele urzędów certyfikacyjnych nie posiada jeszcze domyślnego ustawienia by podpisywać certyfikaty używając SHA-2 – zamiast tego wykorzystywany jest słabszy algorytm SHA-1 , który jest obecne traktowany jako przestarzały (i w niedługim czasie spowoduje wyświetlenie ostrzeżenia w przeglądarkach). Opcja -sha256 pozwala nam zaznaczyć iż chcemy użyć konkretnie tej wersji algorytmu SHA do podpisania naszego certyfikatu.

Generowanie certyfikatu typu self-signed

Aby wygenerować certyfikat samemu (self signed), należy użyć polecenia:

openssl req -sha256 -new -x509 -nodes -days 3650 -newkey rsa:2048 -out /etc/pki/tls/certs/www.example.com.crt -keyout /etc/pki/tls/private/www.example.com.key

Podobnie jak w powyższym przykładzie, tworzymy dwa pliki, ale tym razem zamiast CSR tworzony jest plik CRT w którym mamy nasz certyfikat (-x509), podpisany przez nas samych. Pozwala nam to ominąć proces weryfikacji i podpisywanie certyfikatu u zewnętrznego dostawcy (co zazwyczaj jest płatne) ale z drugiej strony, przeglądarki klientów nie będą wyświetlać połączenia jako zaufanego (złamana kłódka HTTPS).

Ustawienia SSL

Aby jeszcze bardziej zwiększyć bezpieczeństwo naszego serwera HTTPS, poza odpowiednimi certyfikatami możemy również zmienić ustawienia dozwolonej listy szyfrów kryptograficznych, które są stosowane w trakcie wymiany informacji. Konfiguracja została przedstawiona na przykładzie Apache 2.2 i systemu operacyjnego CentOS.

W celu wyłączenia obsługi starych i słabych algorytmów/metod szyfrowania do pliku /etc/httpd/conf.d/ssl.conf należy dopisać/podmienić:

SSLEngine on
SSLProtocol -All +TLSv1.3
SSLUseStapling off
SSLStaplingFakeTryLater off
SSLStaplingReturnResponderErrors off
SSLStaplingResponderTimeout 3
SSLCompression off
SSLSessionTickets off
Header always set X-Content-Type-Options nosniff
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256

Powyższa lista SSLCipherSuite oraz SSLProtocol pochodzi ze strony wiki.mozilla.org i zawiera średnie (intermediate) ustawienia bezpieczeństwa. Są one najbardziej kompatybilne lecz mimo wszystko bezpieczne, bowiem wyłączają m.in algorytm RC4 (który posiada zweryfikowane, nienaprawialne słabości) oraz SSLv3 (atak POODLE). Wyjątkiem pod względem kompatybilności jest Internet Explorer 6.0 pod Windows XP oraz Java 1.6. Dla tej drugiej platformy można mimo wszystko przywrócić wsparcie, tworząc na sztywno wygenerowane parametry protokołu Diffiego-Hellmana i dopisać na koniec głównego certyfikatu domeny:

openssl dhparam -out /tmp/dh.crt 1024
cat /tmp/dh.crt >> /etc/pki/tls/certs/www.example.com.crt

Szerszy opis rozwiązania problemu Java 1.6 na stronie httpd.apache.org/docs.

Należy mieć też na uwadze, iż powyższe ustawienie nie eliminuje wektora ataku BEAST, wykorzystującego TLSv1.2 który, ze względów kompatybilności, zalecamy zostawić włączony, gdyż jest najwyższym dostępnym algorytmem w wielu starszych programach, np Internet Explorer do wer. 10, Firefox do wer. 26 czy Chrome do wer. 21.

Strict Transport Security

Jeśli to możliwe, należy do tego samego pliku (ssl.conf) dodać również:

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

Należy to zrobić wyłącznie jeśli aplikacja wspiera w 100% HTTPS, tj nie próbuje łączyć się po czystym HTTP, np do API czy serwerów pomocniczych lub też subdomen, np CDN’ów (w tym przypadku można usunąć fragment "includeSubDomains").

Strict-Transport-Security w skrócie informuje przeglądarkę która otrzymała taki nagłówek wraz z zaczytaniem np. strony głównej portalu, iż użytkownik powinien pozostać cały czas na szyfrowanym połączeniu. Zabezpiecza to użytkownika w sytuacji gdy ktoś próbuje przekierować użytkownika ze strony na której jest (używającej HTTPS) na HTTP (używając ataku typu Man-in-the-middle) i w ten sposób próbującego odczytać zaszyfrowaną transmisję.

Kompresja SSL i atak CRIME

Do /etc/sysconfig/httpd warto dopisać także:

export OPENSSL_NO_DEFAULT_ZLIB=1

Powoduje to wyłączenie kompresowania zaszyfrowanych danych w locie, co zabezpiecza przed atakiem CRIME (w Apache 2.4.3+ ustawienie to można zmienić bezpośrednio w configu – zmienna SSLCompression).

Generator ustawień SSL

Jeśli chcemy w łatwy sposób przygotować bezpieczną konfigurację dla serwerów Apache, Nginx lub HAProxy to możemy posłużyć się dedykowanym do tego celu narzędziem. Mozilla SSL Configuration Generator pozwala dostosować konfigurację, z uwzględnieniem wersji naszego webserwera oraz używanej wersji biblioteki openssl. Mamy dzięki temu pewność że wykorzystujemy najbezpieczniejsze możliwe ustawienia, pasujące do naszego środowiska.

Weryfikacja ustawień SSL

Aby sprawdzić poziom bezpieczeństwa naszego serwera HTTPS, można posłużyć się jednym z wielu dostępnych w sieci narzędzi. Przykładowo aplikacja od firmy Globalsign pozwala przetestować konfigurację pod kątem wielu znanych ataków na protokół SSL (i nie tylko). Pozwala nam także sprawdzić kompatybilność naszych ustawień na wielu różnych platformach.

Obowiązkowa weryfikacja rekordów CAA

Od 8 września 2017 wszystkie Urzędy Certyfikacji zobowiązane są do weryfikacji zapisów w rekordach DNS CAA dla domeny dla jakiej chcą wystawić certyfikat. W praktyce oznacza to, że właściciele domen mają możliwość jasnego określenia, które firmy mogą wystawić certyfikat dla domeny. Ma to za zadanie zabezpieczyć się przed fałszywym wystawianiem certyfikatów. Dla przykładu wpis w domenie:

thecamels.org.		128	IN	CAA	0 issue "rapidssl.com"

określa, że tylko RapidSSL ma prawo wystawić certyfikat dla tej domeny. Szczegółowe informacje odnośnie wprowadzonych zmian dostępne są na oficjalnych stronach poszczególnych wystawców.