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.

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.

Ostrzeżenie SHA-1

Ostrzeżenie o końcu wsparcia SHA-1 – źródło

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 (samodzielnie podpisany)

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ć:

SSLProtocol -All +TLSv1 +TLSv1.1 +TLSv1.2
SSLHonorCipherOrder on
SSLCipherSuite "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-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-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA"

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.

Qualys SSL Labs Qhost.pl

Należy mieć też na uwadze, iż powyższe ustawienie nie elminuje wektora ataku BEAST, wykorzystującego TLSv1.0 który, ze wzgledó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=31536000; includeSubDomains"

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). Skaner SSLLabs z kolei pozwala nam sprawdzić kompatybilność naszych ustawień na wielu różnych platformach.

Globalsign Qhost.pl

Podobne artykuły

  • Tomlee

    Dzięki! Przyda się. Uzyskam A+?

    • Gerard Stańczak

      Jak zastosujesz wszystkie porady z artykułu to tak :)

  • kj

    Skoro generujemy certyfikat RSA, to po co nam w liście protokołów wpisy poświęcone ECDSA (nie zostaną wynegocjowane ze względu na certyfikat)?

    Co na liście szyfrów robi wpis: “DES-CBC3-SHA”?

    “Dla tej drugiej platformy można mimo wszystko przywrócić wsparcie, tworząc na sztywno wygenerowane parametry protokołu Diffiego-Hellmana […]” – statyczny DH jest niewskazany z bardzo prostej przyczyny – złamanie sztywnych parametrów pozwala odszyfrować wszystkie sesje, których klucze zostały wynegocjowane z ich użyciem. Do tego DH jest wyraźnie wolniejszy od rodziny ECDH.

    Mi osobiście brakło jednej rzeczy – porównania szybkości różnych konfiguracji.

    Poza powyższymi – całkiem fajny artykuł :).