Kilka słów o wdrożeniu SSL i TLS – cz. II

W poprzedniej części poznaliśmy teoretyczne przesłanki, na które należy zwrócić uwagę podczas przygotowania się do wdrożenia mechanizmów szyfrowania SSL/TLS. W tej części postaramy się skupić na konfiguracji, która gwarantuje nam poprawne prezentowanie odwiedzającym naszą stronę stosowanych zabezpieczeń i szyfrów kryptograficznych.

2. Używanie kompletnych łańcuchów certyfikatów

Kiedyś przeglądarka Opera – trafiając na stronę z niekompletnym lub samopodpisanym certyfikatem – wyświetlała komunikat: „Łańcuch certyfikatów tego serwera jest niekompletny, a wystawca jest niezarejestrowany.”  W większości dzisiejszych wdrożeń, sam certyfikat serwera jest niewystarczającą informacją dla klienta. Potrzeba dwóch lub więcej certyfikatów, do zbudowania kompletnego łańcucha zaufania. Certyfikaty te są nazywane certyfikatami pośrednimi (ang. Intermediate Certificates) i dostarczane są przez CA (ang. Certificate Authority). Zazwyczaj znajdziemy je do pobrania na dedykowanych stronach dostawców. Na przykład: GeoTrust, RapidSSL, czy Symantec.

Nieprawidłowo wgrany łańcuch certyfikatów, niepoprawnie renderuje certyfikat naszego serwera i powoduje wyświetlanie ostrzeżeń w przeglądarkach. W praktyce, problem ten jest czasem trudny do zdiagnozowania, ponieważ niektóre przeglądarki mogą odtwarzać niekompletny łańcuch, a inne nie. Tym bardziej, że wszystkie przeglądarki mają tendencję do buforowania i ponownego wykorzystywania certyfikatów pośrednich. Jeśli nie jesteśmy pewni, czy dobrze skomponowaliśmy nasz plik .pem z wszystkimi certyfikatami, lub czy wskazane w dyrektywach konfiguracji certyfikaty pośrednie są poprawne, możemy skorzystać w offline z polecenia openssl:

openssl verify -verbose -CAfile certyfikaty_posrednie.pem sekurak.pl.crt
sekurak.pl.crt: OK

Jest to możliwe również po testowym wdrożeniu z narzędzi online typu What’s My Chain Cert? lub SSL Checker:

( Poprawna weryfikacja łańcucha zaufania )

2.1 Używanie bezpiecznych protokołów szyfrowania

Aktualnie jest pięć protokołów w rodzinie SSL/TLS: SSL v2, SSL v3, TLS v1.0, TLS v1.1 oraz TLS v1.2 (specyfikacja TLS 1.3 jest nadal szlifowana, ale IETF jest bardzo blisko rozstrzygnięcia ostatecznej wersji tego protokołu).

• SSL v2 nie gwarantuje już bezpieczeństwa i nie powinien być w użyciu. Może być wykorzystany do atakowania kluczy RSA i witryn o tej samej nazwie, nawet jeśli są na zupełnie różnych serwerach. Na przykład, jeśli serwer poczty obsługuje SSL v2, a serwer WWW nie – atakujący może skorzystać z tej słabości serwera pocztowego, do przerwania połączeń TLS z serwerem WWW (patrz Decrypting RSA with Obsolete and Weakened eNcryption – DROWN)
• SSL v3 jest niebezpieczny podczas wykorzystania w komunikacji HTTP (patrz atak POODLE) oraz w powiązaniu z innymi protokołami. Również został uznany za zdezaktualizowany i nie powinien być już stosowany.
• TLS v1.0 (rozwinięcie SSL v3) pomimo, że jest przestarzały i nie powinien być w użytku, można go jeszcze spotkać w internecie. Jego główną słabością jest atak Browser Exploit Against SSL/TLS – BEAST. Współczesne wersje przeglądarek złagodziły jego działanie, ale inne problemy nadal pozostają.
• TLS v1.1 i v1.2 są wersjami bez większych znanych problemów z bezpieczeństwem, ale tylko 1.2 zapewnia nowoczesne algorytmy kryptograficzne oraz uwierzytelnienie szyfrowania z dodatkowymi danymi (Authenticated Encryption with Additional Data – AEAD). Oczywiście, aby oferować wsparcie starszym klientom, niektóre witryny muszą także wspierać starsze wersje (1.0 / 1.1) protokołów TLS. Jednakże „emerytura” dla TLS v1.0 została już zaplanowana przez standard PCI DSS, który będzie wymagać od wszystkich stron akceptujących płatności kartą kredytową, aby zaprzestały używać tej wersji do czerwca 2018 r.

2.2 Używanie bezpiecznych szyfrów

Bezpieczeństwo komunikacji polega na pewności, że nasza wymiana danych odbywa się bezpośrednio tylko z drugą stroną i nie przechodzi przez kogoś, kto będzie mógł ją podsłuchać. W SSL’u i TLS’sie, to szyfry określają bezpieczeństwo naszej komunikacji. Zbudowane są z różnych bloków, z ideą osiągnięcia bezpieczeństwa dzięki swojej różnorodności. Jeżeli jeden z tych bloków okaże się słaby lub niebezpieczny, powinniśmy być w stanie przełączyć się na inny. Obecnie powinniśmy polegać przede wszystkim na zestawach oferujących wspomniany mechanizm AEAD, które zapewniają silne uwierzytelnianie i wymianę kluczy, utajnienie przekazywania oraz szyfrowanie conajmniej 128 bitowe. Podobnie jak w przypadku protokołów, niektóre słabsze szyfry także muszą być obsługiwane, ale pod warunkiem, że są one negocjowane wyłącznie przez starsze wersje klientów, które nie obsługują nic lepszego. Poniżej przedstawiam kilka przestarzałych funkcji kryptograficznych, których już należy unikać:

• wszystkie szyfry używające anonimowej wymiany klucza – Anonymous Diffie-Hellman (ADH) nie zapewniają uwierzytelniania,
• zestawy z słabymi szyframi (zazwyczaj 40 i 56 bitów) mogą zostać łatwo złamane,
• RC4 został już uznany za niedostatecznie bezpieczny,
• 3DES jest wolny i słaby,
• wszystkie szyfry eksportowe, czyli takie które zostały zaprojektowane by być dostatecznie słabymi i mogły zostać eksportowane z USA w latach 90., są niebezpieczne podczas etapu negocjacji połączenia oraz mogą zostać również użyte przeciwko serwerom, które preferują silniejsze rozwiązania (patrz: atak FREAK),
• NULL – szyfry, które nie używają szyfrowania.

UWAGA! Pamiętajmy, aby wszystkie konfiguracje TLS testować uprzednio, na przeznaczonych do tego środowiskach. Zanim wszystkie zmiany zostaną przeniesione na produkcję, należy upewnić się, że wszystko działa i jest zgodne z naszymi założeniami. Należy pamiętać, że wszystkie zalecenia są możliwe do użycia w szerokim polu zastosowań, ale nie wszystkie systemy (zwłaszcza te starsze) obsługują wszystkie protokoły oraz szyfry. Dlatego tak ważnym krokiem w konfiguracji, są przeprowadzane w pierwszej kolejności testy.

Jako punkt wejścia, możemy użyć następującego zestawu przeznaczonego dla obu rodzajów kluczy RSA oraz ECDSA:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

Powyższy przykład konfiguracji, wykorzystuje standardowe nazwy zestawów TLS. Niektóre platformy i serwery mogą posługiwać się do niestandardowymi nazwami lub skrótami. Dokumentacja danej platformy zawsze powinna zawierać więcej szczegółów odnośnie używanych konwencji.

2.3 Wybieranie najlepszych zestawów szyfrujących klienta

W protokołach SSLv3 oraz późniejszych, to klient (najczęściej przeglądarka) przedstawia zestaw obsługiwanych szyfrów, a serwery wybierają jeden z nich do obsługi połączenia przez obydwie strony. Nie wszystkie serwery radzą sobie z tym najlepiej – czasami wybierane są losowe zestawy z listy klienta. Posiadanie serwerów, których konfiguracja pozwala na wybranie tych najlepszych z listy, jest kluczowe dla osiągania lepszego poziomu zabezpieczeń.

2.4 Stosowanie utajnienia przekazywania

Utajnienie przekazywania (nazywane czasami „doskonałym utajnieniem przekazywania”) jest funkcjonalnością protokołu, która pozwala na bezpieczną komunikację niezależną od klucza prywatnego serwera. Przy stosowaniu szyfrów nie obsługujących tej funkcji istnieje ryzyko, że ktoś kto pozyska klucz prywatny serwera będzie w stanie odszyfrować wszystkie wcześniej podsłuchane i zapisane komunikaty. Jest to kolejny powód, aby preferować zestawy ECDHE dla aktualnych przeglądarek internetowych (wsparcie dla starszego grona klientów możemy obsłużyć przez cofnięcie się do obsługi również zestawów DHE).

2.5 Używanie silnej wymiany kluczy

Mimo, że wymiany klucza RSA są wciąż jeszcze popularne to powinniśmy unikać tego typu operacji (oczywiście nie jest to zawsze możliwe do osiągnięcia). Większość publicznie dostępnych stron do wymiany kluczy stosuje już szyfry z rodziny Diffie–Hellman Ephemeral (DHE) lub Elliptic Curve Diffie–Hellman Ephemeral (ECDHE) stosując klucze efemeryczne. Niestety – w 2015 roku, grupa badaczy opublikowała nowy atak przeciwko DHE, znany pod nazwą Logjam. Odkryto wtedy, że wymiany kluczy o niższej sile (np. 768 bitów) można łatwo złamać, a różnego rodzaju agencje państwowe mogą być w stanie dokonać tego nawet na 1028 bitach. Dlatego, jeśli chcemy być po bezpiecznej stronie wdrażając DHE – nasza konfiguracja powinna opierać się przynajmniej na 2048 bitach bezpieczeństwa. Należy się jednak liczyć z faktem, że niektórzy starsi klienci (np. Java 6) mogą nie wspierać tego poziomu mocy. Z powodów wydajnościowych, powinniśmy jednak iść w stronę ECDHE, który jest silniejszy i szybszy. Krzywa eliptyczna secp256r1 (znana również jako P-256) jest dobrym wyborem w tym przypadku.

2.6 Ciągłe badania w laboratorium

Jak się odnaleźć w tych wszystkich zależnościach i wybrać najlepsze ustawienia, jeśli chodzi o użytkowane serwery? Niekwestionowanym liderem w benchmarku ustawień SSL/TLS, jest portal Qualys SSL Labs. Oferuje nie tylko testy serwerów, ale także używanych przeglądarek. Możemy w ten sposób nie tylko sprawdzić ustawienia swojego serwera, ale także swojego klienta.

( Wycinek z testu sekurak.pl wykonanego przez Qualys SSL Labs )

W internecie istnieje wiele gotowych konfiguracji, spełniających wymagania do poziomu oceny „A”. Niezależnie, czy używamy Apache (w wersji 2.2, 2.4), Nginx, HAproxy, czy innych dowolnych serwerów SMTP i FTP. Polecam jednak nie stosowanie gotowców, a rozpoczęcie przygody od podstawowych ustawień i stopniowym „rozgryzaniu” komunikatów typu „This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B” lub „The server does not support Forward Secrecy with the reference browsers”, w celu lepszego zrozumienia dlaczego „takie” ustawienie jest już przestarzałe oraz jakie konsekwencje wiążą się z jego pozostawieniem, lub nie dodaniem do istniejącej instalacji. Powinniśmy tak długo pracować nad swoją konfiguracją, aż dojdziemy do możliwie najwyższego poziomu, na którym będą spełnione wszystkie nasze założenia odnośnie liczby i rodzaju obsługiwanych klientów. Warto również zapoznać się z stroną BadSSL i przetestować listę najczęściej występujących błędów na przeglądarkach oraz przyczyn, które je powodują. W ten sposób będziemy mogli szybciej diagnozować problemy z naszymi testowymi wdrożeniami.

CDN.

W kolejnej części zajmiemy się tematem wydajności, która nie zawsze idzie w parze z wysokim poziomem bezpieczeństwa.

– Patryk Krawaczyński